You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For a number of renderers, including Arnold, V-Ray, and also our internal proprietary renderer, these lights represent size as an attribute:
DiskLight: radius
RectLight: width, height
SphereLight: radius
In UsdLux representation, the size of these lights is fixed at 1 (radius = 1, or width = height = 1), and it appears that the size of the light is controlled by scaling the transform on the light itself. This presents a conflict when representing a light for most renderers using UsdLux.
If we apply the light size as part of the transform on the light itself, the light will be correctly represented in USD but loses the explicit differentiation between what is meant as the light size, and what is meant as the transform on the light.
We could represent light size as its own custom transform attribute and add that transform to the transform stack on the light, but this feels error-prone. It would simply have to be known that the transform stack on the light needs to include this extra transform, and that the transform is only used for light size, and overrides should not remove that transform from the list. It becomes an internal standard by convention, with no means of enforcing the convention.
If we apply the light size as a custom attribute, we no longer have a universal light representation, and USD importers and Hydra would need to be customized to support that attribute. To me, "U" is the most important letter in the USD acronym, so this solution is not appealing.
I propose updating the schemas for these lights to support radius (DiskLight and SphereLight), and width and height (RectLight) as first-class attributes. This change could be entirely backwards-compatible, if the default value for these new attributes is set at 1. I also feel like it would bring UsdLux in line with UsdGeom - for example, Cylinder defines height and radius, Sphere defines radius, etc.
Proposed improvement
Add these attributes to these light schemas:
Schema
New Attributes
SphereLight
radius (float)
DiskLight
radius (float)
RectLight
width (float) height (float)
System Information (OS, Hardware)
all systems, all hardware
Package Versions
v0.8.0+
The text was updated successfully, but these errors were encountered:
Description of Issue
For a number of renderers, including Arnold, V-Ray, and also our internal proprietary renderer, these lights represent size as an attribute:
In UsdLux representation, the size of these lights is fixed at 1 (radius = 1, or width = height = 1), and it appears that the size of the light is controlled by scaling the transform on the light itself. This presents a conflict when representing a light for most renderers using UsdLux.
I propose updating the schemas for these lights to support radius (DiskLight and SphereLight), and width and height (RectLight) as first-class attributes. This change could be entirely backwards-compatible, if the default value for these new attributes is set at 1. I also feel like it would bring UsdLux in line with UsdGeom - for example, Cylinder defines height and radius, Sphere defines radius, etc.
Proposed improvement
Add these attributes to these light schemas:
height (float)
System Information (OS, Hardware)
all systems, all hardware
Package Versions
v0.8.0+
The text was updated successfully, but these errors were encountered: