If you are rendering using Redshift or Arnold

…convert your files to vdb, both engines load vdb far faster than bcf. I find with large sims a Redshift render can spend several minutes loading a bcf and yet only need a half min or so to render. Of course this links up with using a fast HD preferably an SSD.
Bottlenecks…the ground is strewn with them.

This is unexpected. Could you post a simple test scene that reproduces this load-time difference?

OK will do when my machine is free

Last frame load/preparation times
Advanced render 33 secs
Redshift 1 min 9 secs ( 1070 and a Titan) no real difference in prep times just using the Titan
Arnold about 35 secs to start of render…so Arnold is not too bad rendrerloadtest.c4d (745.9 KB)

Did you test ?

I finally got around to look into this.
The frame setup speed difference (VDB export/import vs TFD direct) depends on the particular simulation. The cases where the VDB export/import approach has an advantage is when the volume is large (~200MV in this case) and much of it is empty. The VDB exporter will then have clipped away much of the empty space, s.t. it does not have to be processed during rendering. When loading the volume through TFD directly, it has to do something similar to that empty space clipping first and you’ll notice that in the frame setup time.
This issue will be history with the next release where all internal grids are sparse like VDBs are. Frame setup times will be further reduced for render engines that support sparse grids directly.

1 Like

Yes sparse grids will be a quantum leap, as will having the superb fine controls of TFD shading being used in Redshift. Basically from my testing only Arnold comes close to native TFD for looks but takes too much fiddling around, TFD native just works, no flicker, very little setup but slow…of course a render farm makes that a mute objection. RS is fast but a real pain to get decent fine detail in fire with GI scattering. If RS could simply read from the TFD native settings it would be a lot easier.