...

Aggregate volumes are fully supported by the PxrPathTracer and PxrUnified integrators. As noted above, aggregate volumes are designed to to be more efficient than the previous volume workflow in situations with tens or hundreds of overlapping volumes. This design also means that aggregate volumes are far less prone to issues that can arise when dealing with coincident geometry (such as coincident volume boundaries, or volumes coincident with surfaces).

...

Unlike regular volumes, aggregate volumes are fully supported as a heterogeneous interior to 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 a Luca swimming in the ocean with volumetric crepuscular light rays!

Limitations

Aggregate volumes do not support single scattering. Multiple scattering is the only choice.

Aggregate volumes are not optimized for strictly homogeneous volumes.

While aggregate volumes can be used as interiors to PxrSurface, aggregate volumes are not recommended for complex nested dielectric scenarios (e.g. tinted murky water inside a tinted glass inside a foggy room).

...

• visibility: aggregate volumes do not respect the normal visibility flags (Attribute "visibility" "camera"|"transmission"|"indirect") - the flags you might normally expect to set on the individual volumes. To get around this limitation, PxrPathTracer allows the specification of separate volume aggregates that are used when dealing with rays of a particular type: these are the volumeAggregateNameCamera, volumeAggregateNameTransmission, and volumeAggregateNameIndirect parameters to PbsPathTracer.  These These controls are not as flexible as the normal visibility flags - you cannot mix the visibility flags on the individual volumes of the aggregate - you can only operate on either the visibility of all aggregates, or specify which aggregates to use for certain types of rays.
• per volume sampling flags: the parameters on PxrVolume that control sampling techniques do not apply when using aggregate volumes. The controls for sampling are set in the main PxrPathTracer integrator. Name those parameters
• msApprox controls have been moved to the lights (see below)

Aggregate volumes are not currently supported in PxrVCM. They are fully supported in both PxrPathTracer and PxrUnified.

Matte: blah Mention matte volumes against non-matte volumes may not be entirely correct in 24.2?

Mipmapping and prebaked acceleration

...

mipmapping: why - mention increase in disk space and possible increase in memory if the voxels are appropriately sized. However, if overly dense, we expect mipmapping to save significant RAM and expense

prebaked acceleration: in conjunction with Attribute "volume" "int dsominmax" [1] the renderer can build an acceleration structure from the volume much faster if minimum and maximum values of the density are baked into separate mipmap pyramids in the file. This results in much faster time to first pixel. This is only possible if the volume density is not altered (increased) by shading, and if the density signal comes straight from the file. If the volume density is derived procedurally in a shader, dsominmax should be set to 0.

vdbmake is a new utility that creates OpenVDB files that have mipmapped grids and prebaked acceleration.

msApprox

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.

Joint Sampling