UsdPreviewSurface does not specify range or units of emissiveColor

[jcowles]

Description of Issue

The UsdPreviewSurface spec doesn't specify the valid range for emissiveColor, but it's effectively a light and could be physical or non-physical units.

For example, in Unity's HD render pipeline, this value is measured in Nits, which means the scale is much larger than [0,1], however it seems most consumers of USDZ expect the value to be in non-physical [0,1] units, e.g. AR Quick Look expects [0,1] and does not clamp this value, which results in super blown-out emissive values when expressed as physical units.

Seems like this should be part of the spec, no?

Comments from @poljere:

Indeed, we will need to be more explicit in the spec with both the range of values and the units of the values. The original intent was to keep it simple and portable, and let the user communicate an emissiveColor as [0, 1] values. Of course, if you wanted to play with greater than one values, you could use the UsdUVTexture.scale in 20.08 but, as you said, it is not really portable.

Package Versions

USD 20.08

[spitzak]

I would certainly expect the units to be exactly the same units used by a non-normalized area light. I think this means that 1.0 produces 1.0 in the output image if the light is directly rendered.

[jtran56]

Filed as internal issue #USD-6237

[erich666]

Raising my hand on this one, too. There's two parts to this one: how does the emitting surface look, and how much light does the surface emit into the environment.

For "how does it look?" @spitzak 's comment is about right - in 1990's OpenGL sort of shading, emissive color is just the color you add in at the end of the shader, unaffected by anything else. This is in some sense OK, though people dealing with cameras and exposure levels might not be happy. I think most renderers go this sort of route, but it's inconsistent, since not well defined currently. If texture scaling is applied to an emissive texture (in order to have the surface emit more light elsewhere), the colors can get blown out - see the UsdView here.

For "how much does it emit?", which is important if you want to use ray tracing or substitute in virtual lights for emissive surfaces in a rasterizer, "nits" is a fine unit for this. Currently, most renderers I have tested do not use this, e.g., see my tests and analysis here.

[spiffmon]

@erich666 , declaring nits as the units would be in alignment with the currently-undocumented history of UsdLux, and, I believe, with what @anderslanglands has proposed recently in PR #2758 (which I haven't read yet).

Taken alone, though, that might exacerbate the blowout problem in your part 1? My suggestion would be that we additionally add guidance that emission intensity generally be controlled not directly with inputs:emissiveColor, but rather by applying a LightAPI schema to geometry bound to the emissive material, which will provide all the other standard emission-tuning controls, as well. Obviously there will be cases where the emissive variance over the surface is too great to be handled this way, but I think steering people to the idea of treating/controlling such surfaces as a light will be a win.

[anderslanglands]

I cover the exact definition of the emission units for lights in a fairly wordy way (as it's a little subtle) here in the Quantities and Units section: https://github.com/PixarAnimationStudios/OpenUSD/pull/2758/files#diff-3042b10f5eed7d1dc28467437ef7f7c3cad9ccb30eb8dd93820575402328c11e - but "it's nits" is an easy shorthand. For emission in UsdPreviewSurface I would expect it to be the same.

Personally, I think it's fine that inputs:emissiveColor is allowed to be [0, 1) (and I should probably specify ranges for the lights' parameters explcitily in the PR now you mention it). A related issue is the one of camera exposure, which I added a note about in the Exposure subsection.

We'll be discussing this at the next WG meeting.