GI - Global Illumination + Load Level Additive Rendering Issues

Could we get an ETA on Enlighten support for additively-loaded levels? It currently does not work.

• According to this official blog post, it should be in 5.0
• According to this thread, it should be in 5.0
• According to this more recent thread, it is now planned to be in 5.X

This is a must-have feature for high quality and immersive games.

Here is how our store model looks after being additively loaded in our main scene:



There are dark spots everywhere.

In its current state, Unity is forcing us to use only one huge scene for the whole game, which can become quite problematic on not-so-powerful machines.

 

I know, this is so absolutely critical! I am trying to do one huge scene, but I would hate to find out down the road that it's too big to run smoothly. As it is I'm having trouble lightmapping the entire scene without crashing and I only have just the basic geometry in place.

 

@Joachim_Ante

Did you considered out of memory problem in editor? Seems that Your actual solution is good for small or closed world which can be splitted and loaded separately without seam problem like outdoor and indoor but as soon as we consider more open or huge world like skyrim or witcher 3 your solution seems become fast really painfull (because in editor you have to load whole world while game split and stream chunks for performance). Imagine loading 30x30 km world at once and bake in editor... Ouch!

This is how i understand your approach... maybe i missed something but if not then your solution is good only when NOT supporting open world is intended... and what with procedural world? As far as i understand you want to support this case as well but they cannot be loaded in editor by design...

Personally i think multiple chunks loaded in runtime and procedural world are similar but not identical problem (especially prebaked chunks approach) to solve and thats why you should already think about procedural approach instead of trying support chunks first then procedural because as soon as you will support procedural, supporting chunks and huge world and LODing will be trivial and probably you avoid redundant work...

 

How will this work for scene assets that are re-used across different scenes? If I'm reading correctly, this sounds tailored for breaking up the parts of a single, large scene/environment.

Considering that we're not all making open world games, would this work with (for example) centrepiece or furniture geometry that can be found shared across a number of levels - but you only want to bake it once, and additively load it into X scenario? Or is the GI going to be incompatible anyway? (how reliant on the initial bake environment is the realtime GI?)

 

I started breaking my scenes up because they were too big to bake, out of memory, but that was Unity4 32 bit. I was concerned also after reading his post. But I'm hoping the editor can handle it.
Another advantage for breaking scenes up is baking time and updates. One portion may change, so I can easily update that one scene without effecting the rest of the project. And without 'Bake Selected', the entire project needs to be re-baked. Do you know how hard it's going to be to get good and consistent results across your entire project with a single bake? Nearly impossible.
I suppose it's out of the question to ask for an estimate of when we can hope to see any solution?

 

@Joachim_Ante This 30x30 was edge case of course. i guess you know what to do but i think loading whole world at once isnt the best idea for memory.

Maybe you could mix these approach? You see we could bake scene one by one and last, optional step would be choose four chunks and rebake ONLY connecting edge. For better performance and quality control we could define edge thickness.

Or modify your first idea: create editor window where we able to set scene grid (only reference to scenes) and make automatic tool which will load and unload rows by rows (keeping 2 rows at one time is enough i think). I think this is the best idea for seamless gi and enable large open world.

Only two drawbacks i see: more work for implementation and probably slower baking which is compensated by much less memory consumption. And longer baking for whole world isnt huge problem: if you bake whole world your work is probably done and you have to reserve a lot of time anyway for this massive work

 

It can be. I do ArchVis work and if one of these scenes bordered another at a large open space I would create a prefab of the lights at the seam and have them in both scenes for consistency. I would also temporarily bring in the geometry of the neighboring scene while baking so the light diffused similarly. Additionally I would break the scene at a change in floor or wall covering, like where tile starts. I couldn't use a skylight to emulate GI because there would be bright areas where the geometry ended, so I would use area lights where needed for daylight.
But 90% of the time it wasn't a problem because building are broken up into rooms and corridors and spaces naturally. So I split them in the middle of the walls. And the exterior of the building is one shell and all of the interior spaces are loaded from separate scenes at runtime.
All of that may seem like a lot of work, but it's nothing compared to what i'm having to do to combat light/shadow leakage across meshes and between lightmaps with enlighten. Which I am actually fine with because of the quality enlighten can achieve. But almost every space needs to be a detached piece of geometry and there can't be any polys facing each other. I'm doing my first project with enlighten now so learning exactly what I can get away with and what I cant.
And my experience with the caching is that it saves a lot of time if all you are doing is updating lights. But if you switch a mesh out for an updated version, forget it, it's going to start over. I dont know about typical game design, but building design is an iterative process. A lot of work is spent optimising meshes to remove vertices, splitting them to include another reflection probe, and simply adding content. Not to mention changes from the client.
I would be happy with any system at this point. But I would like to see data baked completely separately.

