|
| Redshift demo volume |
Table Of Contents
OpenVDB files are to volume rendering what EXR files are to HDR image files. While an EXR texture stores pixels, an OpenVDB file stores voxels - these can be thought of as three dimensional pixels. Each voxel stores information that describes the volume at a particular point in 3D space. For example, it can store a density value which tells the renderer how opaque or transparent to make the volume at each specific location.
Please note that if any SOPs are added after a VDB file is loaded it is no longer a render time procedural, this is less efficient on memory and scene extraction time will take longer.
For best results, cache volumes as OpenVDB and load them with a File SOP set as the render node directly.
Volume objects are not compatible with light linking.
OpenVDB organizes its voxel data into grids.
VDB grids may also be referred to as channels, particularly in a shading context, and Redshift uses the channel terminology when referencing a VDB grid in a volume shader.
An important thing to remember with OpenVDB channels is that they each have a unique name assigned to them. For example, volume density information could be written to a channel named "bob" and still function exactly the same as the more common channel name "density." Thankfully, most applications follow fairly standard naming conventions but the key thing is to know what channels are contained in your VDB file - to know each channel's name and its purpose.
The reason this is so important is because volume channels tell Redshift exactly how your volume should be shaded, and you are likely to get vastly different results from each channel because they tend to have very different uses. For example, temperature should be used to drive volume emission for realistic flames and explosions by making use of blackbody emission rather than using the density channel which is tailored for describing thick plumes of smoke or clouds.
Velocity channels are expected in either two forms:
A single velocity grid in the float vector type which contains all the XYZ information in one grid.
Example: velocity
Three separate float scalar velocity grids that pertain to X, Y, and Z individually.
Example: velocity.x , velocity.y , velocity.z
For information on how to use the velocity grids please see the motion blur section below.
The Redshift Log File can be used to find out which channels are contained in an OpenVDB file. When Redshift loads an OpenVDB file, it prints out the names of all the channels it contains. Here is an example of how this looks in a Redshift log file:
Preparing volume objects...
Loading: C:\demo\redshift_volume_demo\RS_Vol_Demo.vdb
Contained grids: 'density' 'temperature' 'velocity'
Done! Dim: (243, 356, 245). Num loaded grids: 2. Num voxels total: 16828480
Time to process 1 volume objects: 0.7s
As you can see in the code snippet above, three grids were found: density, temperature, and velocity - these names can be used for shading and motion blur in Redshift.
Similar to the way the clarity of an image is defined by its resolution a voxel grid has resolution as well. While a low resolution image will look jagged or pixelated, a low resolution volume will look blocky. A volume that is simulated at a higher resolution will look smoother, it is important to create a volume with the appropriate resolution for your scene and its distance from the camera. The advanced remapping parameters of the volume shader can be used to help alleviate some of this blockiness but it is a tricky balancing act that may require sacrificing too much of the desired look of your volume, so ultimately what is most important is the actual resolution of your volume simulation.
|
|
| Redshift demo volume |
Download Redshift demo volume VDB (242 MB)
Other resources:
OpenVDB official Sample Models
Cloud by Walt Disney Animation
JangaFX Free VDB Assets
Houdini does not have a Redshift specific volume object, instead the native Houdini volume tools are used so any Redshift specific volume settings are instead found in the 'Volume' tab of the 'Redshift OBJ' tab which are found on Houdini geometry nodes.
Please note that if any SOPs are added after a VDB file is loaded it is no longer a render time procedural, this is less efficient on memory and scene extraction time will take longer.
For best results, cache volumes as OpenVDB and load them with a File SOP set as the render node directly.
To make a VDB loader in Houdini create a File sop. In the image below you can also see the Redshift Volume settings outlined, these are covered in the parameter settings on this page.
|
Next set the field to an OpenVDB file on your computer as outlined in the image below, for this demo we will load the "RS_Vol_Demo" VDB. The VDB should now be loaded into the scene and visible as a bounding box in the viewport.
Volume objects must be stored on a GPU's memory in their entirety, volume rendering is not handled by Redshift's out-of-core system. Therefore, if a scene uses too many volume objects (or if these volume objects are of a particularly high resolution) and do not fit on the GPU's memory, rendering will be aborted with an out-of-VRAM error message.
|
All that remains is to configure a Redshift Volume shader and then rendering can commence! For information on volume shading, please see the Volume Shader page.
|
Houdini does not have a Redshift specific volume object so the settings covered below are instead found in the 'Volume' tab of the 'Redshift OBJ' tab that can be found on Houdini geometry nodes.
|
When enabled, removes negative values found in the volume which Redshift does not support. Voxels with a negative value will be set to 0.
When enabled, removes any voxels with a value above the Degenerate Voxel Threshold, this can be useful to remove volumes with extremely high values that might cause issues with shading.
Sets the upper limit for the for the Filter Degenerate Voxels parameter, any values found above the voxel threshold will be set to the threshold value.
When enabled, Redshift cleans color Cd type volume grids by removing voxels that are not enabled to avoid rendering artifacts.
Volume Padding expands the volume bounding box allowing for greater volume displacement, this is measured in voxel size of the loaded VDB.
Very large values may increase render times.
Volume displacement is always limited by a volume's bounding box. When displacement values are high enough, the volume gets cut off at the bounding box limit as seen in the example below.
| Volume displacement limited by small bounding box |
When this occurs, Volume Padding can be increased to expand the size of the bounding box allowing for full displacement.
| Increasing Volume Padding |
|
Motion blur simulation is a bit different with volume files as they are stored frame by frame rather than, for example, an object animated via keyframes where the speed and motion curves can be accessed at any time. The solution for this is recording speed information to a velocity grid which can be included in a VDB file. Either separate XYZ grids with float scalar values or a single velocity grid with float vector values is required.
Enables the use of velocity grids for volume motion blur.
Enter the names of the three appropriate velocity channels that include the x, y, and z components here.
If you only have a single 3D velocity channel with float vector data you can add it all by itself to the Velocity Grid X field and Redshift will handle the rest.
Velocity scale is a multiplier for the velocity grids to increase or decrease the motion blur intensity of a volume.
Depending on the values in the velocity grid, velocity scale may have to be increased dramatically before motion blur becomes visible.
|
|
|
|
| Velocity Scale: 1 | 1000 | 10000 | 50000 |
When enabled, Houdini can render delayed loaded OpenVDB files from SOP Packed Disk primitives. Instancing of these OpenVDB files is also handled automatically and you can override the transformations and materials of each packed disk primitive.