Search Unity

GI - Global Illumination + Load Level Additive Rendering Issues

Discussion in 'Global Illumination' started by alexandre-fiset, Mar 13, 2015.

  1. alexandre-fiset

    alexandre-fiset

    Joined:
    Mar 19, 2012
    Posts:
    443
    Could we get an ETA on Enlighten support for additively-loaded levels? It currently does not work.
    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.
     
    Meltdown and topofsteel like this.
  2. topofsteel

    topofsteel

    Joined:
    Dec 2, 2011
    Posts:
    975
    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.
     
  3. Joachim_Ante

    Joachim_Ante

    Unity Technologies

    Joined:
    Mar 16, 2005
    Posts:
    4,887
    LoadLevelAdditive is supported for lightmaps like in 4.x but currently not for Realtime GI.

    We are working on making this work for both lightprobes + realtime GI.

    The approach we are going for is:
    * You load all scenes that you will load together via EditorApplication.LoadSceneAdditive
    * Then you bake

    Unity will then split the data based on which scenes require it and load enlighten systems based on what it needs for the active set of scenes.

    Will this solve your use case?
     
  4. Breyer

    Breyer

    Joined:
    Nov 10, 2012
    Posts:
    412
    @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...
     
    Last edited: Mar 16, 2015
  5. Pix10

    Pix10

    Joined:
    Jul 21, 2012
    Posts:
    844
    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?)
     
  6. topofsteel

    topofsteel

    Joined:
    Dec 2, 2011
    Posts:
    975
    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?
     
  7. Joachim_Ante

    Joachim_Ante

    Unity Technologies

    Joined:
    Mar 16, 2005
    Posts:
    4,887
    Are you sure you would want to have a baking process for a 30km * 30km world?
    Skyrim is 5km * 5km.

    We'll have to see in practice. In any case different approaches for different problems. As far as I can see, solving the i have a couple of seperate scenes that are connected and I want seamless lightmaps and trees from one scene casting shadows into the next one is by far the more common use case.
     
    fsidler likes this.
  8. Joachim_Ante

    Joachim_Ante

    Unity Technologies

    Joined:
    Mar 16, 2005
    Posts:
    4,887
    We have a lot of caching and realtime GI is built in a way that scales baking processes by subdividing the world in systems that are connected.

    The other approach to baking is to bake the data completely seperately, but of course in practice this means that neighboring levels will have lightmap seams if you bake them truly seperate from each other. Is that not a problem for you use case?
     
  9. Breyer

    Breyer

    Joined:
    Nov 10, 2012
    Posts:
    412
    @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
     
    Last edited: Mar 16, 2015
  10. topofsteel

    topofsteel

    Joined:
    Dec 2, 2011
    Posts:
    975
    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.

    ligtmap-2.png

    ligtmap.png
     
    Last edited: Mar 16, 2015
  11. alexandre-fiset

    alexandre-fiset

    Joined:
    Mar 19, 2012
    Posts:
    443
    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.
     
  12. maxxa05

    maxxa05

    Joined:
    Nov 17, 2012
    Posts:
    113
    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?
     
  13. topofsteel

    topofsteel

    Joined:
    Dec 2, 2011
    Posts:
    975
    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.
     
  14. benjcooley

    benjcooley

    Joined:
    May 3, 2014
    Posts:
    45
    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.
     
    ProtonOne and topofsteel like this.
  15. benjcooley

    benjcooley

    Joined:
    May 3, 2014
    Posts:
    45
    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.
     
    fsidler likes this.
  16. Joachim_Ante

    Joachim_Ante

    Unity Technologies

    Joined:
    Mar 16, 2005
    Posts:
    4,887
    We have been working a lot on load level additive support in the last month or so.

    Based on feedback here we have decided to support both cases.

    1) Bake scenes seperately. Lightmaps & realtime lightmaps can be loaded togehter. GI will not bounce from one scene to the other in this case.

    Currently we haven't solved lightprobe merging yet, but the plan is to do tetrahedralization at load time when merging two completely different light probe sets

    2) Lightmapping.BakeMultipleLevels (string[] levels); will bake multiple scenes at the same time and split the data at bake time into multiple lightmapsnapshots.

    When they are additively loaded together they "connect" and thus realtime GI light can bounce between additively loaded scenes. In the same way when using Lightmapping.BakeMultipleLevels, lightmaps also output lightmaps that include shadows from geometry from other levels that you baked togehter.
     
    hopeful and alexandre-fiset like this.
  17. topofsteel

    topofsteel

    Joined:
    Dec 2, 2011
    Posts:
    975

    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?
     
  18. alexandre-fiset

    alexandre-fiset

    Joined:
    Mar 19, 2012
    Posts:
    443
    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 :)
     
  19. Joachim_Ante

    Joachim_Ante

    Unity Technologies

    Joined:
    Mar 16, 2005
    Posts:
    4,887
    It will not make it for 5.1. We are working on making this rock solid as fast as we can.
     
  20. Joachim_Ante

    Joachim_Ante

    Unity Technologies

    Joined:
    Mar 16, 2005
    Posts:
    4,887
    You mean if you bake them again independent of each other?

    If you bake it independent of each other afterwards then the lightmap data will not take connections to other scenes into account anymore.

    From a workflow perspective however you can iterate on scenes independently and before making a build you could build with all scenes connected.
     
  21. alexandre-fiset

    alexandre-fiset

    Joined:
    Mar 19, 2012
    Posts:
    443
    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.
     
  22. benjcooley

    benjcooley

    Joined:
    May 3, 2014
    Posts:
    45
    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.
     
  23. benjcooley

    benjcooley

    Joined:
    May 3, 2014
    Posts:
    45
    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.
     
  24. steego

    steego

    Joined:
    Jul 15, 2010
    Posts:
    916
    I too would like to see something like this, but I would need a rotation as well as a position.
     
  25. chrismarch

    chrismarch

    Joined:
    Jul 24, 2013
    Posts:
    320
    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.
     
    Last edited: May 6, 2015
    alexandre-fiset likes this.
  26. Kuba

    Kuba

    Unity Technologies

    Joined:
    Jan 13, 2009
    Posts:
    407
    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.
     
  27. RyuMaster

    RyuMaster

    Joined:
    Sep 13, 2010
    Posts:
    468
    >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?
     
  28. sleepCircle

    sleepCircle

    Joined:
    Jun 6, 2015
    Posts:
    6
    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. :]
     
  29. Stephan-Tanguay

    Stephan-Tanguay

    Joined:
    Jan 27, 2011
    Posts:
    21
    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.
     
  30. DrewMedina

    DrewMedina

    Joined:
    Apr 1, 2013
    Posts:
    418
    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
     
  31. alexandre-fiset

    alexandre-fiset

    Joined:
    Mar 19, 2012
    Posts:
    443
    As of Unity 5.1.1, it still does not work.
     
    DrewMedina likes this.
  32. Kuba

    Kuba

    Unity Technologies

    Joined:
    Jan 13, 2009
    Posts:
    407
    hippocoder likes this.
  33. DrewMedina

    DrewMedina

    Joined:
    Apr 1, 2013
    Posts:
    418
    Thanks for the info, great to hear!
     
  34. alexandre-fiset

    alexandre-fiset

    Joined:
    Mar 19, 2012
    Posts:
    443
    Whoa! Didn't know about the existence of this page- straight to the bookmark bar! Thanks :D
     
  35. GreenRabbit

    GreenRabbit

    Joined:
    Nov 27, 2013
    Posts:
    4
    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.
     
    Last edited: Jun 26, 2015
  36. MS80

    MS80

    Joined:
    Mar 7, 2014
    Posts:
    335
    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.)
     
  37. Meltdown

    Meltdown

    Joined:
    Oct 13, 2010
    Posts:
    5,441
    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.
     
  38. rzigura

    rzigura

    Joined:
    May 26, 2015
    Posts:
    2
    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,
     
    Last edited: Sep 24, 2015
  39. RyuMaster

    RyuMaster

    Joined:
    Sep 13, 2010
    Posts:
    468
    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.
     
  40. Actiview

    Actiview

    Joined:
    Dec 4, 2013
    Posts:
    33
    Any updates on this feature in 5.3?
     
  41. alexandre-fiset

    alexandre-fiset

    Joined:
    Mar 19, 2012
    Posts:
    443
    It works pretty well actually in 5.3 with the new SceneManager.
     
  42. freerangegames

    freerangegames

    Joined:
    Sep 16, 2013
    Posts:
    2
    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?
     
    Sung Woon Jang likes this.
  43. alexandre-fiset

    alexandre-fiset

    Joined:
    Mar 19, 2012
    Posts:
    443
    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.
     
  44. rafikc92

    rafikc92

    Joined:
    Jun 28, 2015
    Posts:
    1
    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.
     
    robstardotstar likes this.
  45. robstardotstar

    robstardotstar

    Joined:
    Jan 12, 2016
    Posts:
    6
    Last edited: Jul 13, 2016
  46. robstardotstar

    robstardotstar

    Joined:
    Jan 12, 2016
    Posts:
    6
    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. :D
     
    Last edited: Jul 15, 2016
  47. E2R_Ben

    E2R_Ben

    Joined:
    Oct 30, 2009
    Posts:
    143
    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?
     
  48. goat

    goat

    Joined:
    Aug 24, 2009
    Posts:
    5,177
    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.
     
  49. alexandre-fiset

    alexandre-fiset

    Joined:
    Mar 19, 2012
    Posts:
    443
    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)
     
  50. alexandre-fiset

    alexandre-fiset

    Joined:
    Mar 19, 2012
    Posts:
    443
    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.
     
    goat likes this.
unityunity