robcat2075

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.

the emmitter only has about six positions on the circle and the particle emitter only knows its momentary positions, not the arc connecting them You could try a longer orbit time or try setting motion blur ON, 100%

I cancelled out of the missing files and can see something...

A chor with no models won't get us much. A PRJ with embedded models would be better.

Interesting find. It's pretty rare to use FK legs on anything so I can imagine it not getting caught.

First, how are you using this video? What are you putting this video in? If you are putting this in other video it' s just a simple dissolve in your editing program.

His says "swept"... he used the sweeper wizard (may not exist in v11) to extrude small circular cross section along each spline. Dong the dissolve we mentioned earlier will be much easier for you.

OK, I'm stumped... how does that work without using "render as lines"?

Welcome back to A:M! Yes the file format changed with V13 and it's not feasible to convert a PRJ. However you can get that effect with the dissolve I mentioned earlier. Or... I took a look a John's PRJ and I'm not sure how it works since he hasn't used "render as lines" as I thought he did. Whatever he did can be done in V11 but he'll need to pop in to reveal it.

I dont' know the exact project but John's various tinkerings are in Tinkering Gnome's Workshop Give that a look.

Modeler of fine gothic cathedrals and , Stian has his birthday today. Happy Birthday, and may it be gargoyle free!

How about render the animation once as wire frame and once as "final" and then dissolve between the two? You could put them both as rotoscopes in a chor and adjust the transparency of the top one to reveal the other.

The light will need to be positioned so it would be visible as a reflection if the surface were a mirror. If the camera is 30° to the SW the light needs to be 30° to the NE or close to it. 2... have you animated any of those properties yet? gamma is not the problem here.

General rule: If a material allows you to do more than the properties of a group would have let you do, you'll have to render it to see it.

I recommend leaving the A:M setting at 1. That seems to get me images that look correct on everyone else's screen.

I find gamma explanations often confusing because depending on whether you are discussing an image making device or an image displaying device, the same number can mean opposite results in brightness and I suspect many writers on the topic don't' get that.

I've rendered some consecutive frames from the same baked CHOR in v15 and so far none of the momentary hair problems are occurring, so eventually I guess I'll need to boil this down into an AMReport regarding V16 or V17. Why not re-render in V15? Because stereo rendering with multipass (more than 1 pass) doesn't work in v15 and I need to render with multipass to get a saved depth buffer in OpenEXR renders and I need the depth buffer to use FakeAO.