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

Lightmapping nightmare

Discussion in 'Global Illumination' started by mmwizard, Apr 7, 2015.

  1. Stash329

    Stash329

    Joined:
    Jul 25, 2012
    Posts:
    2
    If someone would not mind, I am also trying to solve a small lightmap issue myself. I am new to lightmapping so my skill in that is extremely minimal but hopefully someone can solve my issue through the picture.
    in the first picture below of the kitchen; that is what the lighting is supposed to look like( before baked picture) but then after I bake the scene and make all objects static, all the lighting in the kitchen disappears and in the back of the kitchen, some weird lighting stuff occurs(second picture). I honestly don't understand what is going on, so if someone could please help me that would be awesome!!. ( all objects in the scene are static and all lights in scene are baked) screenshot1.png issue 1.png
     
  2. Stash329

    Stash329

    Joined:
    Jul 25, 2012
    Posts:
    2
    Nevermind, i seem to have solved the problem, but now my scene is much much more bright than it is supposed to be.
     
  3. Petha

    Petha

    Joined:
    Dec 4, 2015
    Posts:
    26
    The new baking options are really messy. I don't understand why some values are grayed out. I know how to bake a lighmap externally, I just want to Unity 5 to stop getting in my way.

    How do I change the following Baked Lightmap values?


    It should be:

    Tiling X 1
    Tiling Y 1
    Offset X 0
    Offset Y 0
     
  4. Erind

    Erind

    Joined:
    Jul 23, 2014
    Posts:
    56
    why is the clustering mesh broken ?


    higher res

     
  5. Petha

    Petha

    Joined:
    Dec 4, 2015
    Posts:
    26
    Did you let Unity make the Lightmap UV's or made one yourself.
    What is the cluster size in Lightmap settings?
     
  6. Erind

    Erind

    Joined:
    Jul 23, 2014
    Posts:
    56
    unity made it ,the cluster size(1:0.01), (2,3:0.1).
     
  7. j2l2

    j2l2

    Joined:
    Mar 14, 2016
    Posts:
    14
    Hello,
    Stash329, can you please tell us what you changed to fix it?
    Here's a result of a baked nightmare lightmap in Unity 5.4 Beta in a CHIP home where bathroom walls, ceiling and floor were merged, I have no idea where these circles come from but they are in the lightmap:
    Capture.JPG
    Capture2.JPG

    Crying
     
  8. KEngelstoft

    KEngelstoft

    Unity Technologies

    Joined:
    Aug 13, 2013
    Posts:
    1,366
    The way the artefacts look makes me think that your geometry has overlapping UVs (several triangles referencing the same texels in the lightmap). Select a mesh with artefacts and have a look in the Object tab of the lighting window and have a look at how the UVs look when overlaid on the baked lightmap.
     
  9. j2l2

    j2l2

    Joined:
    Mar 14, 2016
    Posts:
    14
    Thanks KEnglestoft! I moved on and redo the scene completely.
    Meanwhile I tried from scratch with simple objects with 2 UV maps each, following the only Unity 5 lightmap tuto I found (http://ogrehead.com/2015/09/how-to-lightmap-in-unity-5/) I still get weird results, please see enclosed scene (packaged).
    Nothing is merged this time.
    I need to do some interior lightmap so all hints, tricks and insights are welcome!
     

    Attached Files:

    Last edited: May 25, 2016
  10. KEngelstoft

    KEngelstoft

    Unity Technologies

    Joined:
    Aug 13, 2013
    Posts:
    1,366
    You are getting these results because the boxes mainly sees backfacing triangles. This is forcing the lightmapper to interpolate from valid clusters further away. Try making the top plane face the geometry underneath, then you should get nice lighting
    Unity_2016-05-31_15-03-29.png
     
    j2l2 likes this.
  11. Superflat

    Superflat

    Joined:
    Mar 19, 2009
    Posts:
    354
    Hello,

    Enlighten is being a pain in the ass because i have 'static' objects that can be turned on and off. Baking the objects in other locations, then moving them seems to lose the light map data.

    So i went ahead and had my artist bake custom lightmaps into separate PNG's. Whats the best way to implement these now? They use the same uv's as the diffuse maps.
     
  12. smoluck

    smoluck

    Joined:
    Mar 8, 2016
    Posts:
    25
    Thanks a lot Cascho01 for sharing your shader. did you've enhanced the shader during the last year , or new work with ShaderForge ?
     
  13. LeagueOfMonkeys

    LeagueOfMonkeys

    Joined:
    Aug 13, 2012
    Posts:
    33
    I am surprised to read this - ShaderForge has been a massive problem with 2 of the projects we have going. Mixed Lights aren't working with the presence of any shader Forge shader in the scenes. We have tested this time and time again and in order to get Unitys new features working with mixed lights - shader forge needs to be totally removed. We are now using Amplify and freakin awesome (and its supported)
     
  14. ekergraphics

    ekergraphics

    Joined:
    Feb 22, 2017
    Posts:
    257
    These three seem to echo very similar problems, which is also what I'm experiencing. We import from CAD data, which generates overlapping UVs that Unity cannot seem to fix by itself, despite allowing it to generate its own.

    I really want to switch to a workflow where lightmaps are generated externally (in Max or Blender), but again, judging from the above three comments, there doesn't seem to be a good workflow for this yet?

    Will that Octane Render integration that was mentioned in the opening post that now seems to actually happen change any of this? (It's been two years since the topic was started.)
     
    Garrettec likes this.
  15. KEngelstoft

    KEngelstoft

    Unity Technologies

    Joined:
    Aug 13, 2013
    Posts:
    1,366
    1. Lightmap UVs generated by Unity should not overlap. If they do please report it with the object in question attached to the bug report and we can fix that.

    2. We are looking into a way of visualizing UV overlap.

    3. Did you try the preview of the progressive lightmapper available in 5.6+?
     
  16. leitecunha

    leitecunha

    Joined:
    Jun 26, 2013
    Posts:
    7
    Hi everybody. After struggling to integrate my externally rendered lightmaps into Unity, and having no success with what I found, I created my own shader. It's called Standard Plus and you can simply plug in your lightmap textures baked for the models' second UV channel.

    In addition to that, It supports up to 5 lightmaps per material, so you can tweak their color and HDR levels at runtime, essentially doing a realtime light mixing, like day/night lighting... different interior lighting setups, etc.

    I hope you all like it!! Thanks! This is it: https://www.assetstore.unity3d.com/en/#!/content/93745
     
    JamesArndt likes this.
  17. leitecunha

    leitecunha

    Joined:
    Jun 26, 2013
    Posts:
    7
    By the way, it is basically the standard shader, plus the external lightmaps feature (and the ability to create realistic glass and translucent materials as well). No fancy weird shader UI with crazy inspector buttons and what not.
    That's it,
     
  18. JamesArndt

    JamesArndt

    Joined:
    Dec 1, 2009
    Posts:
    2,932
    I'm dealing with an issue that seems related to prior issues mentioned in this thread. I'm using 2017.3.0f3 and I am producing my own UV2 lightmap UVs in 3ds Max. I have the "Generate Lightmap UVs" option unchecked in the Unity editor. However when I look at the charts for the geometry sections I see my UV islands (charts) moved and arranged on maps I did not lay them out on. Obviously some kind of auto rearranging of my UVs is occurring at some point. I simply want to use the UV layouts I've created in 3ds Max for each geometry section. I keep seeing "Preserve UVs" as a checkbox in some documentation, but this checkbox doesn't exist anywhere I can easily find it. If anyone has any helpful info that would be amazing.

    Here is an example of my UV charting in Unity. Inside of that red outline, all of those geometry sections are laid out onto one single texture map (all islands in 0-1 space). However looking at the Unity charting, I see all of these multicolored sections telling me that it's broken out into different areas by Unity.



    Another example as I scroll through all of the charts in Unity. Here is an image of one of the 1024px x 1024px lightmap texture charts. I did NOT lay out my UVs this way or with this much wasted space. Plus there are bits and pieces on some of these charts that aren't related to each other...i.e. in this image there is a piece of a banner sign on the texture for the track asphalt surface!

     
    Last edited: Apr 15, 2018
  19. fourche13

    fourche13

    Joined:
    Apr 20, 2012
    Posts:
    33
    Hey, I encounter this issue with my custom UV2 using GPU progressive lightmapper. ( CPU is not an option, it's too long to bake a level )
    I create my custom UV2 without overlapping, I use grid snapping, island padding of 4 pixel for a 128 texture size, uncheck generate lightmap uv in Unity in order to use my UV2.

    But the problem is that Unity seems to create UV chart like he want, and do not respect at all my UV2 island ( which is pretty simple, just a rectangle ) And so I notice weird seams in middle of face on the lightmap, and those seams match perfectly with the baked UV chart generated by unity. How to fix it ??? ^^ I searched for a long time now, but it seems nobody got the response, why make perfect UV2 if the engine doesn't care about the imported fbx.

    Or I missed something .... well It's not in order to compare engine, But I have absolutely no problem in Unreal engine 4 with those meshes. unitylightmapissue.jpg
     
    JamesArndt likes this.
  20. JamesArndt

    JamesArndt

    Joined:
    Dec 1, 2009
    Posts:
    2,932
    The Unity lightmapper doesn't care about your UV2 lightmap UVs. We had this discussion earlier and Unity staff had said they are working on implementing an option to turn on that will maintain your 3D application authored lightmap UVs. Currently it moves them all around, it even rotates them and it almost always creates a far less optimized UV layout.
     
    Cascho01 likes this.
  21. pitibonom

    pitibonom

    Joined:
    Aug 17, 2010
    Posts:
    220
    it appears unity offers no control on UV. i got the same problem and as long as unity will refuse the user to choose an UV set for the final lightmap texture ( and would also be nice to be able to choose the target texture... ) there will be no solution.

    I'm sure it's just well.... 15-20 lines in the code but..... simple things are not welcome in unity's GI system :p
     
    JamesArndt likes this.
  22. fourche13

    fourche13

    Joined:
    Apr 20, 2012
    Posts:
    33
    Ok so no miraculous solution ... because Uv lightmap generated by Unity is not an option, too much unpredictable. Well thanks for the reply JamesArndt, and In case I found something interesting to fix my issue I'll let you know; BUt I guess a lot of people already tried with no result. unfortunately. From what I read from the unite2018 Tokyo, it seems that the Uv chart are created mostly using the normals of our meshes.

    https://fr.slideshare.net/UnityTechnologiesJapan/unite-2018-tokyo-96503976

    page 31

    And the issue come from the fact that unity lightmapper use those chart to define the limit filtering, which create visible seams.

    Maybe the solution would be to let unity calculate the normal instead of import them.... I will give it a try.

    Edit : I tried, still the same UV charts....
     
    Last edited: Feb 26, 2019
    JamesArndt likes this.
  23. fourche13

    fourche13

    Joined:
    Apr 20, 2012
    Posts:
    33
    Is Bakery the solution ^^ ??? People seems happy with this GPU lightmapper.
     
    JamesArndt likes this.
  24. DavidLlewelyn

    DavidLlewelyn

    Unity Technologies

    Joined:
    Aug 14, 2012
    Posts:
    33
    Presently Unity packs lightmap UVs into Scene-wide atlases using a tile approach. This is whether generated on import or supplied by the user. The square representing the 0-1 coordinates of each object's UVs are scaled and offset in order to pack into Scene altas(es). This is to ensure is no possible overlap of the UV charts within.

    We will likely introduce a "pass-through" mode soon so that users can bypass this re-packing if there are special cases where this is needed. For most this is not desirable as it will result in additional lightmap textures being used in the project.

    Lightmap UVs that bypass our atlasing cannot be guaranteed to achieve the texel density specified in Lighting Settings. They will also not respect the object's scale or scale in lightmap... But maybe there are cases where this needed such as when the user is supplying lightmaps baked outside of Unity. Pretty niche, but we will cater to this.

    @fourche13 Are you able to supply us with a repro project to explore your issue? It's very difficult to diagnose from the images you have provided. If you are authoring your own lightmap UVs, these should be respected by Unity's packer. They may be scaled and offset into the overall atlas, but the charts should still resemble the original layout.

    When you say you are authoring in UV2, can I confirm this is the second UV channel? Some packages use a UV0,01,02 index, so UV2 could be the third channel.
     
    Last edited: Feb 27, 2019
    pitibonom likes this.
  25. JamesArndt

    JamesArndt

    Joined:
    Dec 1, 2009
    Posts:
    2,932
    I would disagree that this is VERY desirable. I also don't feel it's "niche" for folks to be able to use their own 3d application authored UVs properly in Unity (without Unity creating waste through UV shuffling). You said "For most this is not desirable as it will result in additional lightmap textures being used in the project." I'd like to add that for my projects when I allow Unity to manage my UV atlas layouts it usually creates far more lightmap textures than necessary. When I hand-author the lightmap UVs and use Bakery to force them onto the atlases I've determined I keep my lightmap textures down to about 3-4 (1024px) lightmap textures. With Unity's re-organizing my lightmap UVs I usually end up with about 20-30 lightmap textures. So from what I've seen on more than one project is the inverse of what you're saying. When an experienced artist exerts fine control over UV packing you can dramatically reduce the amount of textures used for lightmaps and have far more optimized packing.

    The Bakery Lightmapping plugin allows this with a simple dropdown and it works wonders. That plugin has literally saved one of my larger mobile projects for this reason alone. I think most would agree this is extremely beneficial for mobile games where 3D environments need to have very efficient baked lighting with very tight UVs. Experienced developers can achieve this by controlling the texel density, the scale of UVs and precisely how we want to "spend" our lightmapping real estate. The current automatic UVs and the re-shuffling of hand-authored UVs results in lots of wasted texture space. If this wasn't occuring I'm sure the built-in system would be fine. However as I said the built-in system is not smart enough or doesn't work well enough to pack UVs nearly as well as I do in 3ds Max or Maya.

    We've already discussed this issue with Unity staff in another lightmapping issues thread and he had discussed this pass-through mode. The main issue we were discussing is that we lose control over what UVs go onto what atlas if Unity feels they won't fit properly on an atlas, so it moves and shuffles UVs around to attempt to "fix" that for us. It will ignore the "baked tags" option if it feels the lightmap isn't giving equal resolution to objects. In that process you get lightmap atlases that sometimes have 80% empty and wasted texture space. On desktop, sure we can get away with textures being in the build that are mostly empty, but on mobile we can't afford this. In Bakery if you set a "tag" for geometry, it forces all of that geometry onto the lightmap atlas you need it to be on.

    On the second posting of this thread is where he responds to the changes that can help with this:

    https://forum.unity.com/threads/progressive-lightmapper.454362/page-15

    "The docs on "Baked Tag" ->
    Basically it says:
    Objects with different Baked Tag values are never put in the same atlas.

    and it goes on to say:
    there is no guarantee that objects with the same tag end up in the same atlas, because those objects might not necessarily fit into one lightmap

    However, we have a bunch of work being done in the packing area:
    1) Being able to set a count of lightmaps to use for a given bake tag (close to landing)
    2) Spatially coherent atlassing (also close but delayed because of 1)

    3) Pass through lightmap UVs - being able to do manual atlassing in DCC without Unity messing with the UVs"

    So in closing, it's this "Unity messing with UVs" that is a big issue for artist-created lightmap UVs. It makes things unnecessarily difficult and frustrating to do something so simple.
     
    Last edited: Feb 27, 2019
    pitibonom likes this.
  26. DavidLlewelyn

    DavidLlewelyn

    Unity Technologies

    Joined:
    Aug 14, 2012
    Posts:
    33
    @JamesArndt I think there is some confusion arising out of what "pass through UVs" mean in this context. I may have inferred a behaviour that is not what you were intending.

    My understanding of "pass through UVs" is where you would have a single object, with it's own second UV channel defining lightmap usage in 0-1 space. This would then not be repacked into a Scene atlas, but rather would be treated -effectively - as its own atlas. There is a demand for this behaviour in certain streaming contexts and for things like lightmap swapping. This is what I meant by "niche".

    It sounds like what you mean, is for objects to be packed externally in the DCC (taking advantage of some of the sophisticated algorithms available or indeed the human touch). Absolutely, this is a clear use-case. I can certainly agree that it is desirable to do a tight pack externally and then guarantee padding and a defined lightmap size. Useful for mobile, totally agree.

    So with that said, we need to consider how we design these pass-through lightmap UVs. Whether we take advantage of the Baked Tag available through lightmap parameters to determine which objects use which lightmap, or if we should introduce something else. Maybe this needs to be exposed through the MeshRenderer.

    Ideally where we're trying to get to, would be per-instance lightmap UVs which we could then repack outside of the constraints of the tile packing we currently have. If you could specify the desired lightmap resolution, number of maps and then force objects into these lightmaps with efficient wastage-free packing, then this would avoid the potential round-tripping introduced by packing externally. This will be our eventual aim.
     
    JamesArndt likes this.
  27. JamesArndt

    JamesArndt

    Joined:
    Dec 1, 2009
    Posts:
    2,932
    Yeah I think we might have gotten tripped up by whatever internal nomenclature you guys give for certain attributes. I wouldn't say the functionality I'm describing would be limited to single objects either. In fact you'd have several meshes on one lightmap (mesh combined or not depending on culling approach), and all of the UVs for those objects fitting into that single lightmap texture map. That's really the end goal, to control exactly how many textures are produced and control of the UV packing. When I hear the term "pass-through" in my mind it means "editor does no alterations or adjustments to UVs". I would again use the Bakery lightmapper of an example of this done well. It has a simple script that is dragged onto your mesh objects (or a parent group object with child meshrenderers) that would all share a lightmap texture. What's awesome about their Lightmap Group system is that once that script is applied I can individually set properties for lightmap resolution on those individual groups! So say my mesh objects out on the unreachable horizon would be set to bake a 512px lightmap...and the main corridor of my city can be baked out at a 1024px lightmap. I completely control things like resolution, padding, and more on these groups, so I can balance exactly where I want to "spend" my texture budget on lightmap textures.

    I think you're on a good path looking at it from the perspective of the meshRenderers or objects themselves.

    Bakery Lightmap Group Selector
    Specifies which Lightmap Group to use for the object and all of its children.
    Lightmap Group is a term Bakery uses for a collection of objects sharing 1 Lightmap. For example:
    • Marking certain objects to use per-vertex lightmap instead of textures.
    • Baking a lightmap using exact unscaled UVs as they were produced in a modeling package.
    • Grouping certain areas of the level to use single lightmap to facilitate resource streaming or to switch different baked lighting at runtime via scripts.
    We were discussing this in another thread about the lightmap packing and I think another developer was pointing out what the issue might be with Unity tweaking UVs during it's internal packing:



    And I cannot tell you how many times (almost every single time) I would bake out my environment's lightmaps with the Progressive Lightmapper and I would get multiple lightmap textures that looked like this: 90% of the texture as empty wasted texture space. Working on small mobile 3D environments (less than 16k triangles) and optimizing everything, including lightmap UVs and I would see this happen over and over. I had no way to control how this was being packed either. Unity would bake out 23 lightmap textures for a small level, with about half of them wasting up to 80 or 90% of the texture space (as seen below). Now that I'm using the Bakery lightmapper I have 100% control over how many lightmap textures I produce in Unity when I bake lightmaps for a level. Each environment produces around (6) lightmap textures, and each has 100% tight/optimized packing of UVs. It's the closest thing I've ever seen to the old Beast lightmapper in Unity 4.xxx. If anyone can recall the Beast lightmapper, it was great for baking lighting on mobile projects. It did no funny business with my lightmap UVs.

     
    Stardog and bluescrn like this.
  28. pitibonom

    pitibonom

    Joined:
    Aug 17, 2010
    Posts:
    220
    agree with @JamesArndt, and i also like @FrakkleRogg post :)

    This pass-thru mode is just mandatory for those creating their own UV, just like i do in blender.
    But it's not enough ^^
    Is also needed to be able to choose the target texture for lightmaps !!!

    here:
    Bake-AO-DIRT.jpg
    a 8Kx8K AO and dirtmap i got in my project. each part is unwrapped in blender and reworked/replaced by hand.

    In a brute pic here's what i map this texture on:
    whatisit.jpg

    ( cannot show all, as it's too large :p )

    Each tower, wall, city part's triangle has its own and unique place in the AO and dirtmap.

    Now what i dream of is....
    to setup lights in unity ( for night lighting ), say the lightbaker to use THIS SPECIFIC UV, and choose the target as a new 8Kx8K writable texture.
    Just click 'bake' and applause at unity dev team ;)

    (what i wanna do: the city lit at night, in unity but with realtime lights )
    niote-lights.jpg

    And finally use this texture in my very own way in a shader i choosed ( or modified :p ).

    This is just what is needed on MANY projects, and it's not just a niche XD lol
    just get an obj on turbosquid, pay for it, get it in unity and get pissed off as it's just unable to be integrated in unity because of 'forbidden UV choice' ^^

    I know unwrapping and islands packing is a nightmare for programmers ( i used to code on this ) and it's a big thread on most of the forums like blender's.
    I agree that unity is just perfect for dealing with lightmaps in a scene with a cube over a plane and 5 colored lights. The result is impressively sexy but real life cases are much more complicated, and when you wanna build a wide open world ( IMHO, and tho it's a beauty, the viking village is not a wide open world ) you gotta deal with almost every lil place in the SAME texture. Optimization has to be planned since the beginning and cannot be dealt with at the end, when you see hundreds of textures that should be only one and a useless additionnal UV channel that offers same coords ( but rescaled ) as the one from my AO/dirt UV layer.

    texel proper centering and aspect ratio and also islands margins are MY broblem. Because i do the unwrapping, and also because unity hardly deals with it ^^ ( i often see light leaks on various lightmapped models fully handled in unity.

    At last but not least, i have to say that i'd really like to be able to do this in unity ( and show my friends how this is easily and efficiently done in unity ) but for now i just think i'll have to bake those lights in blender. I see no other way of doing it :-/

    regards and happy unitying !
     
    Last edited: Feb 28, 2019
    JamesArndt and fguinier like this.
  29. DavidLlewelyn

    DavidLlewelyn

    Unity Technologies

    Joined:
    Aug 14, 2012
    Posts:
    33
    @pitibonom This is the behaviour you would get with the "pass through uvs" that I now understand @JamesArndt was talking about, and actually we are discussing internally. The proposed approach would be that you would unwrap the meshes you wished to have lightmapped in your DCC.

    This would need to be in such a way that all objects shared the same 0-1 UV space with no overlaps. In Unity you would be able to tag these objects to all share the same Baking Tag and mark them as `Override Lightmap Atlasing`. The UVs of those meshes with the override applied would not be modified, and they would all write to the same 0-1 lightmap space regardless of any unintended overlaps etc.

    Somehow - and we need to work out what makes most sense from a UX perspective - you need to be able to specify the resolution of this lightmap. As we're effectively overriding the texel density defined in the Lightmap Settings, do we just presume to make a lightmap at the maximum size defined by Lightmap Size? Are there cases where this might not be ideal? Might you want to use a larger lightmap for overridden meshes, and define a size for smaller lightmaps elsewhere?

    Yep, I understand what you're describing: multiple meshes all packed into the same 0-1 space. However, I'd still argue that the ability to force a number of lightmaps based on Baking Tag (available in 2019.2 today) combined with per-instance packing which avoided wastage, was the ideal we should be moving towards.

    The approach suggested by @JamesArndt above is an economy when it comes to guaranteeing lightmap usage, but it also means that you are unable to take advantage of instancing optimisations such as static batching in cases where your lightmapped MeshRenderers contained duplicated meshes. These could/should be prefabs in the Scene and our packing should still allow the level of control to ensure optimal packing using known numbers of maps.

    I'm championing improvements to UV packing internally and I really hope we can get something out into the world sooner rather than later. Better packing, more controls, no overlaps!!!
     
    JamesArndt and pitibonom like this.
  30. pitibonom

    pitibonom

    Joined:
    Aug 17, 2010
    Posts:
    220
    Indeed i'd have to choose my lightmap res, with the risk of choosing an unfitting one, wasting place or making artifacts or i don't know what ;)
    The thing is that when it wanna go wrong, it goes wrong :D
    And when this happens in unity we have no control on anything.
    At least, if you allow ppl doing their own setup, they can try and redo various ones and see what suits to them ^^
    and imagine ! you won't have any more boring questions like mines: 'gimme the wheel' :p
    for instancing benefits loss, yes, i totally agree with you. In my scenes, instancing is a nonsense as each mesh is different, and even there were 2 same gameobjects, they would surely be lit in different way. therefore i'd have to have one different lightmap ( or UV place in the same lightmap ) and treat those gameobjects as 2 different objects.
    However it does not prevent static mesh-merging.
    Of course this is not proper assumption for apps using multiple identical gameobjects.

    As usual, it's hard to discuss neutrally about all possible cases, and it's even harder to find a solution that deals with all of them. The easiest and complete one would be to let the user do everything ( what i'm asking for ). But it's my very own case and my choices ^^ Of course you'll always hear from people needing to have in unity the magic button called 'make an awesome game and send it on my google-dev account' x))
    so, what is the better way ?
    I'd say: both my captain ^^

    Anyway @FrakkleRogg thanks for your patience and kindness ! and good luck for working on those pesky UVs ^^

    hmm a later word: when you got something to test ( eg a package or a beta ) could you please post the info here ? I'm hardly watching at this thread ;)
    Thanks in advance :)
    regards and happy unitying !
     
    fguinier likes this.
  31. JamesArndt

    JamesArndt

    Joined:
    Dec 1, 2009
    Posts:
    2,932
    @FrakkleRogg I know you are all working hard as a team and will improve on the existing tools, no doubt. I appreciate you leading part of this discussion in the forum. Unity has become a behemoth these days, but it's great to see we can still have a back and forth with folks working on the engine.
     
    fguinier, KEngelstoft and grobonom like this.
  32. grobonom

    grobonom

    Joined:
    Jun 23, 2018
    Posts:
    335
    OOOOOOH YES !!!!!

    I won't stop kickin some asses but.... be sure that i LOVE unity !!!!
    IMO it's the ultimate tool for doing things. And even if nothing is perfect..... It's just great to talk, ask and exchange ideas, problems and anything.
    This is why i have to thank ( as i always us to ) unity dev team and unity3D !
    keep up your great work :)

    regards, thanks again and.... happy Unitying :)
     
  33. grobonom

    grobonom

    Joined:
    Jun 23, 2018
    Posts:
    335
    mebe i come too early.....

    is there any change on lightmapping in the latest betas ? concerning what we were speakin of in this topic ?
     
  34. KEngelstoft

    KEngelstoft

    Unity Technologies

    Joined:
    Aug 13, 2013
    Posts:
    1,366
    It depends on your definition of latest, as I don't know which version you are comparing against. You can always check out the release notes on the page where you download alpha releases https://unity3d.com/unity/alpha/2019.2.0a8
    2019.2 GI related changes (not an exhaustive list, there are a lot of smaller fixes too):
    - Support for multiple importance sampling the environment to the GPU lightmapper.
    - Support for the cross-platform Intel lightmap denoiser. Intel Open Image Denoise can produce smooth noise free lightmaps with few samples.
    - The Optix AI denoiser is now supported with GPU Lightmapper.
    - A 'None' mode for emissive GI contribution in the standard shader GUI.
    - Realtime GI now uses correct light falloff for indirect light when using configurable light falloff.
    - Upgraded Optix AI Denoiser to version 6. This new version has better performance and a lower memory footprint.
     
  35. JamesArndt

    JamesArndt

    Joined:
    Dec 1, 2009
    Posts:
    2,932
  36. rasmusn

    rasmusn

    Unity Technologies

    Joined:
    Nov 23, 2017
    Posts:
    99
    No, unfortunately not yet. I hate to sound like a broken record, but it got down de-prioritized against other high-priority fixes and improvements. We are currently looking into ways we can repurpose our resources in order to find manpower to address this. I know this is not the answer you had hoped for, but I can tell you we are trying our best with the resources and other obligations that we have.
     
    JamesArndt and grobonom like this.
  37. grobonom

    grobonom

    Joined:
    Jun 23, 2018
    Posts:
    335
    This is a frank and clear answer !
    I love this ! much more than silence !

    @rasmusn mebe i'm off topic but.... Did U3D devs ( carrying an each-day-heavier-burden ) thought about opening parts of code to open source devs ?

    I feel U3D lightmapping is today more a burden than a joker.
    I simply don't use it at all and do all by myself as it appears simpler to me.
    Open it, federate the dev and integrate it in U3D as a package !?

    Okay it deserves deep rework on RP and shaders.
    But this is the path you are good at: the angular stone.....

    Well it's just an idea..... No doubt other ppl might have better ones.

    Just for finishing i have to say i'm far from ready to usxe U3D realtime or baked GI as is.....
    Mebe am the only one ;)

    Happy unitying !
     
  38. JamesArndt

    JamesArndt

    Joined:
    Dec 1, 2009
    Posts:
    2,932
    Thank you for the honest and transparent answer. Since the lightmapping tools in Unity are still not quite there yet I really had wished there was more support for externally authored lightmaps. I know it's less important for high end PC and console development, but on mobile 3D games it's can be a life saver. Do you know of any recent hack week tools that semi-automate the lightmap offset, lightmap tiling...basically bringing and using externally produced lightmaps?
     
  39. rasmusn

    rasmusn

    Unity Technologies

    Joined:
    Nov 23, 2017
    Posts:
    99
    I don't know any semi-automatic tools like that, sorry.

    The only thing that comes to mind is that you should be able to completely bypass Unity's UV generation and light baking and instead provide your own custom solution. To supply everything yourself you would have to populate LightmapSettings.lightmaps and then use Renderer.lightmapIndex to point to the relevant lightmaps for each renderer. I don't know the details but I think this is what Bakery does.
     
    JamesArndt and grobonom like this.
  40. grobonom

    grobonom

    Joined:
    Jun 23, 2018
    Posts:
    335
    INDEED !!!
    I know no other way and that's what i use for implementing this:
    https://www.artstation.com/artwork/VdWQa5
    Second pic ( the inner room ) comes from U3D. it's realtime rendered as an FPS on the smallest samsung J5.

    You can clearly see AO/LIGHT/DIRT maps covering the stonewalls.
    All baking is done in blender and take some few time. But this is the price for performance and scalability.
    As an example, here's one of my lightmap ( 8K texture ) for 40 towers and almost as many walls:

    ( okay the file don't come as a thumbnail but you can see it clicking on the link.... )
    Note the poor image quality due to high compression ( for the file to be accepted by the forum.... ).

    This is a simple ambient/AO/dirt bake in blender.
    I get rid of U3D RT and BAKED lightmapping and then i can do what i want with any UV layers i want.
    I also ( for my app it's mandatory ) have one realtime sunlight casting shadows in my U3D app.

    There's no other way for realtime lights/shadows and night/day cycles.

    Hope this helps :)

    Happy unitying !
     

    Attached Files:

  41. Reahreic

    Reahreic

    Joined:
    Mar 23, 2011
    Posts:
    254
    @rasmusn , @KEngelstoft, @DavidLlewelyn

    We already create our lightmap UV's on a per model basis in an external application and export them in the UV2 channel, avoiding Unity's generate lightmap UV's functionality anytime we can. What I'd love to know is how can I manually pack my own baked lightmap atlases, as the progressive lightmap atlas packing is terribly inefficient.

    From what I can see the progressive algo itself actually packs UV's as if they were simple quads, which makes sense for predefined imported model lightmap UV's. The painful part is the arbitrary splitting of a single map into 2 or 16 individual atlases, despite there being ample dead space available in the atlases for consolidation.

    Unity Terrible Lightmap Atlassing.jpg

    The above Image shows unity's atlas packing of a simple single room, single light open scene on the left, and what I (the community too) want on the right.

    1. How do we force Unity progressive to give us atlases that match that on the right?
     
  42. rasmusn

    rasmusn

    Unity Technologies

    Joined:
    Nov 23, 2017
    Posts:
    99
    Our packer is indeed not great and we are working towards changing that. However, what you shows seems even worse. Are you sure these objects doesn't have different Lightmap Parameters? If they do, they might be split into separate groups which are then packed into separate lists of lightmaps. That could explain what you are seeing.

    If this is not the case, I'd be great if you could file a bug report containing a simple/reduced repro that exhibits the problem you are seeing. That would allow us to take a closer look. The easiest way to file a bug report is to use "Help -> Report Bug" from within Unity (here you can include the project in the report).
     
  43. Reahreic

    Reahreic

    Joined:
    Mar 23, 2011
    Posts:
    254
    Unfortunately, uploading debugging scenes is difficult for me as it requires basically building a fresh scene in a fresh project and stripping a whole lot of protected data and systems from the application when approved.

    I've noticed that each unique lightmap parameter forces a new UV atlas as you indicated. This was something I thought only occurred when the baked tag was manually set, not realizing that the values for default parameter assets are -1 and 0 for custom parameter assets.

    I've been able to mitigate some of the packing issues after another massive troubleshooting session; although it's a remarkably painful process.

    I post the following steps as guidance for any Googlers who end up here as I did:
    1. Scenes which are composited from multiple additively loaded scenes should be open in the editor with the baking scene selected and set as active.
    2. Pick the single item in the entire composite scene which you want to assign the greatest importance to and assign it a value of 1.
    3. Carefully assess the relative size of all other items in the scene that contribute to GI and and assign them a value as a percentage of the primary object.
      EG: In a scene comprising of only 3 Cubes with the largest cube having highest desired resolution. The largest (10M) cube is 1.0, a 5M cube would be 0.5, and a 1M cube 0.1.
    4. Save the scene & project!
    5. Open the lighting tab, set the direct, indirect, and Environment samples to the lowest they can go.
    6. Set the lightmap resolution to 1 and padding to a reasonable number. (I use 4 to 6)
    7. Hit Generate lighting.
    8. Inspect the generated atlases and Increase the lightmap resolution based on the rough amount of empty space you have and the number of lightmaps you desire.
    9. GoTo Step 7 until you are satisfied with the atlas.
    10. On the main editor menu, open Edit > Preferences
    11. Select GI Cache on the left, then select Clean Cache.
    12. Save the scene and project then restart Unity.
    13. Perform Step 1, then Step 14+
    14. Now, on the lighting tab set your Direct, Indirect, and Environment samples to something appropriate. (I start with 1k, 2k, and 0.5k doubling them each bake until I get the result I'm after)
    15. Save everything, document your settings, push the commit to your version control software.
    16. Walk away from the computer for at least 15 mins.

    Your Mileage Will Vary:
    Your lightmap resolution will depend on a multitude of things from scene size to GPU memory. Some scenes I can bake all to a single 4K map with resolution of 40, others I have to bake to multiple 2K maps with resolution of 16 or below. Multiple smaller maps will be less stressful on your GPU memory, but will incur additional draw calls. I have a 12GB GPU and it will routinely fail memory at only 7.6GB utilization on one scene before rolling back to CPU baking.

    I notice too that after around 20-30 bakes of the lightmaps with super low sampling to get the atlases right, that the GPU light mapper starts to completely fail. Failures range from baking only the bottom half of the lightmap, to just no longer updating the lightmaps or progressing at all. The solution to this appears to be 'cleaning the GI cache' which despite being set to a maximum of 15GB on my system, was sitting at almost 60GB compressed!
     
    Garrettec likes this.