Edit: it seems to me if the system supported baking completely separate scenes and combining them, using it to bake a single scene would already be in place. Or even baking a large scene and breaking it up. Plus with completely separate scenes I might be able to use baked only in some, realtime only in some and both where needed. Not trying to complicate thing, we just need any system that works to start with.

 

Hi

Hi Joachim,

That would certainly do the trick for us. We don't mind having good machines that handle the whole group of scenes in the Editor as long as the end user has them loaded separately, additively.

This is IMO the best way to handle it as it avoids seams and allows us to precisely place our objects in the same, borderless world.

 

In 5.0.1 release notes, one says:

• Asset Loading: Fixed loading of GI data from an AssetBundle.

Is that a solution for this issue, or is that a fix for another issue with loading scenes from AssetBundles?

 

No, I just tested it. It's a little better in that it doesn't destroy the scene. But the loaded GI was not working.

 

This certainly won't work for us.

We build larger worlds/dungeons procedurally from additively loaded scenes, so we don't know the sequence that the scenes will be loaded before hand, and the same scene can be included in multiple parts of the world with various overrides to make them appear different.

Presently we build the sub-scenes so that lightmap edges are simply not visible and objects that interfere are moved to other locations away from the edge, so that is not a problem for us. Also we generally have a simple generic "edge" piece to place beside edges to ensure the lightmaps are continuous, then we hide this simple geometry in production.

Having to place all of the areas to be lightmapped for GI into a single scene would require that we eliminate all procedural generation and that we go through a very large bake process as our levels (because they are procedural) can be enormous.

What we would prefer is just to allow the GI information baked into a given level to be additively added to the current scene with no cross scene GI solving, or some form of dynamic attaching of top, bottom, left and right edges as terrain does. I think that would work just fine for us as our art is engineered to not show the seams between lightmapping anyway.

 

We've tried loading the foreground scene destructively and adjacent scenes additively and we're stymied by the fact that static GI objects actually can't be transformed (so all meshes show up in the same place).

What we would need is the following:

Required (for us at least)

For "Realtime" GI only (as we do not use baking):

1. At the very least the ability to load a scene that has been lit using GI additively with no errors, and to have the lighting work correctly in both the previously loaded scene or additive scene geo, and the newly loaded additive scene as they would if loaded independently.

2. The lit geometry must be able to be relocated in world space by transforming a root game object. Rotation would be nice, but position is required to allow for a continuous generated scene loading the same scene additively.

3. The ability to remove scenes or geometry and reclaim used memory.

Nice to have

1. The ability to rotate GI lit geometry.

2. The ability to correctly merge the GI lighting contributions for adjacent connected edges of scenes when those scenes were not initially rendered as being adjacent. - Nice to have - but we can just design scenes to hide significant issues with seams using proxy edges, other techniques

3. The ability to pack GI information into a prefab. If there is some subtle issue with being able to load the same scene additively more than once then this might not be a nice to have but a requirement, as generative levels require the same scene be loadable multiple times.

 

After initially baking multiple scenes with Lightmapping.BakeMultipleLevels and creating the individual lightmap snapshots, can those scenes be baked again interdependently and maintain the connection?

 

That sounds great! I really hope it can make it to 5.1 as this would tremendously increase the quality of our game.

Keep up the good work

 

Well... I assume it is for the best, but I hate it when Unity says: "This feature should be available in 5.0" when in the end it's not even planned for 5.1.

There is absolutely nothing we can do right now to load a house additively without Enlighten GI falling into pieces.

I guess we will have to live with our 3 square-kilometers map all loaded at once for the time being.

 

Thanks. This will be perfect for us.

In cases where the generative code will not allow us to know before hand which scenes will be adjacent to which others, we will use option #1.

