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:

http://forum.unity3d.com/threads/unity-5-additive-light-probes.307897/

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

 

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?

 

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):

1. 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.
   
2. 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.

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!)

 

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

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.

 

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?

 

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.

 

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.

 

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

 

Found it. Postponed - oy ...
https://issuetracker.unity3d.com/is...loading-scene-as-additive-in-standalone-build

 

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

https://unity3d.com/unity/qa/patch-releases

"(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

 

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.

 

Is still bug/feature still being looked into or is there a workflow to achieve additive loading of light probes now? I'm seeing light probes lose lighting being additively loaded into a scene without light probes.

 

They published a workaround a couple of days before, but it has been removed without any reason (asked on Twitter and in the General Support forum) https://blogs.unity3d.com/es/2017/0...ime-global-illumination-with-multiple-scenes/

 

Interesting...Here's the google cached version:

https://webcache.googleusercontent....th-multiple-scenes/+&cd=1&hl=en&ct=clnk&gl=us

And their workaround:

 

So this is definitely a bug ? Additive loading should be working as @JakeTurner described How to add / update light probes when using load additive.

 

Hi,

It looks like I'm also having a light probe issue in 2017.1.0f3

I have a global lighting scene (PrivateEye_Lighting) and many static geo scenes that load/unload as the player makes their way around the world.

PrivateEye_Lighting contains all LightProbes and is loaded on start. I'm finding that the LightProbe data is incorrect (dynamic objects not receiving correct shadow information, appearing very bright) and has weird lighting changes when static geo scenes are loading and unloaded.

Is this a bug or is there some mistake with my approach?

Thanks, Jake

 

I got a reply from unity. They said the issue should be fixed in the upcoming 2017.3 version of unity.

 

@Simeon Ok great, thanks for letting us know!

 

Thanks for the info. Hopefully it will be fixed for real this time...

 

I tired the 2017.3 beta version and it's still not fixed.

 

@Simeon *sigh* thanks, then I don't have to upgrade unity if it won't make in in the release version!

 

Fantastic... and now everything is broken if you use multi-scene light bakes and bundles... I´ve reported the bug 965309

 

I now tried Unity 2017.2 and it seemed fixed. I loaded my main scene and additive loaded the first level, then hit baked. When I started the game, the first level was correctly lit and all objects finally received the lightprobe lighting! Hooray!
I baked level2 with the main scene, started the game and only level2 got the lighting. It was removed from the first level.

I loaded level1 and level2 into the mainscene, hit baked and of course it couldn't work, since both levels are starting at the same position, means many objects overlap each other and are blocking the light.

SO! Since we are so close, is it possible to add an option like "ignore meshes from other scenes except active scenes" in the baking process? In contrary to 2017.1, light probes are going black again if you additive load another level, so I can't use this version, which is a bummer since 2017.1 got a nasty OnClick button bug. Have to see how I can work around it.. But would be great it someone from Unity could share if there is a workaround for my problem!

 

Sorry guys but in the current bug tracker the answer is :
Lighting team at Unity is well aware about this bug and currently, it is on team's roadmap, it is planned to be addressed during the first quarter of 2018.
Sorry for the inconvenience that this issue causes for you.

So I think it will be fixed in 2018.0 maybe not 2017.3 (I think :/)

 

Hey guys.
I was following this topic for some months due to the same problem (industrial project with a lot of meshes, splitted into multiple scenes for easier baking).

Unable to wait longer for a Unity fix, I ended by implementing a temporary solution that I decided to share with you.

Juste a quick resume of the situation :
- Baked light probes are not merged when loading multiple scenes with additive mode
- Only light probes of the last baked loaded scene are shown
- Number of light probes can't be changed at runtime
- Positions of light probes can't be changed at runtime

Here's my solution :
- Create a new empty scene (called LightProbesFix)
- Copy the probes datas (SphericalHarmonicsL2 values and probes positions) from each scenes
- Copy the probes from all the scenes to my LightProbesFix scene
- Bake the LightProbesFix scene
- Inject the copied datas to the LightmapSettings of the LightProbesFix scene (link original probe scene to merged scene probe using probe position)
- Add the LightProbesFix scene at the end of build settings (and it must be loaded at the end)

Some additional informations about my script :

