|
| 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.
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.
Redshift provides a list of all the available channels contained in a VDB in the Information section of the Redshift Volume Object.
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
To create a Volume object, select Add RS Volume from the Add menu to create a Redshift volume object without a new volume material assigned to it. If you select the Add RS Volume & Shader option a new volume object will be created with a new Redshift Volume shader already assigned to it.
|
Next set the Filename 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.
|
For better viewport visualization the Display mode can be changed to something like points. Use the maximum points and prune threshold parameters to balance viewport performance with the visualization of the volume, for more information see the display settings below.
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.
|
|
|
The following settings manage the import process of VDB files and allow you control the playback of animated VDB sequences.
Specifies which VDB file or sequence from your computer will be used for volume rendering.
When enabled, all VDB files found in a matching sequence will be loaded and animated with timeline playback.
Frequently Start Frame should be 0 to start the sequence with the first VDB file but this can be used to trim unnecessary frames from the beginning of a VDB sequence.
This value will offset the number of the VDB file within a sequence. For example, using Offset 3 would use the third file of the sequence as the new start frame. In this case, the first two files in the sequence will be handled as if they are the last two files of the sequence, so in total the amount of files in the sequence will remain constant.
|
Blender has a number of nice VDB preview options for controlling the display of your volume in the viewport. You can choose from several different display styles like bounding box, points, boxes and even a volume slicing mode that renders a single sliver of the loaded VDB to get a basic understanding of the volume's shading as seen in the example images below. The Detail option can be further adjusted between 'Coarse' and 'Fine' to control how detailed the preview is.
|
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.
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 |
|
Displays all the available VDB grids found in the loaded file that can be used for driving volume shading and motion blur.
