Lighting differences between editor and application

[tmorris]

We are having lighting differences between the editor and application that should not be there.

 

Attached is a screenshot of a roof at one of our flying sites as an example.

 

The left screenshot is the editor, the right screenshot is release application. 

Since the roof is white and takes up the whole shot, the hdr settings should kick in for release and kill the brightness to match how it looks in the editor, but in release it's way too bright and all washed out.

 

I have attached 2 videos that also highlight the issue.

 

From the Editor. When moving towards/away from the roof the lighting starts out bright and dims as you get closer to the surface, as you pull back out it brightens up again.

 

From the Application. When moving towards/away from the roof the lighting starts out bright and stays bright the entire time.

 

Any ideas about what might be causing this? We are having a difficult time tracking it down.

 

Thanks.

[cryunreal]

Hi Taylor,

 

It seems that in the application render_exposure_mode (adaptive exposure) is set to 0 but inside Editor it is set to 1.

 

You can try to turn on an adaptive exposure in your application by entering in console render_exposure_mode 1 command.

 

Thanks!

[silent]

Hi Taylor,

 

If this doesn't help you can type ls command in the Editor console and compare all the variables values with the output of running application to see if there any difference in them.

 

Thanks!

[tmorris]

Hi there, I should have mentioned it but I cycled through all of the render_ console commands while testing this and nothing seemed to fix the problem.

 

After using the ls command It appears that all settings are the same between the editor and application across the board.

 

Any other ideas what might be causing this? Settings printed from ls command are verified 1:1 between editor and application.

[silent]

Hi Taylor,

 

Please, also make sure that you have identical core.ung / editor.ung / scripts.ung in your application (identical to editor's).

 

btw, are you using the latest 2.2.1 SDK version?

Thanks!

[tmorris]

Both the editor and sim are using the same set of .ung files and we are using the latest 2.2.1 SDK version.

[silent]

Hi Taylor,

 

We are running out of guesses, but maybe some UnigineScript code / C++ logic / Tracker tracks are changing nodes paramters?

We've also tried to reproduce this issue on our test stand, but with no luck.

 

Could you please send us your project or steps for reproduction so we can track down what caused such behavior?

Thanks!

[tmorris]

Hi,

 

I was able to isolate the problem. We are using several viewports within our scene, one of them appears to be causing this problem. I dont fully know what is going on behind the scenes but if I disable the trouble viewport HDR works as expected.

 

To give a snapshot: We have 3 viewports in our scene. The main camera(view#1), a binocular gadget(view #2) that shows a zoomed in view of our airplane, and a controller gadget(view #3) that shows a virtual representation of the flight controller with animated control surfaces.

 

View #3 is what looks to be causing the problem. I can fix HDR by simply not adding the viewport to the gui but I would like to figure out how to make HDR & the viewport work. Any ideas?

 

Some differences with View#3:

It is added through UnigineScript.

The camera and controller model for the viewport are not located near our scene and are instead located at the world origin.

 

Thanks.

[silent]

Hi Taylor,

 

In general case where you want to render different viewports with different cameras post effects and tone mapping should be disabled. This is general behavior for all multiple viewports setup. I can assume that this is unfortunately the expected behavior. To be 100% sure a small test scene will required.

 

Could you please give us a small sample with reproduction?

Thanks!

[dred]

silent we will work on weather or not we can get you a test scene, but it doesn't appear to be disabled, it appears to be using the secondary viewport to determine the hdr adaptiveness.  In another scene we have a process that uses a WidgetSpriteViewport to render previews for us.  If we set it up so the secondary viewport it hidden(still rendering but not visible on screen), as we change preview shots you can see the main viewport get lighter and darker which only happens when that secondary viewport changes what its looking it. 

 

My guess as to why we see nothing in the main scene, is that its using the third viewport which never changes what its looking at to set the brightness for the world.

[tmorris]

I am not able to do a sample at this time but I was able to demonstrate the issue in a different way. 

 

It looks like both our View #2 & View #3 cause problems depending on the situation. 

 

Attached is a video of our wip binocular gadget(View #2) in action. In this video you can very clearly see the lighting for the entire scene changing based on View #2. When this view is enabled the lighting darkens quite a bit, as the scene within the viewport changes so does the entire scene, this is bad. What we would like is to have the lighting completely driven by View #1(main view), do you know of how we might go about achieving this?

 

Thanks!

[silent]

Hi Taylor,

 

I'm afraid there is no currently way to use exposure and other camera settings from different viewport.

 

Sorry for the inconvenience caused.

[justin.ead]

To give an update, I managed to solve our problem with a couple small engine changes. I created and set a new viewport skip flag for our secondary viewports and used that flag as a conditional in RenderPost::renderCameraEffects(). Instead of rerendering a new luminance texture each time, if this flag has been set, it reuses the existing luminance texture. This conditional was set as an else if after if (renderer->isNode()) in the exposure section near the top of the function. Inside I just assigned buffers->exposure_luminance = render->getLuminanceTexture(1,1); and moved on.

[justin.ead]

Thoughts on any unintended consequences?

[silent]

Hi Justin,

 

Your solution seems to disable adaptive exposure mode for all viewports. But adaptive exposure for multi-viewport setup indeed a complicated task.

 

The same thing (disabling automatic exposure) in theory can be achieved via render_exposure_mode 0 console command. 

 

Thanks!

[justin.ead]

Hi silent,

 

To clarify, I'm not disabling adaptive exposure for all viewports. I'm skipping the luminance generation for all newly created widget viewports, but keeping that code executing for the initial main viewport. Adaptive exposure continues to work just fine as if I had never created multiple viewports. The goal here is to use the luminance generated by the main viewport across all viewports.

 

Justin