I’ve been pretty impressed with the ‘one click export’ workflow from UE4 to Omniverse. Geometry, materials, textures, pixel-perfect camera match, etc. all working well.
The one thing that didn’t transfer seamlessly was the light rig, which required a lot of manual tweaking in intensity before I could get a match between ‘Create’ and ‘Unreal’. The scene initially came in black, looking like the entire export process had failed.
In particular:
Point and area lights required the intensity to be increased by a factor of around 10
Spotlights came in with a inner cone angle of 0, and required a lot of trial and error to get a reasonable match (not a simple 10x multiplier)
Emissive materials also required an order of magnitude increase in intensity to show up as expected
With a fair bit of tweaking of the lights, I got a good match between the two applications (image attached). Is this a known issue / expected? Happy to write up a detailed bug report for each issue if not.
1 Like
Thanks for the detailed report Alex. There are a lot of variables here, and we’ve done the math repeatedly with point, spot, rect, directional, etc lights to try and get them right. I’d love more information on your scene so that we can improve things.
I’m curious if your Unreal level’s post process settings had any effect on things in Omniverse Create… The stage export will set these three tone mapping settings in the stage’s custom layer data, which Create will then use:
- Film ISO
- Camera Shutter
- f-Number/f-Stop
AutoExposure in Unreal Engine makes things more difficult (if enabled in game settings). Sometimes if we’re aligning looks between UE and Create we’ll disable the game settings and just use the fixed exposure setting:
Also beware of static lighting in Unreal Engine compared to the dynamic lighting in Create. This can cause differences.
On top of all of this, there are differences between the brightness path-traced and real-time rendered stages in Create as well. There’s a default “Indirect Diffuse Lighting” applied to the real-time render settings, and sometimes it’s necessary to disable this by adjusting the intensity.
Thanks for the info. I’ll run through the same process again, making sure I haven’t made any of the mistakes you flagged up.
I wanted to make sure that I wasn’t trying to troubleshoot a known issue (a grand waste of time for everyone), but if it should theoretically ‘just work’, it’s definitely worth the time.
If I do spot any issues, the scene is made from free marketplace assets, so no issues in sharing.
There is at least one bug with the light translation from UE4 to ‘Create’:
In UE4, the ‘softness’ attribute of a spotlight is defined by two cone angles (inner and outer), while in ‘Create’, the softness is a 0-1 scalar.
Create appears to read in a UE4 cone angle value directly into this ‘softness’ parameter, which gives very incorrect results.
1 Like
You were correct in your assumption that I was using ‘Exposure Compensation’ in a PP volume, and that this was causing some of my issues with the camera exposure.
The ‘cm^2 Factor’ would seem to be the nearest equivalent in ‘Create’, but it does not appear to be driven by the exposure compensation in UE4.
The translation of the camera settings is also… odd. While the scene initially looks almost identical on load (as shown in the screenshot below), the camera settings are not at all similar. Adjusting the settings in either of the applications, even with Live Sync selected, rapidly causes the scenes to diverge.
1 Like
Thanks for all of this detail.
SpotLights
- We have fixed the SpotLight softness issue by using the OuterConeAngle and using both the Outer and Inner Cone Angle in the calculation for the Softness attribute.
- Note that even after our fix the Source Radius is 0 by default. This doesn’t map very well to the physical Sphere light implementation so we actually bump it to 0.5 on export. I still find that lights with a tiny Source Radius don’t translate very well. In this example I used a higher radius (10.0) and they came over better.
Exposure
- On export we don’t write to the cm^2 Factor parameter in Create. Perhaps when we improve post process and exposure translation we’ll look into that.
- Also, it appears that the CustomLayerData (RTX Settings) does not replicate over a live link, so adjusting these items in a live session doesn’t push them to other clients like UE4.
Camera Settings
- In your image you’ll see that we do not export the camera’s shutter speed and ISO, just the fStop.
- Interestingly enough, Create doesn’t use the camera’s fStop to change the lighting, it uses the CustomLayerData-RTX Settings-Post Process settings. At some point we may change Create to use the camera’s values for “Tone Mapping”, but it does not at the moment.
- The fStop is primarily used for adjusting DoF in Create.
This GIF demonstrates how the Create camera fStop setting doesn’t influence the lighting:
The cm^2 Factor and Spotlight export changes were released in hotfix 100.5.
