USD Importer (USD Stage Editor) failing to read DomeLight_1 definition for Dome Lights + USD Questions

Hello,

First, please take a look at the two possible DomeLight definitions:

https://openusd.org/release/user_guides/schemas/usdLux/DomeLight_1.html

https://openusd.org/release/user_guides/schemas/usdLux/DomeLight.html

Currently, Unreal Engine’s USD Stage Editor supports DomeLight definition, but not DomeLight_1 definition.

Certain DCCs such as Houdini, on their newest production builds, (20.5.654) author Dome Lights with the DomeLight_1 definition; allowing for the “poleAxis” attribute to be used correctly.

At the moment, you only support DomeLight def, but not DomeLight_1.

The only difference between the two is that the older definition, DomeLight, only supports an Y axis; while the DomeLight_1 definition supports either Y or Z.

This is not so important for us yet, as all our Dome Lights are set to Y, but then our Dome Light exports to Unreal Fail because they use the newer definition.

Yes, we could, and we will for now, use the older definition, DomeLight, but we would like to ask you to support DomeLight_1 definition in the future; if you can not support the PoleAxis attribute, then perhaps you could read the DomeLight_1 definition and just turn it into a DomeLight definition, ignoring the PoleAxis attribute or forcefully setting it to Y. This will future-proof your USD Stage Importer and remove confusion about light imports failing.

-------------------------------------------------------------------------------------------------------------------------------------

Regarding Dome Lights, it would be great if in the future we could import .exr not only .hdr, but we understand that this is a current limitation.

-------------------------------------------------------------------------------------------------------------------------------------

Regarding lights in general, we are aware that we can not match the Lights from Houdini Karma to Unreal’s Pathtracer 1 to 1, that’s impossible due to big differences in renderers; but we would like to ask you how do you calculate the Lumen output of a light?

For example, USD lights from our research are working with nits; and the formula to calculate the nits from an USD light is this:

intensity * pow(2, exposure); and then 1 nit is 3.426 lumens and 1 nit is 1 Cd/m2 but that does not seem to be the case in Unreal.

(Don’t take this at face value, we might be wrong about this, I will attach the USD Lux Schema below)

When importing a light, we can select the intensity units and we can check your conversions there:

  1. Nits ; these match to the formula above - but of course there are still quite large light differences between test renders in other DCCs and Unreal’s PathTracer, even with the same Nits.
  2. Lumens / Candelas stop matching according to the formulas for us. We perhaps need to take into account the Source Radius and Source Length - what formulas do you use? It seems that the Lumens / Candelas are “Normalized”, this normalization is the same as USD Lights normalization which keeps the same light output no matter the scale of the light? We tried using USD Normalized lights, but we did not have much more luck in matching lights closer than with non-normalized lights.

Basically, how do you believe we can match lights closer to what we have in other DCCs? Do you have any tips or mathematical formulas we can apply to the intensity of the imported lights?

I know that the USD is not very explicit with lights units, but keeping in mind the nits and that we can use the scene scale attribute, perhaps we can find a better Lumen calculation for imported lights.

https://openusd.org/dev/api/usd_lux_page_front.html - USD LUX Schema

-------------------------------------------------------------------------------------------------------------------------------------

Regarding Interchange - it does not yet supports lights, do you have any idea when it would support them?

Thank you,

Vladimir

Steps to Reproduce
Hello,

  1. Create an USD that contains a Dome Light with a DomeLight_1 definition; either from Omniverse or Houdini (Newest Production Build)
  2. Import it into Unreal Engine via the USD Stage Editor
  3. The import *fails*, DomeLight becomes an Actor instead of a SkyLight

Hi Vladimir,

I’ve logged a Jira for a feature request to support the DomeLight_1 schema in Interchange (possibly for USDImporter too, but Interchange is currently the focus of development).

Note that Interchange USD already do support some lights, but you must do a scene import to get them (File > Import Into Level…), which you must enable through a cvar (Interchange.FeatureFlags.Import.USD.ToLevel 1) since this is still experimental. Support for DomeLight was added recently to Interchange (and will be part of the next release) so DomeLight_1 could be added as well.

Interchange can potentially support .exr for the SkyLight in the future since it has an option “File Extensions To Import As LongLat Cubemap” in its texture pipeline where you can add the exr extension.

As for the light intensity conversion, you can see in the source code how it’s calculated in USDLightConversion.cpp. You’ll see that the light intensity conversion from Nits to Lumens varies with the type of the light because it has to take the area into account so it’s not just one formula you can use to convert.

Best regards,

Anousack

Hello Anousack,

Thank you for the reply and for the information given.

We hope that you will be able to add DomeLight_1 to USD Stage Importer as well, even though I know it’s currently not the focus.

Thank you,

Vladimir