BCF vs VDB..BCF WINS HANDS DOWN

Workflow
1

I like most of you find conversion to vdb a pain, not least for the threading and cpu utilization…it seems very archaic. That is one reason I have favoured Arnold over Redshift. Though RS will render the bcf files there is a massive overhead on loading/converting them but vdbs do render order of magnitudes faster than bcf for redshift.
Arnold not only works with bcf seamlessly out of the box…it is faster to render bcf than vdb. Here are two test frames. the bcf rendered in 56 seconds and the vdb in 3 m 32. There is some very slight difference in lighting.
Arnold shades beautifully just using TFD with no volume shader and you can tweak away inside the TFD render settings. If you do add a volume material tag you also get the benefit of mixing and matching. You can set up volume shading inside the Arnold volume shader and still get access to all the graph functions inside TFD as Arnold is getting it’s data from the TFD container…NO NEED FOR PESKY CLUNKY TIME CONSUMING VDBs. However Arnold will render TFD on the GPU it is just a bit flaky at present and it does require VDBs. Note the bcf file is 203,367 kb and the vdb is 246,102 kb

bcf56sec
bcf56sec1920×1200 19.8 KB

vdb2m32s
vdb2m32s1920×1200 19.6 KB

Here is the scene bcfbdb.zip (103.6 KB)

2

Render times are for an I7 3930 I7 6 core at 3.5 Ghz and 64 GB Ram, simmed on a Titan X 12 GB. I will fire up the dual xeon later and amuse myself with it’s speed !!!

3

VDB has inherent complexity that makes it slower to read and write than BCF. That’s something that will be hard if at all possible to get rid of. But that is only one part of the resulting performance. As you have measured, there seems to be other issues at play in RS that are more likely to be resolvable. We’ll revisit this issue soon-ish when upgrading the SDK for upcoming releases.

1 Like