How to add / update light probes when using load additive

I am using the Scene Manager and Load Additive to add additional scenes to my world. These new scenes have their own light probe data but the information isn’t being added to the global lighting data.

What is the correct way to add scenes with additional light probe data?

Thanks!!

Bumping this, as we’re running into it as well, in 5.3.4f1. Is there a correct method of bringing in light probes additively? Or are there currently hard limitations to the system that require light probes for the entire game world to exist in the most recent, non-additively loaded scene?

And for reference for anyone looking into this, here is a thread from last year where it was acknowledged that additively loading light probes was not possible, but that a solution was in the works:

It’s unclear to me if the solution mentioned ever made it into a release.

Hi.
Unfortunately this feature has not yet made it in. It probably won’t be finished until the progressive lightmapper is out.
So at the moment you can not do this when realtime GI is involved.

1 Like

Ok, thanks Karl!

Followup question: is there a recommended workaround for using light probes when using additive scene loads? For example, can all light probes be placed in just one scene and loaded in? If so, can you describe how exactly that should be set up? For reference, our scene flow in standalone builds is currently as follows:

BootLoader (active scene) → additive async load → StartMenu

when the user selects ‘start game’ from our start menu, all of this happens right away:

StartMenu → non-additive load → OcclusionAndLighting (becomes active scene)
StartMenu → additive load → SharedStuff
StartMenu → additive load → World1
StartMenu → additive load → World2
StartMenu → additive load → World3
etc (many more World scenes)

Our scenes have the following realtime GI setup:
BootLoader: no GI
StartMenu: no GI
OcclusionAndLighting: precomputed realtime GI is checked, but no LightData is built or hooked up. This scene also contains our combined Umbra occlusion data for all World scenes.
SharedStuff: no GI
World1: precomputed realtime GI is checked, LightData built individually (not a combined build with other scenes)
World2: precomputed realtime GI is checked, LightData built individually (not a combined build with other scenes)
World3: precomputed realtime GI is checked, LightData built individually (not a combined build with other scenes)
(etc)

This setup works to get realtime GI functioning in a standalone build-- it took us a while to nail down this specific combination of properties (which scene is active, which scenes have GI checked/enabled, which scenes actually have built LightData, etc) because most combinations we tried did not work-- the GI was either all black, all white, did not manifest at all, or in some combos the GI would work in editor but not in builds. But this combo works for us in both editor and builds.

However, we have been unable to get light probes working at all with this setup. As you noted, we have found that trying to additively load/combine multiple scenes with light probes doesn’t work. However, we have also tried many variations of placing all light probes in just one scene and the result is always that surfaces whose GI is affected by light probes just become completely black.

So, we’re not really sure how to proceed. Is there something we can do to get light probes working with our setup, even if it is hacky or doesn’t fit perfectly with the way we are loading our other scenes?

Hi Leon

Since 5.3.4f1 the light probes in additive scene loading should be working like this:

  • If the new scene has light probes those light probes are used.
  • If the new scene doesn’t have light probes then the existing light probes are used.

Without seeing how your World1, World2, World3 are setup I can’t advise the best setup.

I would say the 2 options are (but I predict you have already tried this):

  • put ALL the light probes into the “SharedStuff” scnee or the “OcclusionAndLighting” scene but perhaps that won’t work if you don’t compute lighting
  • put ALL the light probes in World1 & World2 & World3 so they are present with the light data when the light data is computed.

Let me know if that helps to explain. If you have evidence that it isn’t working as I described then please reply and we can investigate further.

Thanks

Jake

Thanks, Jake! A couple of questions/clarifications about this info:

Just to clarify: if the new scene has light probes, it’s a total replacement of light probe data? Meaning, the existing probes are all discarded, replaced by the probes from the new scene? And I guess a second question about this: barring bugs/inconsistencies, should this behavior apply to all types of scene loads? (ie Additive, Single, Async Additive, Async Single) Or is there expected variance in this behavior depending on scene load mode?

