 |
|
|
|
UsdLux provides a representation for lights and related components that are common to many graphics environments and therefore suitable for interchange.
The goal of UsdLux is to serve as a basis for:
The UsdLux core includes:
This core can be extended to add more types of lights, filters, or other features.
For a comprehensive list of the types see the full class hierarchy.
UsdLuxLightAPI defines all the common attributes and behaviors that are considered to be core to all lights. Thus, we define a UsdLux light as any prim that has a UsdLuxLightAPI applied. In other words, applying a UsdLuxLightAPI imparts the quality of "being a light" to a prim.
Most light types, such as UsdLuxRectLight or any type that inherits from UsdLuxBoundableLightBase or UsdLuxNonboundableLightBase, have an applied UsdLuxLightAPI automatically built in to their type and therefore will always be lights. However, by attaching the quality of being a light to an applied API schema, we can turn any geometry into a light by applying a UsdLuxLightAPI to it, or, as we would in the case of a UsdGeomMesh to which we'd apply UsdLuxMeshLightAPI, by applying an API schema that itself has a built-in UsdLuxLightAPI.
By convention, lights with a primary axis emit along -Z. Area lights are centered in the XY plane and are 1 unit in diameter.
UsdLux objects are UsdGeomXformable, so they use its set of transform operators, and inherit transforms hierarchically. It is recommended that only translation and rotations be used with the lights, to avoid introducing difficulties for light sampling and integration. Lights have explicit attributes to adjust their size.
UsdLux provides the UsdLuxLightAPI, which can be applied to arbitrary user-supplied geometry, as well as concrete lights for specific shapes: spheres, rectangles, disks, and cylinders. The specific shapes exist because they can support superior, analytic sampling methods.
UsdLux is designed primarily for physically-based cinematic lighting with area lights. Accordingly, it does not include zero-area point or line lights. However, some backends benefit from a point or line approximation. This intent can be indicated using the treatAsPoint and treatAsLine attributes on UsdSphereLight and UsdCylinderLight. These attributes are hints that avoid the need for backends to use heuristics (such as an arbitrary epsilon threshold) to determine the approximation. These hints can be set at the time of creation (or export) where the most information about the visual intent exists.
UsdLux does not provide support for expressing live transform constraints, such as to attach lights to moving geometry. This is consistent with USD's policy of storing the computed result of rigging, not the rigging itself.
Colors specified in attributes are in energy-linear terms, and obey the USD convention for indicating their color space via colorConfiguration and colorSpace metadata. See UsdStage::SetColorConfiguration() for discussion of colorspace management in USD.
UsdLux presumes a physically-based lighting model where falloff with distance is a consequence of reduced visible solid angle. Environments that do not measure the visible solid angle are expected to provide an approximation, such as inverse-square falloff. Further artistic control over attenuation can be modelled as light filters.
More complex behaviors are provided via a set of API classes. These behaviors are common and well-defined but may not be supported in all rendering environments. These API classes provide functions to specify the relevant semantic behavior:
Like other USD schemas, UsdLux core may be extended to address features specific to certain environments. Possible renderer- or pipeline-specific capabilities that could be addded as extensions include:
We provide a utility to aide in extending the UsdLux core schemas, namely the schema generation script usdgenschemafromsdr. This script can be used to generate new light schemas from the shader nodes in the SdrRegistry. These light schemas can be typed schemas that describe a completely new light type or can be applied API schemas that extend an existing light type automatically by being specified to auto apply to an existing light (such as UsdLuxDiskLight) or light API (such as UsdLuxMeshLightAPI).
We expect "published, pipeline citizen" render delegates to provide codeless schema libraries that contain typed schemas and/or applied API schemas that define or extend all of the renderer's core light types. But some render delegates may be developed as part of a proprietary application package that is only using USD as a mechanism to communicate to that render delegate. In other words, the application doesn't really want to participate in the open USD ecosystem, but needs to use it for rendering scenes imported from USD and augmented using application/renderer-specific lighting features, or finds it useful to use USD as an archiving format to send jobs to a render-farm so that the full application need not be run there.
In order to lower the barrier somewhat for such applications, we provide UsdLuxPluginLight and UsdLuxPluginLightFilter, concrete schema types that specify a "node identification" encoding just like UsdShadeShader, so that the application need only plug its extensions into Sdr (by providing node definitions that will be consumed by render delegates), and not be required to take the extra step of generating USD schema definitions. Because they provide less easily accessible information to users, we do not advocate using these types in pipeline-persistent "user-level" USD files.
1.9.6