© 2019 Shotgun, Inc.

  • LinkedIn - Black Circle
  • Vimeo - Black Circle
  • YouTube - Black Circle
  • Facebook - Black Circle
  • Twitter - Black Circle
  • Instagram - Black Circle
Search
  • Teddy Gage

Volume Displacement and Motion Blur from TFD in Redshift C4D


I was working on a project the other day in Cinema and I was trying to do something I thought was relatively simple: Get motion blur out of a TFD sim in Redshift C4D. Turns out it wasn't. For more details scroll down. Here's how to get it working:

Turns out it was an issue with data channel conversion, (TFD encoding VDB channel data in a different way than RS expects) and there's now a new update to TFD build 1445 - specifically to the bcf2vdb utility. For those who don't know, this is a small, extremely fast and efficient command-line tool that converts your TFD .bcf file cache into an industry-standard VDB sequence usable in any renderer. Note: the VDB files will be about 20-30% larger due to TFD's compression. So make sure you have space on your cache drive before running the operation. They could likely be re-optimized in Houdini.

Here's how you do it:

Download the new TFD update, go into your plugin folder and find the bcf2vdb folder.

Watch this video on how to use it:


There's a new option - simply add the "-s" flag during the bcf2vdb conversion operation to split the velocity into 3 discrete channels.

You'll now get the proper velocity.x / y / z etc channels to plug into the Redshift VDB volume object (slots are on the object attributes in the main tab). Then you can play with the various motion blur settings and it works as expected.

Note - multiplying the velocity vectors has more of an "upscale" or "displacement" effect than a blurring effect - this is great for adding detail but can deform the sim (usually makes it bigger) and cause some strange artifacts.


Warning: Render times explode with an increase in the velocity scale. For reference a scene with vel scale = 10 was 1 minute / frame. The same scene with vel scale = 30 was almost 6 minutes / frame. So use it sparingly. This happens entirely on the pre-processing pass and can't be mitigated with render settings.

More details:

So the problem was this: the native TFD container has a velocity.x y and z channel, but it can't be accessed as a data input by Redshift to use for motion blur. The strange thing is that you can use it as a channel for visualization in the scattering or absorption slots, but the vectors, for whatever reason, can't be applied to Redshift's vector blur. Adding a Redshift Object tag to a TFD container leaves no X, Y, Z slots for adding those channels either, unlike a native VDB container. They simply don't exist in the tag.




When you look on the render global settings for a scene with TFD, there's a "Turbulence FD" post effect with a "fluid motion blur" setting, but sadly this does not work with Redshift as your engine either. With a deadline looming, I was starting to get nervous.

So my next thought was "oh there's the bcf2vdb utility included in the plugin folder" surely Redshift can access motion blur via the converted VDB object. Right? Not so fast. At the time, the converted VDB of my object only output a single cached channel called "velocity" into the vdb. This seems fine until you see the input fields for motion blur on the Redshift volume object. It has three separate fields for the X, Y, Z split vectors. I'm not sure why this is, but my guess is, it has to do with the traditional split vector channels from older sim software like Realflow, which generates those as vertex maps for deformation blur on meshes with changing topology.

So I took a closer look at the VDB itself and realized these had to be actual discrete channels, and this was a bigger problem than I realized. I spoke to my good friend David Torno, who in turn contacted Jascha the lead developer of TFD, and was quickly informed I should restart Cinema and pull a new update, this build 1445. And it worked. I'm still working on getting smooth long trails and flowing mists but it's a huge improvement for the workaround available, namely: doing it in comp.


973 views