One question regarding these suggested options. But first, some unfortunately lengthy background info…it’s my understanding, and experiments seem to bear this out, that 5.3.4f1 supports two different approaches for additive scenes + precomputed GI (this probably applies to other lighting as well, but I haven’t experimented with anything else):

  • Use MSE to load all scenes in the editor and build lighting. LightData is saved as an asset in the folder for the active scene, and contains a LightData sub-asset for each scene that was present via MSE during the lighting build-- a reference to the corresponding LightData sub-asset is set in each scene. When the primary scene is loaded (non additively) at run time and other scenes are subsequently loaded additively, all the GI just works (without visible seams) because the lighting for everything was built together. In our setup, the process for this method is: load OcclusionAndLighting in the editor and bring in all the World scenes via MSE. Make sure they all have realtime GI checked and OcclusionAndLighting is the active scene. Build lighting. Save all scenes.

  • Build lighting for each scene individually, having only one scene loaded in the editor when each lighting build occurs. Each scene gets its own LightData asset in its own sub folder. At run time, when such a scene is loaded additively, Unity is able to merge the precomputed GI data with what is already loaded and GI functions more or less as expected, though there will be visible seams if there are any areas where geo or GI in additive scenes overlap spacially. In our setup, the process for this method is: just build lighting individually in each World scene, with precomputed GI checked. Additionally, we needed to select a scene that will be loaded non-additively as the base active scene for GI, the scene must have precomputed GI checked in its lighting settings (though it need not actually have built LightData), and SetActiveScene() may not be used any time after that base GI scene is loaded. Any deviation from those three rules results in GI not functioning properly in standalone or console game builds (though play in editor GI is fine even when breaking some of the rules): depending on which deviation, GI will come out either solid black or almost completely white with just the slightest hint of the expected GI color/intensity. In our setup, we use OcclusionAndLighting for the base non-additive active scene, then additively load the SharedStuff and World scenes.

We are using method #2. We don’t care about lighting seams because the things in our scenes are not near to stuff in other scenes. The primary reason we are using #2 is build time and workflow convenience. Our precomputes/builds take a significant amount of time, even for individual scenes. We first experimented with method #1, but it turned out to not be a feasible option due to build times. #2 also fits better with our decision to break up the game into all of these sub scenes in the first place: compartmentalizing the game spaces, facilitating concurrent editing, and reducing central/shared dependencies as much as possible.

I include all that info as background for my actual question, plus just to get the info down somewhere in case it could be useful for anyone in the future doing web/forum searches for this stuff. :slight_smile:

