robcat2075

"Use visual styles on windows and buttons" seems to be a feature that causes the problem. There may be others.

I'd call that a "Teaser" Looks good!

As i look at that some more, it's possible the "frosting" is not intended to be a frosted glass look but a more typical specular reflection. Carefully posing lights to sweep the specular reflection across the front might get you the effect in one pass. Use the Glossy shader for that.

yup!

Hey, Xtaz... if you can, re-edit the title of this thread to point people to the post with your solution. I bet lots of people have run into it. I think the XP is the key. I didn't have this problem either when I was on Win2000. Some detail of the Vista/Win7 display is a problem for A:M.

If no one else steps up to organize the next project I'll declare a topic myself and do the organizing. But like all my projects it will run long, have the deadline extended several times, then disappear without a trace for months with no explanation and only appear long after you had given up all hope of it ever surfacing. I'm just warnin' ya...

Me... if I had a program that could already do the text effect I needed, I'd use it! But in A:M... hmmm... of course, the letters have depth and small bevels on the edges... I think two passes would be necessary, one for the transparent effects and then one for the frosted look that turns the glass white where light is hitting it The transparent glass pass would be a regular render. It probably needs refraction in the glass material, but hard to tell from the sample. For the frosted pass I would reset all the letters to flat white and turn off all the lights except the spot light waving across them. The frosted pass would be composited at about 50% over the glass pass with a screen or multiply or add or something so only the bright parts were transferred. It's possible that separate "frosted" passes would be needed for each layer of the letters: front surface, front bevel, sides, back bevel, back surface... to catch the different bits of light on them.

That take the appearance of the of the screen back to about 1995 but it does seem to fix it. there's probably one of those "Custom" setting s that is the culprit and the others could still be on. There is a situation with simulating cloth where you need "aero" to be on to see the simulation (hence the "dont' turn off "aero" " checkbox in Options).

Hair was off when I did mine. It's not that chor that only has that problem. Anything that runs more than 5 seconds will freeze. I think it's related to Win 7 or Aero some how. What video card to you have Nancy?

I wouldn't do 16 passes on a Q render but even with 1 pass or non-MP it doesn't take much screen area for the render to exceed 5 seconds and freeze. You can look at the screencam movie in my AMreport to see how small an area will trigger it. I have my PWS on a second monitor as an undocked separate window.

He looks like a dangerous musician.

I've put a report in, #5939.

I'm finding it can still fail even with the above precautions, but not nearly so often. Always use a Shift-Q render as those are easier to abort and restart.

I've found something... If I close all other windows that are open on the computer, the renders will finish. No other window, even a directory window, can be open. Don't even have the PWS or any other A:M window open in a separate window. Try that... EDIT: they have to be closed, not just minimized.

I have an NVidia card. How about you guys?

I haven't actually tried using an 8bit depth file on FakeAO but my intuition is it's gotta be an EXR depth file because fakeAO needs the extra precision. You can render to PNG and have FakeAO applied to the render because it's using the internal hi precision depth buffer, but if I want to do my FakeAO in post it needs to be an EXR depth buffer.

That looks like what I get too. I just tried it on a TWO scene with lots of hair and it stopped at 5 secs. If the area is small or simple enough to finish in less than 5 sec it's OK, but more than 5 is a problem Shift-Q renders have the same problem but dont' seem to actually crash A:M. I hadn't noticed the 5 seconds before but that does seem to be the limit.

I hadn't noticed a specific 5 second event yet but on complex scenes I often find a progressive render will give up or a Q render will quit and return to a shaded view.

Two ideas to consider... -rig and animate with TSM2 like you really want to -bake the animation including constraint results -swap in a version of your model that didn't have rigger run on it yet (it would have none of the non-geometry control bones, just the bones your mesh is attached to.) -delete all the channels pertaining to now-unnecessary bones (you can make a filter to make it easy to do this again once you've done it once) -export You dont' want the mesh at all? Swap in a version of your character that has all the mesh deleted and leaves just the bones, then export.

I just tried it , it appears to work in v16.

As far as I know, you need to use multi pass to get OpenEXR renders to contain most buffers, including the depth buffer. Or is there some way to use regular render and still get a depth buffer? It can't be a "normalized" depth buffer like the 8-bit renders get with the depth buffer switch ON (because that won't work with fakeAO, AFAIK)

Thanks!

Looks like real movie stuff you're making!

thanks, Mark!

One reason it probably hasn't been used much is that TSM2 didn't have seamless FKIK inthe legs so you would likely choose to use IK from the start since that will be most suited to most motion that a character does. Only time I've used leg FK was on TWO and we had the squetch rig that did seamless FKIK that made using it temporarily in the middle of a shot easy.