...
Aggregate volumes are designed for workflows that involve many individual volumes which do not have any boundary behavior. The knowledge that rays will not reflect or refract at the boundary of a volume allows the renderer to perform significant optimizations over the set of many such volumes.
In the Luca cloud scene shown above, several dozen individual cloud elements have been layered together into a unified cloudscape. The aggregate volume workflow allow these cloud elements to be rendered efficiently without having to combine them into a single volume, which may be an expensive process external to the renderer.
...
The usual workflow for aggregate volumes is to create a named aggregate volume by attaching the Attribute "volume" "string volumeAggregateaggregate" ["name"] to one or more RiVolumes primitives, where "name" is the desired name of the aggregate volume. These volume primitives should use the PxrVolume shader to control their volumetric appearance. Once several volume primitives have been tagged with this attribute with the same name, 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. Control over how the volume is integrated and sampled is via parameters on the PxrPathTracer integrator.
If the data source for the volumes are OpenVDB files, the density signals comes directly from the file, and is not increased by shading, then it is highly suggested that the new Attribute "volume" "int dsominmax" be set to [1]. Doing so will allow the renderer to build an acceleration structure from the volume much faster using minimum and maximum values of the density, either by reading prebaked data directly from the VDB file or generating it on the fly at render beginas the volume is loaded. 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. If the volume density is derived procedurally in a shader, then dsominmax should be set to 0. An exception exists for cases when a quick density manipulation is desired: impl_openvdb supports new controls that allow for global scaling and shaping of the density while still supporting the dsominmax 1 optimization.
In addition, if the OpenVDB files are heavily detailed and it is anticipated that the files may be overly dense for what is required, the VDB files can optionally be preprocessed with vdbmake to generate mipmaps. Doing so may result in lower peak memory requirements as only lower levels of the mipmap pyramid will need to be loaded by the renderer. On the other hand, it may often be the case that loading two fine levels of the mipmap pyramid may use more memory than simply loading the base level of the pyramid; the OpenVDB file format in particular can make the advantages of mipmapping less obvious than would be seen in other potential volumetric file formats.
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. Unlike regular volumes, aggregate volumes are fully supported as a heterogeneous interior for PxrSurface. This is the best way for creating complex effects such as occlusions inside gemstones, or a swirling ball of smoke inside a crystal ball... or Luca swimming in the ocean with crepuscular light rays.
...
Mipmapping is a standard technique used to improve texture aliasing and rendering performance by automatically choosing an appropriate texture resolution level from a pyramid based on viewing size and angle of the texture on screen. This technique can also optionally be applied to volumetric data comprised of voxels: 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 each averaged from eight finer voxels. Mipmapping a volume asset will increase its disk space significantly, and may increase memory during rendering somewhat if the finest voxels are 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 using the impl_openvdb plugin as a data source for the volume primitives can enable mipmapping by setting the filterWidth parameter to a value greater than 0; this parameter is a multiplier on the standard filterwidth computed by the renderer.
...