My actual question: I think if I am understanding you correctly, the two options you suggested will only properly work with a monolithic/combined lighting build (method #1), since we’ve established that light probes are not currently mergeable at run time and thus need to be built with all lighting + probes present at the same time. Is that accurate, or is there an incorrect assumption I’m making about something? I just wanted to clarify that, because if that is accurate, then deciding if we can realistically switch to that lighting build method should probably be a prereq before doing any more investigation and experimentation with light probes in our current project.

(Also, please feel free to correct anything here that is just wrong…we’re definitely going by observation/experimentation for a lot of this, rather than knowing 100% how it’s intended to function. So there definitely could be some incorrect conclusions or assumptions!)

Hey Leon,

Yes light probe data is never merged for any type of scene load.

For Additive scene loading : if the new scene has light probes the new scene light probes are used and if the new scene doesn’t have light probes then the existing light probe data is kept.

For Non-Additive scene loading: the new scene light probes are always used and replace any existing light probe data.

So for Method#2 to work with light probes then I think you need to compute the light probe data in the OcclusionAndLighting scene.

1 Like

Hi Jake, Leon. This thread has been very useful as we face a similar workflow to Leon’s (lots of additive loading of world content for workflow/memory reasons). So first of all thank you!

We are on Unity 5.3.6f1.

For our game, our areas form a connected network and we load them additively as the player approaches the handover point. The player could move across into the new area, cause the old one to unload, then later cause it to reload and return to where they were. So for clarity:

  • BootLoader, StartMenu, Wrapper scene, etc have all been loaded additively and stay loaded.
  • Player loads the game, causing a SharedStuff and World1 scene to be loaded additively.
  • Player has World1 loaded and should be subject to World1’s lighting.
  • Player ventures towards World2, World2 is loaded additively.
  • Player enters World2 and should be subject to World2’s lighting.
  • Player ventures away from World1, World1 is unloaded.
  • Player returns towards World1, World1 is loaded additively.

And so on. The problem we are finding now is that very early on in that game flow (the third stage, when we additively load our first game scene), the light probes appear to be broken in both editor and standalone build. I can see them in the editor, but they are all solid black. Thus dynamic objects are far too dark. However the static geometry does appear to be lit correctly.

I expect we will have further problems as we would not want the loading of World2 to cause World1’s light probe data to be discarded, until we are ready to acknowledge the scene switch (game logic already does SetActiveScene at this point). We’re not there yet though as we can’t even load World1 additively and keep its light probe data :frowning:

Any ideas what’s going wrong for us? Thanks guys!

EDIT: even more simply I can recreate this in the editor: if I have a fresh, blank scene then use MSE to drag in a scene with light probes, the light probes all go black and mark the scene as changed.

Additionally, if I have a scene with 8 light probes lit by a light, and then use MSE to load in a new scene - the new light probes are all loaded in but black as described above except that eight of them (even though they’re in a different place!) are still coloured according to the original scene’s lighting. So it seems that although the new light probes replace the old ones as you describe, they don’t fully replace them and lingering data refers back to the previous scene.

Tom that sounds like a bug. Please could you report it with a small reproduction project and will investigate it.

2 Likes

Hi Jake - thanks for the response. Embarrassingly, trying to create a repro project for the bug I was unable to actually reproduce it, leading to me finding a solution.

The new project was DX11, while our main one (which was created a while ago under 4.x) is still DX9. Ticking “Auto Graphics API for Windows” to true under “Project Settings → Player Settings → Other Settings / Rendering” then rebuilding our lightmaps fixed it.

Is this an expected limitation for DX9 or a new bug?

Hmmm, not expected as an immediate answer but if you have a DX9 reproduction please report that and we can debug it.

Hi Jake, really sorry about this but I can’t create a repro at all. I can only assume that something about the project’s legacy journey from 4.x to 5.3.4 left some unusual settings somewhere that got cleaned up when doing the reimport or change to DX11 (I also had to rebuild lightmaps under the new player settings for the change to have any effect).

Sorry for this unsatisfying answer and thanks for your help - I will post again with a repro if I am able to ever catch it.

Hi Jake, I believe I have a reproduction now.

NB: We are in 5.3.4f1 for this, 5.3.6 didn’t help us so we reverted back while exploring the options.

In the attached project, you will find two scenes. Both have lights, light probes and pre-computed realtime GI. Both also contain a sphere that is clearly receiving bounced light via the light probes. They also have separate ambient light settings, to make it clearer which is the active scene.

There is a small script on both root objects which stores the light probes for that scene, and re-applies them in Update if it finds that it is the active scene but a different set of light probes are active.

By loading either, and then hitting any key (or clicking) it will load the other. Notice that the second scene loaded will look as we expect, receiving lighting from its probes as well as direct light.

There is a small script on both root objects which stores the light probes for that scene, and re-applies them in Update if it finds that it is the active scene but a different set of light probes are active. So, if we set the first scene to be active again the light probes will be correctly re-applied but not be using the original lights to calculate their settings. Additionally, if the first scene and second scene had a differing number of light probes, some of the light probes receive no lighting data at all and remain black.

I hope this all makes sense, and is the right way to report it (very happy to repost all of this in the correct place if not). Many thanks!

EDIT: have also reported bug through editor.

2762048–199443–LightProbesBug.zip (977 KB)

We have the same problem. Unity 5.3.6p2. I’ve attached a super-simple project for the repro. We’re pushing our early access release very soon and could use a fix or workaround.
Appreciated,
Paul
Warpforged Games

Repro:

  • Extract the project from the attached zip and open it.
  • Open SubScene.Unity and bake lighting (save)
  • Run the scene and note the colors of the backsides of the static and dynamic spheres.
  • Open MainScene and run it.
  • Note the colors of the backsides of the static and (incorrectly dark) dynamic spheres.

2765221–199761–WarpforgedLightProbeAdditiveScenesBug.zip (215 KB)

TomLansdale, would you please post the link to your bug report here? - thanks

Found it. Postponed - oy …

We haven’t had chance to test this ourselves yet, but today’s patch notes may indicate some good news for us all:

“(745588) - GI: Multi-scene editor. Fixed the lightmap indices not updating for additively loaded scenes in the Editor.”

EDIT: Don’t get too excited. Bug still seems to be present :frowning:

Thanks, Tom. Yes - still seeing the problem on Unity 5.4.0p4.

This is bad. We literally have no way to light our scenes in perf until this is fixed.