In cases where we "can" know before hand which scenes are adjacent, we can still potentially make use of option #2.

One more question - it should be possible to "translate" the hierarchy of baked gI scenes, correct? This is not presently working for the test scenes we have tried. When we load the same scene with baked GI twice (or more) additively the MeshRender components seem to point to a single on screen mesh and the that single mesh does not seem to be affected by any changes to the game object's Transform.

We're assuming this is a bug related to GI and loading scenes additively just not yet working, but we wanted to make sure this wasn't actually a basic limitation of the Enlighten system in general (that GI meshes are locked in place).

Again, we don't need (or expect) GI geometry to rotate or scale, but for generative worlds we need them to translate.

 

Note: this could also be a problem if the tetrahedralization assumes the additive level data will remain at world position 0,0,0.

Our engine currently immediately translates the scene hierarchy root on load to it's proper location after loading has completed. This would probably break the tetrahedralization done during loading.

Possible solutions would be to allow the tetrahedralization be performed (or re-performed) after loading, or to be able to pass a "scene transform" to LoadSceneAdditive() which would allow the scene to be loaded at a non 0,0,0 world space location.

A fallback option would be to allow us to avoid connecting the lightprobes on load at all (which would produce some pretty unwanted side effects, but possibly better than having them patched incorrectly).

Finally, an alternative to automatic patching might be to just allow manually passing in two arrays of probes to patch manually that are already arranged to connect in a well known geometric pattern . Since we are specifically authoring the "joints" between scenes to align, we can ensure during authoring that there are two parallel sets of light probes in each scene on either side that can be easily connected. For our case this could potentially be a better solution as it leaves how the probes connect more under the artists direct control.

 

I too would like to see something like this, but I would need a rotation as well as a position.

 

Will 5.1 have any support of LoadLevelAdditive and Realtime GI? I just want to be crystal clear, as there are many features being discussed in this thread.

 

This is not related to GI at all and is most likely caused by static batching.

Batches are created when the scene is postprocessed when entering play mode or building the player. The world transform of each source instance is baked into the combined mesh, that's why those instances can't be moved at runtime.
In the Editor this is shown with the "static" label next to 3D handles in the scene view.

You can simply untick "Batching Static", see http://docs.unity3d.com/Manual/DrawCallBatching.html

Indeed, something like that will be needed.

We would either need a way to tag those special probes or connect all the probes on the hulls of the clouds of probes coming from the different scenes, but reject connections that go through any of the hulls (as those were created already)...

We haven't settled on a solution yet, but we'll go for something that doesn't require additional manual work and doesn't break carefully set up connections.

 

>GI will not bounce from one scene to the other in this case.
How will that look visually? We are going to see some kind of seam between two scenes? Or this can be neglected, if both scenes will have same amount of lighting on their edges?

 

Ah, it's good to find this thread here! I've been fiddling around with a concept for a flashlight based horror game, where the level will partially re-organize itself upon player death. I was depending on bounce light from the flash-light to do 80% of the world lighting, with the exception of occasional lit rooms that would allow the player a breather. It seems that the level rearranging itself wouldn't work under the current implementation of Enlighten, so it's nice to see that you've already considered this case and are working on it. I really appreciate you guys working on Unity—thanks. :]

 

Would be great

It would be awesome when you do an additive / async level load you could specify to bring in lighting / render settings. It would be handy on mobile if your doing lots of small loads but need to change these settings from time to time without having the do a normal level load.

 

can we use realtime GI and Level load async yet? This is also an issue for anyone using SECTR streaming, they had to disable realtime GI in streaming/over all.
thanks

 

As of Unity 5.1.1, it still does not work.

 

It required quite a lot of engineering to get it to work and it's a part of Unity 5.2, please see: http://unity3d.com/unity/roadmap

 

Thanks for the info, great to hear!

 

Whoa! Didn't know about the existence of this page- straight to the bookmark bar! Thanks

 

Well that is all nice but it will not fix our problems. For example we have all game mechanics split from visuals right now, so there is always just one set of lightmaps and one set of lightprobes. What we want is to load the visuals into our scene. When we do that, light probes object loads but it doesn't affect any objects, it just looks as if lightmaps are not built. We just want it to load additively without any merging or re-tetrahedralization. What can we do with that? Is it possible to load LightProbes manually into the LightmapSettings.lightProbes?

