Whether to bake the light fields together before raymarching through them. Rasterize Volume tends to take longer to run when this option is off because the OpenCL kernel must iterate over 4 uncombined VDBs simultaneously, which requires many shader registers. It’s possible to iterate over 2 VDBs instead: a density field and a “light” field (the combination of diffuse and emission), however, in order to combine the fields this way, the fields must be remapped before starting to raymarch, meaning they must be remapped at voxel positions, not at interpolated positions while raymarching. So, having this option on decreases quality and makes the output look more blocky; if you want higher quality output, turn this off.

To determine the amount of diffuse light at any point, we use the formula diffuse_field x (1 - e^(-density x step_length)). This essentially means the density field and the diffuse field must be multiplied together. There are 2 ways of doing this. One way (this option toggled off) is to sample the two fields at the given sample location and multiply the interpolated values together. Another way (this option toggled on) is to find the 8 voxels surrounding the sample locations in the density field and multiply these by the corresponding voxels in the diffuse field before linearly interpolating the 8 voxel values at the sample location. The former way is faster but less accurate, and the latter is slower because it must remap each field 8 times instead of once, but it is more accurate. One case where this option makes a difference is near the boundaries of the active region of the density field. One might expect regions with zero density to not contribute any colour to the final raster.

Consider sampling halfway between a voxel with nonzero density and an inactive density voxel. In the colour field, you might have some non-black colour where the density field is nonzero and a black background color. If we sample halfway betweent these two voxels, the interpolated density will be nonzero but the interpolated colour will be darker because it will be halfway between black and the active voxel’s color. This results in the boundary of the active region looking darker than it should. When this option is turned on, we first multiply the density and diffuse fields and see that the inactive voxels with black color don’t contribute to the final output because they have zero density.

This option only really makes a difference when the density changes very quickly from inactive (0) to some very high density. For rasterizing pyro simulations this option probably won’t make much of a difference because density tends to vary somewhat smoothly, so it’s best to leave this option at its default setting of off, since that will result in better performance.

Length of ray slices. This is the expected distance between samples when samples are jittered.

Used to prevent the OpenCL kernel from running forever or timing out. You shouldn’t need 4096 shouldn’t need to be changed unless rastering a very deep volume.

The transmittance of the accumulated portion of the ray after which to stop raymarching. This is an optimisation for the case where a very dense region of the volume is encountered: almost none of the light from behind this region will reach the camera so we can stop raymarching early to save time. Due to rounding error, it is possible for the accumulated transmittance to reach 0 despite this not being physically possible, and this will be seen when rasterizing very dense volumes. Thus, completely disable this option (and force raymarching to continue until the ray exits the volume’s bounding box) you can set it to -1, but there should be no difference in the output between 0 and -1.

Makes the sample location jittering depend on time.

The amount by which to jitter sample locations. When this is 0, sample locations are always at the centres of ray slices. When this is 1, sample locations can be drawn from anywhere along their respective ray slice. There will never be more than one sample drawn per ray slice.

The amount by which to jitter ray slice locations. When this is 0, the start of ray slice #0 coincides with the ray origin. When this is one, the start of ray slice #0 varies from backward and forward along the ray by half the step length. This is a single offset applied to each view ray, not per sample.