picture of Pixar scene with clouds/aggregate volumes, with a slide over - before image is wireframe boxes for the volumes, after image is the actual volumes

Why Aggregate Volumes?

Aggregate volumes are designed to tackle a key issue with the previous volume workflow in RenderMan.

Aggregate volumes are designed to optimize situations where individual volumes do not have any significant boundary behavior, such as that represented by the PxrVolume shader. The knowledge that rays will not reflect or refract at the boundary of a volume allows the renderer to perform significant optimizations which allow it to take much larger steps over all the volumes instead of continually having to start and end volume integration over many volume boundary intervals.

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.

Capabilities and Advantages

Aggregate volumes are fully supported by the PxrPathTracer and PxrUnified integrators. As noted above, aggregate volumes are designed 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).

Aggregate volumes also offer several advantages that are not available to non-aggregate volumes. They support mipmapped volumes, which can potentially reduce memory consumption for overly detailed volumes, and prebaked acceleration information, which can greatly reduce time to first judgement for renders. Aggregate volumes may also have faster convergence in complex light transport scenarios, as the renderer/integrator is able to make global decisions about sampling with information about more volumes in the scene.

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 Luca swimming in the ocean with 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).

The main limitation of aggregate volumes centers on the fact that a single acceleration structure is built over multiple volumes, and the acceleration structure does not store many properties of the individual volumes. This is for performance reasons; having to built an acceleration structure that is aware of all those individual properties would slow iteration over those volumes immensely. Thus, properties of a single volume that would affect ray traversal would not work with aggregate volumes unless specially handled; even then, adding that special handling would require us to add checks in the renderer with every tracking stop, instead of when determining the tracking length. In other words, it would be suboptimal. As an example of this, grouping the volumes into trace memberships and using ray subsets do work, but may not be as efficient as in the normal surface rendering case.

The main individual volume properties that does not work include:

• 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. 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: 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