- The script LightProbesFix must be placed inside an Editor folder
- You must create LightProbesFix scene manually (scene name is fixed but you can change it in script if you want)
- You must add this scene to the build settings (with last build index)
- Scenes disabled in build settings are not taken in consideration
- The script isn't doing any modifications to your original scenes (light probes groups are duplicated to LightProbesFix scene)
- Only fix Light Probe Group components
- If the GameObjects containing LightProbeGroup components are doing other things (scripts, meshs, ...) you should deactivate them in LightProbesFix scene (not automatically done because it's not the case in my project)
- You can execute the script through the Unity menu item : Studio Nyx -> Fix Light Probes
- Fix is made in Editor, no performance cost at runtime (except LightProbesFix scene loading)

You can download my script. Hope it will work for you and help someone .


EDIT : script from this post has one issue. You can download a fixed version in one of the following posts.

 

Thanks! The same workaround was posted by William Armstrong on a removed blog post =) I was lucky to copy the woraround hahaha

 

Hi and thanks for the script! I've also been struggling with this issue and was excited to find a workaround. The script appears to work, but every time I run it, it returns "Missing Probes: 27". These are the probes in the second of two test scenes and the script returns the same message regardless of scene order in the build settings or if I have either or both scenes loaded when I run the script.

It does appear to pull light probe information from both scenes, but the 27 probes in the second scene are black. Any ideas on what might be causing the issue? I'm running Unity 2017.1.1f on Windows 10 if that's of any consequence. Thanks!

 

Hi !
Thanks for your feedback. I fixed the problem, it was related to this step :
"Inject the copied datas to the LightmapSettings of the LightProbesFix scene (link original probe scene to merged scene probe using probe position)"

I was using Equals operator to compare positions but sometimes it returns false instead of true, due to float precision I suppose. Now I use closest position to find the good probe.

You can download the new version of the script, tell me if everything works now .

 

