Date: Thu, 28 Mar 2024 21:45:35 +0000 (UTC) Message-ID: <2009908665.17.1711662335387@ip-10-0-0-233.us-west-2.compute.internal> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_16_417912346.1711662335384" ------=_Part_16_417912346.1711662335384 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
To create a volume aggregate, you can use the Volume Aggregate Editor, w= hich can be accessed from the right click menu in the viewport:
Hit the + button, to create a new aggregate. You can then start adding v= olumes that are in the scene to the aggregate:
You can also select the volume you want from the viewport and then add i= t to the group, from the right click menu:
To specify the global volume aggregate to the integrator, make sure an i= ntegrator node tree has been created (see Integrators in Blender), and then select the volume ag= gregate name in Volume Aggregate Name drop down list.
If a volume aggregate name has not been specified to the integrator, any= volumes that are part of a volume aggregate will not render
A= ggregate volume composition of cloudscape vs final render - Luca =C2=A9 Dis= ney/Pixar
Aggregate volumes are designed for workflows that involve many individua= l volumes which do not have any boundary behavior. The knowledge that rays will not reflect or refract at the bo= undary of a volume allows the renderer to perform significant optimizations= over the set of many such volumes.
In the Luca cloud scene shown abov=
e, several dozen individual cloud elements have been layered together into =
a unified cloudscape. The aggregate volume workflow allow these cloud eleme=
nts to be rendered efficiently without having to combine them into a single=
volume, which may be an expensive process external to the renderer.
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.
The usual workflow for aggregate volumes is to create a named aggregate =
volume by attaching the Attribute "volume" "string aggregate"
=
["name"]
to one or more RiV=
olumes primitives, where "name"
is the desired name of the=
aggregate volume. These volume primitives should use the PxrVolume shader to control their volumetric appear=
ance. Once several volume primitives have been tagged with this attribute w=
ith the same name, the named aggregate volume can be supplied as the =
"volumeAggregate"
parameter to the PxrPathTracer integrator. This signifies that the global vo=
lume 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.<=
/p>
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 dsominma=
x"
be set to [1]
. Doing so will allow the renderer to b=
uild an acceleration structure from the volume much faster using minimum an=
d maximum values of the density, either by reading prebaked data directly f=
rom the VDB file or generating it on the fly as 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=
code> should be set to 0. An exception exists for cases when a quick densit=
y 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 anticip=
ated 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 w=
ill need to be loaded by the renderer. On the other hand, it may often be t=
he case that loading two fine levels of the mipmap pyramid may use more mem=
ory than simply loading the base level of the pyramid; the OpenVDB file for=
mat in particular can make the advantages of mipmapping less obvious than w=
ould 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 heterogeneo= us interior for PxrSurface. This is the best way for creating complex = effects such as occlusions inside gemstones, or a swirling ball of smoke in= side a crystal ball... or Luca swimming in the ocean with crepuscular light= rays.
F= og beam layer with aggregate volumes bound to ocean interior, vs final comp= osite - Luca =C2=A9 Disney/Pixar
Aggregate volumes are fully supported by the PxrPathTracer and P=
xrUnified integrators. As noted above, aggregate volumes are designed t=
o be more efficient than the previous volume workflow in situations with te=
ns or even hundreds of overlapping volumes, and impose no limitations on th=
e number of overlapping volumes. Their design also means that aggregate
Aggregate volumes also offer several advantages that are not available t= o non-aggregate volumes. In situations where the density of the volume come= s directly from a VDB file and is not increased by shading, aggregate volum= es will usually offer greatly reduced time to first judgement for complex r= enders. Aggregate volumes also support mipmapped volumes, which ca= n potentially reduce memory consumption for overly detailed volumes. Aggreg= ate volumes may also have faster convergence in complex light transport sce= narios, as the renderer is able to make better global decisions about sampl= ing with access to information about more volumes in the scene.
It is anticipated that aggregate volumes will be the primary supported v= olume workflow in future versions of the XPU renderer.
The main limitation of aggregate volumes centers on the fact that a sing= le acceleration structure is built over multiple volumes, and the accelerat= ion structure cannot 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. Properties of a single volume that would affect ray tra= versal would not work with aggregate volumes unless specially handled, and = that special handling would require the renderer to perform extra checks wi= th every step in the volume. As an example of this, grouping the volumes in= to 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 do not work include:
volumeAggregateCamera
, volumeAggregateTransmission
, and volumeAggregateIndirect
paramete=
rs. 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 spec=
ify which aggregates to use for certain types of rays.minSamples, maxSamples, equiangularWeight
) =
do not apply when using aggregate volumes. Instead, the controls for volume=
sampling are set in the main PxrPathTracer integrator. Several limitations are also related to renderer optimizations that can =
work across many disjoint volumes. Aggregate volumes do not support single =
scattering; multiple scattering is the only choice, and the multiScat=
ter
parameter to PxrVolume
will be ignored. Aggregate v=
olumes are also not optimized for strictly homogeneous volumes. While the r=
endering algorithms are optimized for volumes that are close to homogeneous=
, they still assume that the aggregate volume as a whole is heterogeneous e=
ven if an individual element is homogeneous and cannot perfectly importance=
sample the volumes accordingly.
Aggregate volumes only support the use of the RiVolume
geom=
etry primitive.
High speed transformation motion blur of individual volumes will not be = as efficient in an aggregate volume workflow compared to non-aggregate volu= mes.
While aggregate volumes can be bound as interiors to PxrSurface, aggrega= te volumes are not recommended for complex nested dielectric scenarios (e.g= . tinted murky water inside a tinted glass inside a foggy room).
Aggregate volumes are not currently supported in PxrVCM. They are fully = supported in both PxrPathTracer and PxrUnified.
Multi-scattering optimizations are fully supported, but the relevant con= trols on PxrVolume are ignored on aggregate volumes. Instead, in the aggreg= ate volume workflow, those controls are now on the light sources themselves= .
In the initial 24.2 release, matte aggregate volumes may not correctly h= old out against non-matte volumes. We anticipate that this will be addresse= d in an upcoming dot release.
Mipmapping is a standard technique used to improve texture aliasing and =
rendering performance by automatically choosing an appropriate texture reso=
lution level from a pyramid based on viewing size and angle of the texture =
on screen. This technique can optionally be applied to volumetric =
data comprised of voxels: in much the same way that a 2D mipmap pyramid lev=
el contains texels that are averages of four finer texels, a 3D mipmap pyra=
mid level contains voxels that are each averaged from eight finer voxels. M=
ipmapping a volume asset will increase its disk space significantly, and ma=
y increase memory during rendering somewhat if the finest voxels are approp=
riately sized to the level of detail required for the camera; however, if t=
he voxels are much finer in detail than the camera settings require, mipmap=
ping can save significant RAM and render time because the renderer will onl=
y load coarser averaged voxels instead. Aggregate volumes using the <=
a href=3D"/display/REN24/OpenVDB+Implicit+Field+Plugin">impl_openvdb plugin as a data source for the volume primitives can enable mipmappin=
g by setting the
filterWidth
parameter to a value greater than=
0; this parameter is a multiplier on the standard filterwidth computed by =
the renderer.
vdbmake
is a ne=
w utility shipping with the RenderMan distribution to aid in the creation o=
f these optimized files in OpenVDB format. vdbmake
takes as in=
put an OpenVDB file with a set of grids, and creates OpenVDB files that hav=
e auxiliary mipmapped grids and prebaked acceleration information for those=
grids.
The techniques used to approximate the look of deeply multiscattered vol= umes rely on altering the density properties of the volume based on the dep= th of the camera ray. For volume aggregates, the controls for this have bee= n moved to the lights. For more information, please consult rendering clouds with a= ggregate volumes.