Search Unity

  1. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  2. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

So. Many. Lightmapping. Problems. (Unity 5)

Discussion in 'Global Illumination' started by JamieVRcade, Apr 23, 2015.

  1. JamieVRcade

    JamieVRcade

    Joined:
    Oct 21, 2012
    Posts:
    32
    UPDATE: 8/8/15

    This problem happened again and I think I have solved it. I first tried manually deleting every ounce of Gicache in my computer. When that didn't work, I noticed that a doorknob model that I brought in from Sketchup never had its UVs made by Unity. It was around the same time that this problem reared its ugly head again. I had it generate UVs and rebaked and all of the problems went away, so far.

    MAKE SURE THAT EVERY MODEL THAT YOU ARE USING HAS ITS UVS GENERATED BY UNITY IF THEY DIDN'T COME PREPARED. See if that helps. I will post here if it happens again in this model.

    ~~~~~~~~~~~~~~~~~~~~~~

    I have been having a few problems with lightmapping over the years. With the jump from Beast to Enlighten, I thought they would go away. Not only did the original issues not go away, more came. It's maddening and now I turn to you all for some help. I have searched the forums and have found clues and tips for some of these, but NOTHING has helped.

    Background: I am taking models designed in Revit and putting them into 3DS Max using the Suite Workflow feature. I am then using the Autodesk Material Converter script to get the materials into Unity. This process works great and always has. I then generate lightmap UVs in Unity, which takes forever, but works. In the past, and currently, I use a many different settings from baked lighting only, Realtime and baked, all sorts of padding values, a range of quality values, default values...these problems still persist.

    I have a wide range of lights. One directional and about 2 dozen spot. I have changed the pixel light count to 50 to ensure all of the lights are represented in the scene.

    My issues.

    1-Splotchy dark spots on random geometry (black spots on vertical bronze trim)
    LM1.PNG
    This is a particularly irritating issue as it happens at random. I can rebake and sometimes it will go away and it may, or may not, appear on another object. I often have to clear my entire lightmap and rebake and see if that does it. Upon clearing and rebaking this one WITH THE EXACT SAME SETTINGS, the problems were solved...until they came back again. The randomness is what concerns me. You can't see it in this shot, but there are three stools on the left. The one in the middle is completely covered in these spots, while the two identical ones near it are fine.

    2-Dark spots on seams of geometry
    lm2.PNG
    These spots really bother me. At first I thought it was ambient occlusion, but even at 0, they still persist. Higher resolutions make them higher quality black spots. Different padding values does nothing. I have re-generated UV maps for these objects with a wild variety of settings. Nothing fixes it. If anything, it scoots the black spots around.

    Issues 1 and 2 occurring in the same scene, at the same time, in the same view in a different part of the model.

    lm3.PNG
    Hooray.

    3-Strange banding when light passes through transparent material
    lm4.PNG

    This is the only NEW issue. This wasn't a thing in Unity 4 that I ever ran into. I don't know why this is happening. The alpha channel is all the way down and the standard material is set to transparent.

    BEHOLD! MORE RANDOMNESS!!
    lm5.PNG
    This really put me over the edge. I changed the resolution from 40 to 10 to test baking. This is the result after bake. I cleared the lightmapping and tried again. Same thing. I cleared the lightmapping completely, disabled all lights, and nothing changed. I have to restart Unity after erasing all of my lightmapping work in order to get it to display correctly, and then all of the problems in this thread start over.

    My specific settings change all the time, which leads me to believe that they have nothing to do with these issues. I am on a Titan X, 3.5ghz intel CPU, 32 GB of RAM. Over the past few years, I have never been able to reliably eliminate any of these problems. They either show up or they don't.

    Additionally, in Unity 5, I can select the shadow strength when I toggle a light to realtime, but the option goes away when I change it to baked. However, the value still applies in the editor and in baking. It seems that in order to change the shadow strength of a baked light, I need to change it to realtime, make the changes, and then go back. A bug or a feature?

    For lightmapping issues, if anyone has any insight, I would love to hear it. If I have to bake in 3DS Max instead, I may end up doing that, however I fear that will lead to it's own set of issues.
     
    Last edited: Aug 9, 2015
    AldeRoberge, Trekopep and Tudor like this.
  2. Nullzero

    Nullzero

    Joined:
    Apr 24, 2013
    Posts:
    12
    Yup. S***'s busted. Makes me wonder how they managed that awesome GI arch vis lighting promo video! Must have been a bitch to get working!

    I posted stuff about the black spots as well, and how I solved it:
    http://forum.unity3d.com/threads/gi-baked-point-light-blotching-black-spots.319940/

    But... no replies. So maybe it isn't working for anyone but me.

    I have a feeling GI is gonna be busted for a while. Even once its fixed, it's gonna take some time until everyone adjusts. The amount of settings that are tweakable in Enlighten is daunting... Bounce numbers, bounce intensity, global GI intensity, baked, unbaked, real time... it's hard to know if a Enlighten is broken, or if we are all just using it wrong.
     
  3. JamieVRcade

    JamieVRcade

    Joined:
    Oct 21, 2012
    Posts:
    32
    Yeah, I feel EXACTLY the same. I followed your instructions just before I made the thread. It didn't seem to fix anything. Once I saw THOSE options, I felt even more like you do...is it Enlighten or is it me not knowing these millions of values and how they may or may not be used to correct a problem that I may or may not be having?
     
  4. JamieVRcade

    JamieVRcade

    Joined:
    Oct 21, 2012
    Posts:
    32
    Update: things just get worse.

    lm7.PNG

    I thought the issue stemmed from having so many lights. This is with one directional light (the light component is turned off on all of these bulb gizmos) with unaltered lightmap settings in a COMPLETELY NEW project. Now the ceiling and some of the walls have decided to give me trouble. The randomness of these issues is the largest concern.

    Since I made the post, I have solidified my workflow for attempts. It's ridiculous.
    1. Clear all lightmap data from the last failed attempt
    2. Ensure that all of the lights are set to baked, not realtime
    3. Ensure that the objects I want to test on are marked as static
    4. Set resolution
    5. Bake
    6. Wait
    7. Upon completion, search the scene for the inevitable NEW error
    8. Cry
    9. Clear all baked lightmap data
    10. See that the scene has become EXCESSIVELY blown out, even with all lights disabled.
    11. Save, exit
    12. Re-open and see that the blown out problem is solved
    13. Re-enable lights
    14. Change one lightmap setting
    15. Repeat
    Below is the screenshot of the same scene, but with my own custom lightmap settings as outlined by Nullzero (just to see what would happen)
    lm8.PNG

    However, upon changing the resolution from 10 to 20, this happens:

    lm9.PNG

    Doing this on a completely separate computer (4 ghz, Titan X, 16GB RAM) yields the same results, albeit random.
     
    Last edited: Apr 24, 2015
  5. DreamEnder

    DreamEnder

    Joined:
    Apr 12, 2011
    Posts:
    191
    Any updates? I'm getting the same issue.
     
  6. JamieVRcade

    JamieVRcade

    Joined:
    Oct 21, 2012
    Posts:
    32
    Nothing. I was using Simplygon models originally. I went back to normal models and most of the issues went away. I covered up the offending geometry, so it's not a real fix.
     
  7. SpiriTx

    SpiriTx

    Graphics QA

    Joined:
    Apr 12, 2012
    Posts:
    252
    Could you please report a bug with this scene attached and post the number here?
    I'd take a look
     
  8. topofsteel

    topofsteel

    Joined:
    Dec 2, 2011
    Posts:
    999
    @SpiriTx I appreciate Unity's involvement in the forums since Unity5's release, I really do, it's a great thing! But 'file a bug report' is getting a little old. I see the same issues time and time again by wave after wave of frustrated would be lightmappers. Every time I lightmap I see these issues, do you really not get them in-house testing? Is this all news to you?
     
  9. SpiriTx

    SpiriTx

    Graphics QA

    Joined:
    Apr 12, 2012
    Posts:
    252
    Most problematic from my testing was Directional Specular, it sometimes provided artefacts, but never anything so wrong. I have a number of projects which I constantly use for baking and they look good. Problem is that Lighting is so dependant on the geometry used that we constantly get these different, sometimes corner-case, scenarios.

    A lot of issues raised are caused by incorrect UVs, normals or compression, especially when Jamie mentioned that most of those issues were present in Beast too, so it's hard for me to tell something more unless I can take a look at it myself.

    You are right that we have quite a significant number of bugs right now and experience for the person using it might not be optimal, but I can assure you that we trying our best to make it better. Devs have been squashing bugs for months now, we also have a set of new docs and tutorials being prepared to ease the pains of using lightmapping.
     
  10. topofsteel

    topofsteel

    Joined:
    Dec 2, 2011
    Posts:
    999
    How come we haven't seen any significant improvement in lightmapping/GI. I think you moved a button on the UI once or something.

    I agree, Directional Specular is most problematic. Will the new Docs include workflow tips, mesh preparation, ideal scenarios, limitations? When can we expect the new GI system to work correctly? You should take your whole iOS team and tell them they can't go home until it's done. ;)
     
  11. ImpossibleRobert

    ImpossibleRobert

    Joined:
    Oct 10, 2013
    Posts:
    521
    I also get artifacts after baking a lot lately (5.1) which is quite frustrating when there is no workaround I can come up with so far except setting the lights to realtime. Any ideas why these black patches appear are highly welcome! When do these artifacts generally appear? When switching the lights to realtime everything looks great.

    baking_artifacts.PNG baking_artifacts2.PNG
     
  12. SpiriTx

    SpiriTx

    Graphics QA

    Joined:
    Apr 12, 2012
    Posts:
    252
    In the point releases (5.1, 5.2) mostly.

    Yes, most of that will be in the docs or tutorials. Answers to all of the confusing topics have been gathered. Well it works correctly in a lot of scenarios already, so it mostly depends on the thing you are trying to achieve and what exactly is in your way right now.

    Why iOS team?
     
  13. SpiriTx

    SpiriTx

    Graphics QA

    Joined:
    Apr 12, 2012
    Posts:
    252
    Those look like compression artefacts. Please try unchecking "Compressed" in Baked GI section
     
  14. ImpossibleRobert

    ImpossibleRobert

    Joined:
    Oct 10, 2013
    Posts:
    521
    I tried all kinds of parameter combinations but nothing seems to remove the black patches. Compression is also deactivated. Any other options you see?
     
  15. topofsteel

    topofsteel

    Joined:
    Dec 2, 2011
    Posts:
    999
    Looking through the release notes of the point releases, there are dozens of iOS updates and fixes. I was joking. And yes, in a lot of cases I can get satisfactory results. And overall the system looks amazing, it's a huge improvement over 4.x, great job! Please put loadSceneAdditive to the top of the list. Thank you!
     
  16. SpiriTx

    SpiriTx

    Graphics QA

    Joined:
    Apr 12, 2012
    Posts:
    252
    It might be incorrect UVs or normals, please check your meshes.
     
  17. SpiriTx

    SpiriTx

    Graphics QA

    Joined:
    Apr 12, 2012
    Posts:
    252
    LoadSceneAdditive support is almost done, I did first testing round on it last week.
     
    Tudor likes this.
  18. JamieVRcade

    JamieVRcade

    Joined:
    Oct 21, 2012
    Posts:
    32
    Unfortunately, this project and these assets are under NDA. Images are fine, but I can't release the files. If I run into it again with a model that isn't under NDA, and I can reliably reproduce, I will take the step you outlined. Thanks for the help!
     
  19. duke

    duke

    Joined:
    Jan 10, 2007
    Posts:
    763
    Some of those issues stand out and I would be very surprised if they have anything to do with Unity:
    1) UV island too small/stretched or geometry flipped.
    2) UV seam is in a horrific place, not enough padding?
    3) Elevator definitely flipped geometry, chairs are S***ty geometry/uv's.

    Revit geometry is particularly horrendous, and nothing Unity does can magically fix it.
     
  20. Bruce_GMC

    Bruce_GMC

    Joined:
    Oct 23, 2014
    Posts:
    65
    I haven't ever used revit but if you aren't editing your uvs before importing the meshes in to unity then problems with normals are bound to happen. In medium scale environment applications a difference in tessellation calculations between unity and maya alone can means hours of mesh and uv repair on the front end of the production pipeline especially if you edit the mesh at all in unity with tools such as vpaint, which are rendered useless because of a difference in vertices index.

    If you can enable a viewfinder setting called backface culling, and granted the material being rendered in revit is one sided, your viewport will show you which faces are reversed. Another error that can pop up in a mesh is a set of flipped uvs. Maya allows you to shade your uvs, blue for out and red for in, when viewing the uv editor window but it's something to check.

    I played with the lightmapping settings for a good 2 or 3 days in a scene with unity meshs, a custom shaderforge shader and for a control the standard unity shader before I started trying to bake actual scenes. Success came from turning all settings as low resolution as possible and slowly increasing lightmap and texel resolution until the result was satisfactory. I start any new lightmap process by switching GI Directional mode to non directional and reducing the baked resolution from the default 40 texels per unit to 4 texels per unit. Enabling a small amount of final gather and finding the right scale in the lightmap per object is important too. All our objects are made from maya, all our uvs have been touched before they see unity so we aren't running in to problems with artifacts yet but in certain scenes the light transport stage continuously produces errors detailing that the radiosity core is corrupted. Resulting in halfbaked scenes if I'm lucky.

    So consider yourself lucky that your issue is with your models and not with your shaders and plugins. Currently I'm trying to bake lightmaps using a shader with an opacity clip channel and it's making unity do some very crazy things. ie: flipping normals and failing to find shadows.

    I'm a team manager for my company and if asked I would have no problem releasing game files to Unity if it was strictly business. Unity doesn't release these files, I would recommend requesting permission

    edit- oh I also turn real time rendering off like a mofo, and do it all at once. Lights can be set to mixed so you can preview them.
     
    Last edited: Jun 3, 2015
    SpiriTx likes this.
  21. ImpossibleRobert

    ImpossibleRobert

    Joined:
    Oct 10, 2013
    Posts:
    521
    Thanks SpiriTx and duke for your comments. I invested more time to narrow down the issue but did not succeed. I took the sample scene from the elevator asset which looks nice and simply rebuild the lightmap and voila, black patches again.

    I created bug 702231. Maybe support can help me to find out what is wrong. How would one go about checking errors in third party assets?
     
  22. testure

    testure

    Joined:
    Jul 3, 2011
    Posts:
    81
    yeah, i've pretty much gone back to baking lightmaps in v-ray. talk about a step backward in terms of efficiency... had high hopes for enlighten, kinda surprised they yanked Beast when it was such a stable and proven lightmapper by the end of the 4.x cycle.
     
    JamesArndt and MutantGopher like this.
  23. ninjanosui

    ninjanosui

    Joined:
    Jul 12, 2013
    Posts:
    54
    I'm having similar issues. One of my findings is when I disable Ambient Occlusion my UV's get screwed up.(overlapping uv's). Other findings are that setting model scale to 1 helps a lot speed wise.
     
  24. Disastercake

    Disastercake

    Joined:
    Apr 7, 2012
    Posts:
    317
    I've been having these problems as well. The weird part is that the artifacts seem completely non-sensible and random. For example I will have 4 houses in a scene (same model). 3 houses are fine, and the fourth will randomly have blotches of pure black all over it. Then I might change something, like make that one house not cast shadows, then a lamp post on the other side of the scene (no where near the houses) will become blotchy (when it was fine before).

    The artifacts seem to happen less the higher the texel resolution, but I really don't want 20MB - 60MB of lightmap data for my game in each scene. That would add up to multiple GB of just lightmapping data.

    The kicker is that beast worked fine for me, and it was a LOT faster to iterate through changes with beast. This new system takes no less than 30 minutes on the lowest settings, when Beast would take 10 or less. I wish it would have been able to stay in for Unity 5.

    P.S. No compression used.
     
    Last edited: Jul 29, 2015
  25. SpiriTx

    SpiriTx

    Graphics QA

    Joined:
    Apr 12, 2012
    Posts:
    252
    Stretched UVs caused problems like the elevator mentioned previously, but it was fixed in 5.2 b4, so it is way better now. Please inform us about your results when you get a chance to use it.
     
  26. Kuba

    Kuba

    Moderator

    Joined:
    Jan 13, 2009
    Posts:
    416
    Hey @JamieVRcade,

    Issues like this seemingly random spots typically come from some geometry overlapping in the atlas. You should be able to check if something is overlapping by going to the Lighting window and checking out the Baked Intensity mode in the Preview in the Object tab. Selecting the different objects that you have will show you if any of them overlap. If the blue wireframe UV overlays of those overlap, that's not good as the two objects will fight for a certain space in the lightmap and hence give random artifacts.

    In 5.2.0b4 we fixed issues that caused UVs of different objects to overlap. It is still possible that UVs of one object will be overlapping with itself. However, that should not happen if you're using Unity's unwrapper (see "Generate Lightmapping UVs" option) on all of your geometry.

    You should be able to understand where do those come from by looking at the same Preview window in the same mode as suggested above.
    I'm guessing that you're only adjusting the padding in the Lighting window in the Scene tab. That controls the padding between the different objects. The padding between UV islands of a particular object is controlled with Pack Margin in the Model Importer in the Advanced options under "Generate Lightmapping UVs".

    Once we switch to per instance baked UVs the padding parameters will be unified. Right now, however, you need to set the Pack Margin separately. You can imagine that the pack margin allows you to define the amount of texels between the UV islands assuming that the object fills up the entire 1024x1024 lightmap. Typically that is not the case though, so if you set the Pack Margin to 4, but the atlassing ends up giving just a 128x128 area in the lightmap for your object, then the margin in the lightmap will end up being just 0.5.

    We're not aware of such an issue. We would really appreciate getting a bug report on it.

    Seemingly strange lighting like that is typically caused by disabling lighting in the scene view (which makes the scene use a directional light pointing in the same direction as the camera). To view the proper lighting you should make sure the button with the sun is enabled in the bar at the top of the scene view.

    This is by design, but...
    Shadow strength allows some of the direct lighting to show up in the shadows. When using realtime lighting only it's a poor man's substitute for GI. When using mixed mode lighting it allows for tweaking the strength of the shadow from dynamic objects, so that they mix with baked shadows better. This feature doesn't make much sense for fully baked lights, as you get proper GI there and there is no need for mixing.
    That said, currently we do preview baked lighting with realtime direct lighting and realtime GI (as the precompute needed for realtime GI always finishes before the bake can even start) and there the shadow strength is used when previewing. It shouldn't be, we'll make it behave consistently with what the UI shows.
     
  27. Kuba

    Kuba

    Moderator

    Joined:
    Jan 13, 2009
    Posts:
    416
    Hey @Bruce_GMC,

    An issue with corrupted radiosity core was fixed in 5.2.0a4. You can get the latest beta release with the fix from http://unity3d.com/unity/beta/ or wait for the final release for about a month.

    Previewing baked GI with realtime GI is not specific to the mixed mode being set on a light. It works both in mixed and in baked modes.
     
    Bruce_GMC likes this.
  28. JamieVRcade

    JamieVRcade

    Joined:
    Oct 21, 2012
    Posts:
    32
    Check out the update text in the beginning of the thread. Kuba, does this make sense? Could this have been my issue all along? Also, thanks for the detailed reply. I am just now seeing it.
     
  29. aimetribolet

    aimetribolet

    Joined:
    Sep 26, 2015
    Posts:
    3
    I just got through the same problem here with lightmap nightmare artifacts in Unity 5.
    (New with Unity and advanced with 3ds max 2015).

    Currently, Unity 5 documentation is really lacking about how to deal with issues concerning imported object, UVs and lightmapping.
    Unity Documentation Team should aware us from the start that if UV are not properly set (no overlapping surfaces in UVs) the lighmapping wil generate unexpected awful artifacts like showed in the figure below.

    Here is the difference below if we miss the UV setup.


    2 workarounds:

    1)
    - Go to the mesh model dealing with lighmapping artifacts
    - On the Model tab check the "Generated Lightmap UV" check-box
    - Clear baked data and Build the new one.
    Unity_Generated_UV_Setting.jpg

    2) Simply add a "flatten UV" unwrap modifier on all standard primitive objects to solve overlapping UV surfaces before importing them in Unity.

    Result in either way in the figure below
    Unity_Generated_UV_Lightmap.jpg

    (with 3ds max 2015 and Unity 5.2.0f3 Personal)
     
  30. MikeDPad

    MikeDPad

    Joined:
    May 23, 2013
    Posts:
    3
    Just wanted to add that I also ran into this problem and it was indeed the UV2 coordinates overlapping which produced these artifacts.

    I have some popular assets from the store that look fantastic with their separate materials. Being that I was making something for mobile VR, I combined the materials into a single atlas using Mesh Baker while leaving the models separate (for culling purposes). Because I had previously used these models with baked and realtime, I was left scratching my head for the better part of an afternoon because I'd never come across this problem. Turned out that Mesh Baker had some options specific to "Lightmapping UVs" where I was unknowingly generating new UV2 coords. I found this thread and that helped clear it up for me... I just changed the option to "Copy_UV2_unchanged" et voila! Enlighten as I expected it... Cheers, Kuba!

    mesh_baker_uv2.png
     
    idurvesh likes this.
  31. LadyR0uge

    LadyR0uge

    Joined:
    Aug 1, 2015
    Posts:
    8
    I am having lightmaps issues as well where some lights bake fine and others are not taken into consideration. We are using Unity 5.2.1p4. We use the "generate lightmaps" by unity to generate our lightmaps. The lightmaps seem to bake fine at the resolution of 4, 5, 10 and 20 (I am currently waiting to see what is the result at 40). We get this weird problem at 15. I also got similar result (scene halfbaked) previously with resolution as low as 5. I am using the default material provided by unity, nothing fancy here. Is there a maximum of lights that unity can handle in one scene? I had to break down my scene into smaller scene to be able to bake (it was already quite small to begin with).

    I even had at some point the following error: Failed executing external process for Bake Visibility job.
    The only thing I did at that time was to put a transparent material on a mesh in my scene.
    Is any of you had problems with transparency that could affect baking lightmaps?


     
  32. LadyR0uge

    LadyR0uge

    Joined:
    Aug 1, 2015
    Posts:
    8
    I have updated unity to 5.2.2f1 yesterday and I am happy to report that, so far, all my lightmaps bugs seem to go gone!

    UPDATE
    I actually downloaded the 64 bits version by accident. When I tried again with 5.2.2f1 but in 32 bits, all my bugs came back. So it seems to have to do with 32 bits vs 64.
     
    Last edited: Oct 27, 2015
  33. Max_Bol

    Max_Bol

    Joined:
    May 12, 2014
    Posts:
    168
    I'm currently using the Beta 5.5.0f2 version as I didn't have time to upgrade to the newly released 5.5.0p1.
    I can tell that, in my version, the Generate Lightmapping UVs option will generate overlapping UVs for any Mesh that has multiple materials. For example, if you're using multiple materials (and UVs relevant to each UVs IDs) on 1 big Mesh (containing multiple parts) like a building, the Generate Lightmapping UVs option won't detect the multiple material setup and will generate the UVs as if the mesh had only 1 material and 1 set of relevant UVs (as if all UVs IDs on the mesh were flatten into a single 1 ID before Unity generate the lightmap UVs.)
     
  34. vonpixel

    vonpixel

    Joined:
    Oct 2, 2012
    Posts:
    31

    Well. I think this just might be what is plaguing me right now. Im building a large environment right now for a project and it requires a lot of real world distances and iteration which I have found much easier to make inside of Modo and maintain in basically 1 large .fbx.

    Ive been wasting my time for the better part of this week trying to figure out why im getting blotchy effects in my dark basement walls. I think what you are saying here might be my problem (and Ive searched a lot of threads trying different things).

    Would the best solution here to manually pack UVs myself in UV2? I suppose that wouldnt be too difficult as I have everything unwrapped well to begin with. I guess Ill have to figure out just how many UV maps ill need because Im assuming its best to combine things to less maps than their are objects based off looking at the light maps that unity generates?
     

    Attached Files:

  35. IgorAherne

    IgorAherne

    Joined:
    May 15, 2013
    Posts:
    393
    It's really horrible - upgraded system to have 24 gigs ram, placed unity & GI cache folder onto PCIe M.2 disk, trying to bake in Enlighten, only to come back 8 hours later and see that clustering 5/11 is at 2200 remaining jobs.
    Also spits out errors like

    Failed writing to: 'C:/MyDrive/GameName/Custom GI cache/76/763455f90f37b49f430802ee434ece27.pps.tmp'
    Failed creating system: 0xb872010168e458a12c2627f030ff20a6.
    lightmap errors.JPG


    Looking into editor log, getting errors like
    GIFileCache::OnRemoveFile 'C:/MyDrive/Vigor/Custom GI cache/c2/c21f0633d87d9e0c7791385206d07596.pig'.
    GIFileCache::OnRemoveFile 'C:/MyDrive/Vigor/Custom GI cache/54/54201e804269b0feffd51d044f41a526.bip'.
    GIFileCache::OnRemoveFile 'C:/MyDrive/Vigor/Custom GI cache/c2/c21f0633d87d9e0c7791385206d07596.nrm'.
    GIFileCache::OnRemoveFile 'C:/MyDrive/Vigor/Custom GI cache/0d/0d229ad23d0c8b9bb4ffe24b461aab2b.nrm'.
    GIFileCache::OnRemoveFile 'C:/MyDrive/Vigor/Custom GI cache/66/66b93cab5cb47c5eaed2b9a6ae2e2371.pig'.
    GIFileCache::OnRemoveFile 'C:/MyDrive/Vigor/Custom GI cache/66/66b93cab5cb47c5eaed2b9a6ae2e2371.ppg'.
    GIFileCache::OnRemoveFile 'C:/MyDrive/Vigor/Custom GI cache/66/66b93cab5cb47c5eaed2b9a6ae2e2371.nrm'.
    Enlighten error: 'Saving instance debug failed.'. Return code 0.
    Failed writing to: 'C:/MyDrive/Vigor/Custom GI cache/41/41488f9c3c6cc5a534d51fa767d77619.pps.tmp'.

    I know that people are suggesting lowering the texel resolution, but have a look at this resolution, -isn't it reasonable?
    We've adjusted every single object's resolution, including lowering resolution of objects in the distance, etc

    res.JPG

    There aren't large pieces (max one in our scene is a ground tile, about 15m x 15m)

    Progressive lightmapper doesn't seem to perform final gather, we are not getting any well-defined colorbleeding anywhere in the scene, unless objects are directly emissive. Progressive Lightmapper's "Albedo Boost" and Indirect Intensity" don't seem make final bounces any juicier, so we decided to get back to Enlighten, to see if it would produce a better result, only to get these errors.

    The image above is rendered with Progressive Lightmapper, however all these pink colors come from glowing objects - none of usual objects contribute any colorbleeding, even if they are illuminated by such an emissive surface (neither by an area light). We are only getting a glow from emissive surfaces but no bounces (there is no final gather for texels)

    Coming back to discussing the Enlighten I think I know what the problem might be.
    Enlighten runs out of ram memory when processing a scene - perhaps it's due to some sneaky object having polygon that's blown up in the UV-table, so it's requesting massive amounts of texels.
    Perhaps you guys can introduce a precaution-check to see if 3D-models have polygons with abnormal amount of texels.

    But then again, this error occurs many times. Horrible, Horrible, Horrible!

    You'd be better off writing a custom voxel solution like

    This one is mine, and it has a couple of serious visual flaws because it was my first ever vxgi, but you could use VXGI for pre-bakes as well, with way larger resolutions. If I am using 128^3 texture and programmed it by myself in 2 months (and it's realtime GI btw, featuring 2 bounces, could be more - like 4+) in my custom engine, your entire team could create an octree, via 1D buffer-texture object , where you would use 8192^3 leaf resolution, and use it for static pre-baked lightmaps - would produce absolutely no lightleaks and would complete in like 15 bloody minutes on a single GPU, resulting in a SUPER HIGH quality.

    @KEngelstoft
    @Kuba
    @SpiriTx
    @Jesper-Mortensen

    If scenes are massive, you could overlap such octrees, rendering scenes in overlapping portions.
    You could even combine it with your current raytracing solution, - to voxelize indirect light, but to only use it for secondary bounces of raytracer
     
    Last edited: Nov 14, 2017
  36. IgorAherne

    IgorAherne

    Joined:
    May 15, 2013
    Posts:
    393
    @KEngelstoft
    @Kuba
    @SpiriTx
    @Jesper-Mortensen

    Here are 13 steps I used to make VXGI. I used 3D texture, but you guys must use octree if you want high resolutions with pre-baked lightmaps. I took it from my comment under my video I've lined above.

    You are not forced to use VXGI as a way to illuminate pixels on screen at the end of deferred rendering. Instead, in the case of baking for static lightmaps, you should output into texels of 2D lightmaps. Current solutions (directed at deferred rendering) reach 512^3 resolution and result in appx 40 fps in 1920x1080. However, in case of baking lightmap, you don't care about fps - all you need is just the only 1 single frame, and obtain it after rendering for 15 minutes. So you can crank up resolutions by way more, and pack data to save GPU memory. You could stream data into GPU, to process octree in portions if you are out of memory.

    We achieve this lighting in several steps:

    1) make triangles into voxels, store them in a 3D texture (which is like a big cube), - this texture contains just Original, unlit colors of materials - will call them "Basecolor" from now on.

    2) Along with the basecolors, store the normal of the voxel in a 3D texture #2.

    3) Illuminate each voxel with your point light sources and store it as another texture #3 (Diffuse 3D texture). Of course, we make such diffuse as lambert*basecolor*lightColor*shadowmapping. If the voxel is emmissive - prevent shadowmapping on such voxel, and store its Basecolor into texture #3 instead (if it glows, then no shadows shall affect/darken it).

    3.5) we must store Alpha=1 for each diffuse voxel in this texture. Empty voxels should have Alpha=0 (But, if your scene is in fog/underwater, alpha might be different)

    4) Mipmap the diffuse texture which we've built in step 3). Notice that we will mipmap Alpha as well. Additional word of caution (I've made this mistake before) is that we don't multiply diffuse by alpha as we mipmap it. We treat them as 4 separate channels, RGBA - each gets averaged on its own.

    5) Create a #4th 3D texture. For each of its non-empty voxels, we need to inspect the voxels around it, to see what light is incoming towards it. Once we will do it - this will be our first bounce. And so we inspect the volume around it in a hemi-sphere, which is oriented along the voxel's normal (calculated in step 2). 5.5) To avoid bruteforcing, we will approximate the hemisphere of the incoming light with several cones. If you have a bouquet of 7 cones - this can be a good approximation. Now, we also need to approximate cones - they can be represented as a sequence of cubes, one above another, where each next cube is larger in size than the one its sitting on top of. Of course, their sizes will grow according to the cone's aperture.

    6) We pick one of the cones, and begin traveling away from our Original voxel, outwards, following the cone's direction. As we travel, we sample or Diffuse texture, accumulating the color as we go further. As we travel further, we take samples at increasing intervals (Remember about the increasing cube sizes). However, we take those samples from a *correct mipmap*, where our traveled interval corresponds to the size of its texel. Let's say we travel 1 voxel outwards and perform a sample. Because we traveled a distance of "1" - this fits exactly into Mipmap Level "0" of our Diffuse Texture. After, say we need to travel a distance of "1.7" - this fits in between of Level 0 and Level 1, so we take samples from both mipmaps, and then use linear interpolation between them to get the final color. This is referred to as "quadralinear interpolation". Then let's assume we need to travel distance of 2.4 etc.

    7) As we are travelling outwards from the cone in step 6, we need to multiply each sample that we take from mipmaps by the Alpha of such samples, and accumulate alpha in a separate variable. As soon as that alpha in a variable goes above 1 or we've reached the lowest possible mipmap of Diffuse - we stop. Notice, we don't try to dim the brightness with multiplying by inverse-square the further our samples lie. This is because our cones already average out data with samples from more low-res mip-maps

    8) Do this for each of our 7 cones, then combine their result and store it in a voxel of our first-bounce 3D texture, declared in step 5). Once again, for this first-bounce texture voxels the Top-Level-Mip should have alpha of 1.

    9) Mipmap your first-bounce texture, similar to step 4)

    10) At the end of a standard deferred pass, once you have all the pixels visible on the screen, restore world position and world normal of each final fragment (fragment that's on the screen) In case of your static lightmaps - every texel of 3d-object textures, because you are not rendering to screen, but to textures. However the analogy still holds, just assume that object 2d textures are your screen). Then for each such fragment perform cone tracing once again. This time however, you will be sampling both diffuse and the first-bounce 3Dtextures.

    11) Once you have diffuse and first-bounce sampled, add them with the color of the Final Fragment - there is your double-bounce Global illumination.

    12) If you refrain from using shadowmapped lights and just use emissive surfaces described in step 3, then you will have the most correct lighting with soft shadows, similar to 7:29 in my video.

    13) You can achieve reflecitons by adding 8th cone, which is much sharper, oriented in a reflected direction (taking into the account the Final Fragment's normal and the direction from Final Fragment to the viewer.

    ----------------

    I will first discuss shadowmapping vs emissive surfaces (without shadowmapping). Afterwards, I'll clarify on how shadows are created without shadowmapping (when using emissive surfaces for illuminating the scene).

    We can either a) use shadowmapping or instead b) completely rely only on emissive surfaces, without shadowmapping.

    If we choose a) then For every voxel, we will have to perform shadowmapping, to see if the voxel's position is obscured by some other fragment when transformed into the light's shadowmap. If the voxel is indeed obscured by something from the light - the diffuse of this voxel should be black, because it's in shadow. Otherwise, it's in light, so calculate its diffuse with the standard formula lambert*basecolor*lightColor. Any result of this stage gets stored into the diffuse3D texture. Diffuse's Alpha shall be 1 of course for any voxel which represents surfaces (and not an empty vacuum space), regardless whether it was in shadow or not.

    If we choose b) then For every voxel we will immediately make its diffuse black by default, unless the voxel is emissive. If that's the case - we will store the "unlit, original" material color into the diffuse texture. Remember about Alpha being 1, it must be one on the highest-resolution mip-level, for mip-mapping to work correctly.

    As you can see, working with shadowmaps can be very resource consuming, since we have to "see how voxel looks from the light's point of view" for every voxel in our 3D texture, AND for every light. On the other hand, working with emissive surfaces just requires us to immediately store emissive color into the diffuse texture or make it black if the object is non-glowing, and this helps us avoid those nasty for-loops.

    So now, regardless of which approach we've chosen, we have a diffuse texture which has some colors stored in it - either dark or colored. Now, we should propagate the light, simulating the bounce.

    To understand of how shadows are created when we use emissve surfaces, think of "shadows" as being the absence of any arriving light

    1) If our voxel contains black diffuse (from the previous step), technically it must be in shadow(as long as such voxel is not empty-space, with alpha of 0). However, it can still "look" at the voxels that are around it, being curious of "what diffuse each of those neighbors has?". Hence Our voxel (originally having its own diffuse as either some color, or completely black) is interested in the diffuse colors of such surrounding voxels. So, it will perform Voxel Cone Tracing described in 4) in my main comment, above.

    2) As it finds out that its (non-obstructed and visible to this voxel) neighbors contain non-black diffuse (even if it's the result of "the unlit color" which we chose with approach b) ), then this original voxel will "accomulate" such colors from its surrounding neighbors. However, if all neighbours were black, then our original voxel will remain black, as there is no light arriving at it from the neighbors.

    If we carry out this procedure for each voxel in our structure, they will contribute their diffuse colors between each other, resulting in a light-exchange between the surfaces such voxels represent.

    This means that this last step could be used for either the first-bounce (if the shadowmapping was used) or to illuminate all the voxels that can observe such emissive voxels (which is still 1st-bounce actually).

    implementing this algorithm should take 3 months (?) with your team of 4 and would end all the suffering + would put you next to (if not above) CE3 or UE4 in lighting
     
    Last edited: Nov 3, 2017
  37. IgorAherne

    IgorAherne

    Joined:
    May 15, 2013
    Posts:
    393
    I've noticed a weird thing, - previously Enlighten Lighting Window settings had 70 resolution in direct and 40 resolution in indirect. The objects in scenes had scale in lightmap to somewhere around 0.1

    After changing the Enlighten Window to have 1 direct and 1.2 indirect resolution, then cranking up resolution of objects in scenes to 5-7 everything started working!

    That must be an issue with Enlighten. In Lightmapping Settings it sais 70 texels per unit, which creates a gazilion of calculations.
    However when changing things around (reducing to 1 but increasing res of individual objects proportionaly) everything seems to work.

    ...so it's not texels per unit? Maybe it's voxels per unit
     
    Last edited: Nov 16, 2017
  38. mistermishhka

    mistermishhka

    Joined:
    Feb 8, 2019
    Posts:
    1
    3d max. Reset XFORM. and there will be no dark spots.
     
  39. drakekaz

    drakekaz

    Joined:
    Jan 16, 2014
    Posts:
    43

    I could kiss you.
     
    IgorAherne likes this.