[polynurb]

i believe to remember from an earlier thread that it is not so easy to achieve, but some way allowing (eg. after mishaps) to recover the ram fire uses within rhino would be a good thing.

here i got the wrong density map.. so too much grass was generated.
but i don't find a way of releasing the ram.




also a faster killing of the fire process would be great , like possible with "quit" in maxwell.exe

[JDHill]

The only reason you can quit faster in maxwell.exe is because when you do it, the whole process is torn down. The analog of this in the plugin would be if it gave you a button where when you clicked it, the plugin immediately killed Rhino.exe. As that is not an option, we have to wait for any working render threads to stop cleanly, ready to start again.

Regarding releasing memory, the plugin keeps FIRE data in memory until you do anything that invalidates it -- creating/deleting/moving an object, and so forth. Otherwise, a full export would need to be done every single time you enabled FIRE. As far as how memory is released, it is done by asking the engine to free its data; if any memory is not freed, it would either be because some code wants to keep it, or it could be due to a bug. In the second case, it would likely be due to some very specific conditions and sequences of actions; testing with grass in particular, I am able to observe memory being held without apparent explanation, but it is not easy to see a pattern to it; usage will increase substantially if I move the grass-enabled object during rendering, but then when memory is requested to be released, most of it is, but not all. I'll try to find a pattern to this and make a report.

[polynurb]

thanks for the info.

when handling certain files/situations a lot of time is lost by waiting for fire to stop/start.
it is also partly because i can't use the grass lod in fire and so a wrong setting causes more trouble.

[JDHill]

I'll be looking into the LOD issue later today.