Choosing a composition to render

(...) If I start with the second animation, instead of the *first there is no prob, (...)

The animation selector causes quartz to crash on me running snow leopard 10.6.8. But besides that i can tell you that the image multiplexer you running both render and image through will only render either-or, I think you'll wat to investigate either a sprite for each render and image or piping them into a image overlay/blend patch. Ill dig into the comp a bit more...

Could you simplify the comp to demonstrate? When I pull particle renderer out of the RII inside the kineme particle RII patch, I can get it to work like I think you are asking, but it's only a guess....

Here it is a simplified version of the composition. I also did that. But didn't work. Maybe your 're doing it different than me. Can you send me you composition please?

Does this work for you? I think something is being extra lazy b/c of the render in image(s).

I'd also eliminate that render in image that's inside of the render in image, and push the blur stuff to the root level. Right now you're creating to rounds of render in image when it's not needed.

If you're feeling experimental you can try moving all of the particle scene outside of the render in image, and place just the renderers inside, and see if that eliminates the need for the stopwatch workaround I'm attaching. That's pretty likely to actually work. In general, there's no need to place the providing and processing patches inside of render in image patches, 3d transforms, etc., other than for convenience, and in edge cases, it can actually be the cause of some problems. The "environment" that the patches are placed in has to be in charge of making the subpatches execute, so you can sometimes get rid of the bugs by working around the way that patches are nested.

Yes that works for. But I tried what you said. I moved all the particle scene outside of the render in image and then there is no need of the stopwatch. Thank you very much for your tips. They're really useful. :-) Have a nice sunday and don't forget to change your watches' time!

Cheers,

That's what I figured. I've never delved in deep enough to figure it out, but there's something with the way the stock Render In Image patch works that is screwy with some Provider and Processor patches when they're placed inside. There's some kind of optimization taking place that causes things not to always evaluate correctly unless driven by certain other patches.

This reminds me that I have made a Render In Image that's "barebones" and doesn't do some of the weirder, arguably "not right" stuff that the stock Render In Image patch does. I'll try to remember to double check it some time and release it.

In general, for ultimate clean-ness, it's my take that all of the providers and processors in a qtz should be at the root level whenever possible. I guess iteration is one valid example where one needs to place some subpatches that do not render/consume inside of an iterator. Generally, only the rendering patches need to be placed inside of Environment macros, to "do" whatever it is that needs to be done, and the qtz's seem to run better when following this principle and keeping "nesting" to a minimum.

If you actually look at what happens to the qtz structure when macros are placed inside of macros, and look at how the graph (eg., the "qtz" patch chains) get evaluated, you start to realize it's akin to placing iterators inside of iterators, inside of iterators. It can overly complicate the structure of the qtz in cases where it's not absolutely needed to accomplish the task at hand.

...and thanks for the Sunday wishes. You too!

Thank you for your tips. They helped me a lot. They're really useful, and are very important for newbies like me.

Thanks a lot.