...
In addition, aggregate volumes allow for a named set of volumes that can be used in special circumstances, such as binding a heterogeneous interior to the interior of dielectric surface.
Workflow
Capabilities and Advantages
...
In the initial 24.2 release, matte volumes against non-matte volumes may not completely correctly hold out each other. We anticipate that this will be addressed in an upcoming dot release.
Workflow
The usual workflow for aggregate volumes is to create a named aggregate volume simply by attaching the Attribute "volume" "string volumeAggregate" ["name"] to one or more RiVolume primitives, where "name" is the desired name of the aggregate volume. These RiVolume primitives should use the PxrVolume shader to control their volumetric appearance. Once several RiVolume primitives have been tagged with this attribute, the named aggregate volume can be supplied as the "volumeAggregate" parameter to the PxrPathTracer integrator. This signifies that the global volume aggregate for the scene is the named aggregate volume. The named volume aggregate will now appear in renders.
While typically the PxrPathTracer integrator can only render one global volume aggregate, any number of aggregates can be created. These aggregates can be bound as the interior to a closed dielectric surface that uses the PxrSurface material.
Mipmapping and prebaked acceleration
Mipmapping is a useful technique for 2D textures that allow for allows the renderer to efficiently load prefiltered versions of the a texture when the texture detail is much smaller than the filter size. Aggregate volumes support the 3D equivalent of this technique: much like This technique can be used for volumetric data as well. In much the same way that a 2D mipmap pyramid level contains texels that are averages of four finer texels, a 3D mipmap pyramid level contains voxels that are averages of each averaged from eight finer voxels. Mipmapping a volume asset will increase its disk space, and may increase memory during rendering somewhat if the finest voxels are relatively appropriate appropriately sized to the level of detail required for the camera; however, if the voxels are much finer in detail than the camera settings require, mipmapping can save significant RAM and render time . because the renderer will only load coarser averaged voxels instead.
Aggregate volumes also support reading prebaked acceleration information from a volume file. When the new Attribute "volume" "int dsominmax" is set to [1], the renderer can build an acceleration structure from the volume much faster if using minimum and maximum values of the density that are baked into separate mipmap pyramids in the file. This results in much faster time to first pixel as the renderer no longer needs to run density shading in a preprocess upfront before shooting rays. This optimization is only possible if the volume density is not altered (increased) by shading, and if the density signal comes directly from the file. If the volume density is derived procedurally in a shader, dsominmax should be set to 0. An exception exists: impl_openvdb now supports new controls that allow for global scaling and shaping of the density while still supporting the dsominmax 1 optimization.
...
The techniques used to approximate the look of deeply multiscattered volumes rely on altering the density properties of the volume based on the depth of the camera ray. For volume aggregates, the controls for this have been moved to the lights.
...
. For more information, please consult the tutorial on shading of clouds.