 |
|
|
|
UsdVol provides schemas for representing volumetric geometry.
UsdVolVolume can be used to represent continuous volumes (smoke, fire, etc), and can load spatial field definitions directly from OpenVDB and Field3d assets; it can also be extended to support other volume formats. The fields comprising a volume prim are represented as distinct prims whose schema types derive from UsdVolVolumeFieldBase, to distinguish them from particle fields.
UsdVolParticleField can be used to represent a family of related lightfield techniques that define their spatial presence through a set of 3d particles. This schema was introduced to support 3d Gaussian splats, but is designed to be extensible and support things like Nerfs as well as future evolutions of this field of technology.
UsdVolVolume schema describes a volume composed of multiple fields. A field is a "grid" in OpenVDB terminology. Volume is a UsdGeomGprim, so it is transformable, renderable, can have a material binding, etc.
A Volume has one or more named relationships to FieldBase prims.
UsdVolFieldBase is an abstract schema representing a single volume field. This schema should be inherited by any schema representing a volume field.
UsdVolFieldAsset inherits from FieldBase and is an abstract schema representing a single volume field that is stored as an asset separately from the layer or stage. USD does not currently support data types required to represent volumetric data directly, so volumes are generally stored using purpose-built file formats such as OpenVDB. This schema should be inherited by any schema representing a volume field stored as an asset outside of USD.
As field asset formats may store multiple fields in a single asset, UsdVolFieldAsset contains properties fieldName and fieldIndex to aid in selecting the single desired field.
UsdVolOpenVDBAsset inherits from FieldAsset and is a concrete schema representing a single volume field stored as an OpenVDB asset.
Learn about OpenVDB at https://www.openvdb.org/.
UsdVolField3DAsset inherits from FieldAsset and is a concrete schema representing a single volume field stored as a Field3D asset.
Learn about Field3D at https://sites.google.com/site/field3d/
Here is a simple example of a Volume prim, representing a static wisp of smoke:
Volumes are generally not static. For volumes with OpenVDBAsset fields, volume animation is represented by setting time samples on the filePath attribute:
UsdVolFieldAsset describes a single field that can be loaded from an external asset. FieldAsset has a filePath attribute that specifies an asset path where a volume file can be found.
Field prims are not required to be children of the Volume prim. But in most cases the Volume and its Fields are conceptually inseparable, so Field prims are generally created as children of the Volume prim for organization purposes, ease of referencing, and overall ease of use.
Relatedy, the grid extracted from a Field prim is positioned in world space by the local-to-world transformation of the Field prim, plus any transformation contained in a FieldAsset's external asset encoding. This semantic makes clear why organizing Fields under a Volume is useful: re-positioning the Volume prim will automatically move all its child Field prims along with it.
The Volume prim must establish named relationships to its Fields using the UsdVolVolume::CreateFieldRelationship() method. This is how the "field:density" relationship is created on the Volume prim in the examples above.
The naming of the field relationship on the Volume prim and setting a fieldName on the OpenVDBAsset may seem redundant, but it is not. The intention is to allow a Volume to define fields by the names appropriate for the Volume and/or pipeline, without tying these to the VDB grid name. For example, a Volume might want a "velocity" field for the purposes of shader parameters, but you have a VDB with a grid named "vel". Defining field:velocity on the Volume prim would accomplish that. You can also re-use Fields for multiple volume fields in this way.
USD does not have a way to describe volumetric data structures. This is similar to how textures are not FileFormat plugins either - USD does not have data structures to represent image data. In both cases, It can be argued that USD should not do this. A VDB can be thought of as a 3D texture for this purpose, so the OpenVDBAsset schema describes an asset path where it can be discovered for someone else (Hydra, your renderer, etc) to interpret.
Particle fields are an area of rapidly evolving research, and so here we opt for a structured, but dynamic system to define their data model in USD. All particle fields are built on top of a common concrete base type ParticleField. Applied schema are used to define how all the necessary data used to define the specific particle field are delivered.
There are certain categories of data required to describe the particle fields, these are discussed in more detail below, but the applied schema that define each category of data automatically apply a base applied schema. This behavior is similar in concept to an abstract base class in C++, and is intended to allow for robust validation of the conceptual structure of a particle field.
As commonly used, particle field configurations evolve across the industry, we will create concrete schema types to specify these combinations of applied schema (See ParticleField3DGaussianSplat below). This provides the more typical, fully specified data layout we see in other USD schema, and it intended to deliver practical schema that can be used in production environments.
The ParticleField concrete schema type is the base type of all particle fields. Various applied schema are appended to this base type to define the various characteristics of the particle field.
All ParticleField are required to provide the following attributes, but are free to provide them in any form.
Other optional attributes that may control the kernal instance are, but are not limited to:
As outlined above the schema that provide data in each category of required attributes above all automatically apply a base applied schema to aid with validation of a fully constructed ParticleField.
The following list of schema all provide their respective data to the ParticleField directly in the form of plain attributes. They all use the suffix AttributeAPI to differentiate them from future alternate representations of the same underlying data. We believe there may be future schemata that provide the same data with a different representation, e.g. as a Multi-Layer Perceptron (MLP).
The kernel schema for a ParticleField is responsible for defining both the shape and the falloff function of the kernel that is instantiated at each particle in the ParticleField.
The shape should be fully defined in the description of the schema, potentially using locally defined attributes if the shape needs to be configured. This description should include the default scale and orientation of the shape.
The falloff function is used during rendering to determine the local region of influence of the kernel, with respect to the local space of the shape.
The radiance schema for a ParticleField is responsible for defining the appearance of the particles. Initially we provide ParticleFieldSphericalHarmonicsAttributeAPI to define the spherical harmonic coefficients use in traditional 3D gaussian splats. This is an active area of research and we expect additional schema to be defined that describe the particle field radiance.
We expect there will be future research in the area of particle field appearance. Their appearance may be described using an external material description. We consider the local definition of radiance to be analogous to displayColor in UsdGeom. Meaning, if a material is bound to a ParticleField location, then the material description should be used instead of the locally defined radiance.
1.9.6