non-cached sim rendering behaviour

[super gnu]

im trying to do a grain sim, and to get decent detail, its necessary to disable cache and render directly while simming, otherwise id fill my ram after a few frames. 


however ive noticed that, after 17 frames,   the "updating objects" part  of the rendering is taking longer and longer each frame.. 

is it possible that it recalculates the whole sim from frame 0 each time it renders a new frame?

if so, i expect im never going to finish my render



i would expect it just to store the result from the last frame and advance it one frame before rendering the next one. 

if not, is there any way to achieve this result?

---

actually ive just noticed it *DOES* redo the whole sim from frame 0 for each frame. i can see it counting through the frames at the bottom of the screen.

blimey imagine a 1000 frame sequence.

i assume this is a bug, or a checkbox ive missed...

[tyFlow]

Can you send your scene to support@tyflow.com? It definitely shouldn't be resetting each frame.

Also for stuff like hires grain simulations, you'll want to use the "Export Particles" operator to cache your particles to disk, for faster playback/rendering. The tyCache format should give you identical results to the flow itself, or you can use PRT along with your own mesher.

[super gnu]

sent!

i will play with the export particles thing.

[tyFlow]

Hey,

So I looked at your file and the behavior is expected. Here is what's happening:

Because you have caching disabled, there is no information saved to RAM concerning particles states at a timestep other than the current one. So if you were to scrub backwards in time, the simulation would have to start fresh to get to any prior frame.

Because you're rendering with motion blur, VRay is essentially triggering that behavior itself. So if you render frame 10, in order to get a proper motion blur interval, VRay is querying tyFlow and saying "Could you please tell me particle transforms on frame 9.5 and 10.5" or whatever, to get the motion blur vector. As soon as tyFlow is asked for the prior frame (in that example, frame 9.5) it resets the sim to calculate that data, then continues forward to get to 10.5 or whatever.

So in your case there are two solutions: enable caching (which will take a lot of RAM, of course), or export your particles to another history-independent format like PRT, tyCache, etc...and render the cache instead.

Hope that makes sense!

[super gnu]

ahhh motion blur.. of course. might it be possible to have a cache option which saves only the couple of frames before the current one? might be useful? if i can get file export working i expect, as you say it is the correct solution.

many thanks for your help.