That worked. Thanks a ton! Is there someplace online I can send some beer $ your way? (I'll buy you one in person if you happen to be in the Seattle area.) Thanks again, cheers!

 

Ahah that's kind but I don't think it's necessary. I'm french and I don't plan to come to Seattle soon, too bad :/. But you can follow me on twitter @GhatSmith and the day when I will release a game or something on the Asset Store, maybe you will be interested to buy it . I'm glad I helped you and thank you again for your proposal.

 

Bonjour Ghat-Smith I ran into this exact same problem and I'm having problem actually using your script.

Here's my problem. A fire breaks out in my game, and this obviously includes new lighting (red everywhere, nooooo!). So I had the idea of duplicating my base scene, baking red lights into it (along with new light probes reflecting the red light) and loading it additively, then unloading it when the fire stops. The "loading" part works just fine. New light probes are loaded on top of the old ones, everyone bathes in red light. However, when I unload the scene, those probes remain, and everyone is still bathing in red light even though the fire scene is unloaded.

Using your script just like you described seems to work fine. Your script seems to combine the probe groups of both my scenes and put them in the LightProbesFix scene. But then what? I tried loading both my scenes additively then loading the LightProbesFix scenes on top of them, and then removing them when the fire is over...yet the red is still there when I unload them. Am I making any sense? Do I need to remove the light probe groups from my other scenes to get the desired effect? Is your script even usable in such a situation or am I simply using it wrong?

Sorry if this is confusing, but if you can figure out my problem, I'll add onto that beer money jStinson proposed

 

Hi xanderv. Sorry for the late answer.

Unfortunately my script is not designed for your problem :/.I take a bit of time for you to create a new script which should help you. I don't have baked scenes on my computer so I didn't test, there is a probability that it doesn't work :s.

Some explanations. First, remember that :
- Number of light probes can't be changed at runtime
- Positions of light probes can't be changed at runtime

When the fire stop, you can't remove light probes, but you can change the probes value (SphericalHarmonicsL2).
So the idea is to save two set of probes datas : one with fire and one without it and make the switch at runtime.

I create a scriptable object with serialized values to store SphericalHarmonicsL2 datas. It's a non serializable struct, so you need to store the inner values (27 float for each SphericalHarmonicsL2). You can access SphericalHarmonicsL2 coefficients like a two dimensional array (https://docs.unity3d.com/ScriptReference/Rendering.SphericalHarmonicsL2.Index_operator.html).

I also store the position of the SphericalHarmonicsL2 too but I didn't used it finally because I assume (and like I didn't test it's a high risk) that probes order isn't altered when making a baking or when launching game. If it's not the case, you need to store positions and use them to associate the saved probes index to the true current probe index. It's what I've done in my first script (under the comment "// V2 : use closest position to find index"). But it will probably be terrible for the framerate, so let's assume that probes order won't change .

Resume :
- ScriptableObject to hold set of probes datas
- Method to populate scriptable object with current probes datas (access probes from LightmapSettings.lightProbes.bakedProbes array and save for each probes the 27 SphericalHarmonicsL2 float values)
- Method to inject the datas from ScriptableObject to current probes datas. This is the method you need to call at runtime with the needed set of datas.

How to use :
- Import package uploaded with this post
- Create a LightProbesDatas (instance of scriptable object) throught Create Asset menu (in project view) : Create -> Studio Nyx -> Framework -> Additionals -> Light Probes Datas
- Use previous script to merge probes in a specific scene
- Use button in your scriptable object instance inspector to save current probes values
- Create a new scriptable object instance
- Disable unwanted probes for the new probes save
- Use previous script to merge probes in a specific scene
- Use button in the new scriptable object instance inspector to save current probes values

Now your datas are ready. You just have to inject the wanted set of datas on runtime, depending on your scene situation. I added a small example script "InjectLightProbesDatas" to give you an example (set scripable object instance reference and click on the button in play mode to inject its datas into LightmapSettings

I hope it will help you and will be clear enough. Like you can see, this is not really practical. Maybe it can work if you have a simple case with two states, but if you have a lot of runtime probes change, the best is to pray for a fix in next Unity version :/.

 

Oops forgot to assign new probes datas to LightmapSettings.lightProbes.bakedProbes.
Here is a fixed version of InjectProbesDatas method, sorry :

Code (CSharp):

1. // Inject saved probes datas to LightmapSettings
2. public void InjectProbesDatas ()
3. {
4.     SphericalHarmonicsL2[] orderedProbes = new SphericalHarmonicsL2[LightmapSettings.lightProbes.count];
5.  
6.     for (int i = 0; i < LightmapSettings.lightProbes.count; i++)
7.     {
8.         orderedProbes [i] = new SphericalHarmonicsL2 ();
9.         for (int k = 0; k < 9; k++)
10.         {
11.             orderedProbes [i] [0, k] = probesCoefficients [i].RedCoefficients [k];
12.             orderedProbes [i] [1, k] = probesCoefficients [i].GreenCoefficients [k];
13.             orderedProbes [i] [2, k] = probesCoefficients [i].BlueCoefficients [k];
14.         }
15.     }
16.  
17.     // Need to reassign bakedProbes (modifying directly bakedprobes elements isn't working)
18.     LightmapSettings.lightProbes.bakedProbes = orderedProbes;
19. }

 

Has this been fixed yet? I can't seem to find any info on this..

 

still broken for us in 2017.4

 

I can confirm that it's fixed in Unity 2018.2.0b4

 

I've just tried on 2017.4.5f1 and it seems to be fixed

 

special thanks for this one!

 

Doesn't appear to be fixed for me in 2018.1.2f1.

if I bake two scenes separately, and load them both in the editor, the scene that loads second alters how non-static objects in the first scene are lit. I can fix this by deleting the probe group in the 2nd scene and re-baking it (which obviously does not help me) so it would appear that the probes in the 2nd scene are somehow affecting lighting in the 1st scene.

Are you guys sure this is working for you?

 

Not working in 2018.2.14. Can't find any mention of it in more recent versions. Putting together my own solution since our scene setup is pretty fragile. This really needs to get fixed.

EDIT: Honestly, just a function to set which scene's light probes we want to use at runtime (without unloading and loading scenes) would go a LONG way. For us, it doesn't need to be seamless.

 

Hello !
There is quite an issue with the script fix of Ghat-Smith, and you can notify it only if you using colorful lights.
Here is what you have to change in LightProbesDatas.cs to make it work.


public SphericalHarmonicsCoefficients(SphericalHarmonicsL2 copiedDatas)
{
greenCoefficients = new float[9];
blueCoefficients = new float[9];
redCoefficients = new float[9];
for (int i = 0; i < 9; i++)
{
redCoefficients = copiedDatas[0, i];
greenCoefficients = copiedDatas[1, i];
blueCoefficients = copiedDatas[2, i];
}
}

( Just a ref to the same array is never a good idea )