robcat2075

There was a stretch in the 80's where VFX animators were doing something called "go-motion" where they would use wires or rods attached to the puppet to move it to get motion blur as each camera frame was clicked off. "Jurassic Park" was originally going to be a go-motion production, but CG animation ended all that.

(If I'm understanding your description) You need to extend the time taken to cover the path. Best way is to set the "ease" property in the path constraint. Set 0% at 0:00 and set 100% at some time you feel it would be appropriate to have covered that path.

We should investigate why that happened. It is EXTREMELY unusual for Netrender to produce a different result than A:M

Cool-looking beard! That reminds me of a cassette tape i pulled out of the dash a long time ago.

And, of course, you will not use any motion blur.

That looks very jolly! Thanks!

We had another thread here a bit ago where we were thinking about that http://www.hash.com/forums/index.php?showt...9&hl=jitter in brief... a bit of random motion (see my post#9) and animating at 12fps to make the strobing obvious.

Here's the essential problem... ...you can't know that new instructions are asking you to render something that has been already rendered until you have actually done them and compare the new to the old. That's the way I interpret it.

I didn't digest the entire "hungry renderer" description, but it sounds like hyperthreading as explained by Yves is a way to keep the CPU always working on something.

You might try a reset all settings in A:M then relaunch Netrender. Is that the latest v17d?

-Z-buffered Kleig light shadows may render faster than Ray-traced Kleig light shadows -Sun light shadows are ray-traced only but a distant Kleig light will look similar. -Turning "Cast shadows" OFF on hair will render faster. -Complex material can be baked into a bitmap for faster rendering. -Fewer lights render faster than more lights (mostly true with ray traced lights) -Regular render has anti-aliasing equivalent to 16 pass render, but is much faster.

they ought to be there but you could save a render Preset from the A:M render panel and use that in Netrender.

I looked at the last sample clip. Is it all like that? If you have any ray traced lights change them to z-buffered. If there are complex Materials on the models baking them might help.

Hard to know without seeing it. I could look at it if you want but you'd have to zip up EVERY asset it needs.

to bake hair right click in the chor window and choose "bake particles". the baking files will be written where ever the PRJ was saved. However your cloth hair looks promising too.

Most of those splines over the top of the head could be ended sooner with hooks.

If you turn off "Cast shadows" for hair it will render faster

For what it is worth...FakeAOGPU works for me in 64-bit v17 both as a render time post effect and as a post effect in a Composite However, both FakeAOGPU and FakeAOCPU crash my 32-bit v17 One other work-around for people who want to use 32-bit v17 but also want to have FakeAO.... Render without FakeAO in V17 to OpenEXR with a depth buffer, then use that OpenEXR file in a Composite in v16 to add the FakeAO as a Post effect. Of course this is more efficient for image sequences than single images, but if you tend to use FakeAO in Post anyway, like me, it's a minor commute.

Does this computer have a touch screen? I'd be curious to know if any of the touch interface gestures work with A:M.

For what it is worth...FakeAOGPU works for me in 64-bit v17 both as a render time post effect and as a post effect in a Composite However, both FakeAOGPU and FakeAOCPU crash my 32-bit v17

I'll note that you may have more success with modeled holes if the 5-pointers are from fairly squarish patches and if they come up to a ring around the hole rather than try to be the edge of the hole itself.

So make the object not-green?

OK, you made me install 32-bit v17 again. In a three way race I got v16b 32-bit 7:34 v16b 64-bit 5:57 v17c 32-bit 8:06 v17d 64-bit 5:05 So perhaps 32-bit v17 is a bit slower than v16 edit: I ran another test with 64-bit v16 in the mix and added the result above. So 64-bit v17 is faster than 64-bit v16 but 32-bit v17 is slower than 32-bit v16 In all cases the 64-bits are faster than the 32-bits. It's POSSIBLE that my and Nancy's results for the 32-bit versions are handicapped because we are running them on 64-bit CPUs.

Something is weird happening around the corner of the mouth. It looks like your smile line is connecting to the bottom edge of the lip. I'd have run it down to something below the lip.

The Frequency% is how much of the top clock speed the CPU is running at regardless of whether it is churning through any code. I have a 2.4MHx CPU but right now it is idling at only 1.6MHz. The usage% is how much of the available processing time is spent doing real stuff, regardless of what speed it is doing it at. If you are running One A:M on a two core machine 50% would be an expected number (100% use of 1 core out of two). your results sound reliable. I'd have to install 32-bit v17 to investigate more.