Little update, it's not possible with Unity 5 because there is no Lightprobes prefab created, it's part of snapshot, which is not even available in player.

Anyway, there is a very hacky way how to do this. You can write a script, which creates probes prefab from scene which built them. Prefab can then be instantiated and assigned to whatever scene LightmapSettings.lightProbes you want.

 

I tried it with Unity 5.2.1b5! Unfortunatly loading additive / unloading (destroy) levels seems not to work correctly?!
Has anybody found a solution to this issue?? Packing all into one big scene is no solution for me (too big, different lighting setups / skys etc.)

 

It probably hasn't been properly implemented yet in that beta. 5.2 is only due in September, so there will be at least another month of bug fixes and features.

 

I'm in the same boat. I want to create randomly generated level by combining scenes with Realtime GI and light-probes as tiles. LoadSceneAdditive works up to the point where I need to translate/rotate tiles. Lighting just sticks to (0,0,0) point. Tested with Unity 5.2.0f3.

It would be nice to be able to pass transformation info into LoadSceneAdditive. Rotation is nice to have but translation is a must unfortunately. I'm OK with seams between tiles.

Any updates on this feature?

Thanks,

 

This was asked many times, so do not expect this feature, i.e. plan your game as if this will not exist. That is how I do it, though I wanted to have this badly, but did not find any solution.

 

Any updates on this feature in 5.3?

 

It works pretty well actually in 5.3 with the new SceneManager.

 

This fails for us in 5.3.3p2

We've discovered loading a scene additively, then destroying it, then loading it *seems* to cause the lightmaps to disappear. Days of experiments have not fixed the issue, so we've gone back to GI, but that seems to fail entirely on additive loads.

Any updates?

 

I don't know about lightmaps, but GI does work now with additive loading (we use async) as long as you use the new Scene Manager.

 

In 5.3.4f1 additive asynchronous loading scene with realtime GI using SceneManager is working well for me but only in editor. In Windows standalone build all static objects of loaded scene are very bright.

 

Still having this issue, it's fixed in the Editor, GI and lightmaps are swapped out fine.

Players are still broken in 5.3.5f1 Standalone & Mobile players.
Lightmaps & GI are not swapped out. Resulting in over exposed scenes.

Editor Game Window Correct:


Android Player:



Related issue: https://issuetracker.unity3d.com/issues/gi-is-broken-if-loadleveladditive-is-used
Other reports: http://answers.unity3d.com/answers/921831/view.html

 

I've just tried 5.4 b25 and it's working as expected
AND 5.3.5p2 notes has

• (790530) - GI: Fixed some cases of additive scene loading not merging lightmaps properly.

Very hopeful, testing that now.
//edit all fixed.

 

does anyone know if multiple scenes (we plan to have 250, each with a different world space location), each with their own light probe set, can be additively loaded in at runtime? Using unity 5.4
Light probes offer a massive performance gain for us so this one small feature would enable a lot of possibility. Alternatively is there a way to load in all the baked scenes and then bake all the probes together?

 

Yes, with 250 additive levels though out of memory will be your problem I think because it doesn't destroy the current levels. If I'm wrong experts please correct me.

 

Yes it does work (we're doing exactly that in Kona), but keep in mind that loading scenes additively in Unity is still imperfect, especially if you have GI turned on and are running on a non-so-fast machine.

Problem is: All textures from the loaded scene are loaded in one frame, so it's quite easy to feel the loading hiccup if you scene is more than a few mb.

Solution is: We're still hacking around to reduce the hiccups, but our main solution would be to split our world in even smaller pieces and to stream textures (not by using tools like Amplify Texture as this kind of thing is even worse, but by assigning 64x64 versions of our textures to the materials, then load higher resolutions ones async on scene load)

 

You can unload any level, but they will indeed stay in memory unless you call Resources.UnloadUnusedAssets.

We have an option in Kona called "Preloading" which essentially, if ticked on, will load all levels at the initial loading, then unload them. What that does is preloading all the data, increasing the memory footprint, but reducing/eliminating hiccups. Lower-memory machines owners don't have that option ticked so all scenes are loaded and unloaded properly, but the user do feel hiccups.