Search Unity

  1. Good news ✨ We have more Unite Now videos available for you to watch on-demand! Come check them out and ask our experts any questions!
    Dismiss Notice

Possible FIX suggestion for GI getting stuck at 5/11 Clustering or 7/11 Lighting

Discussion in 'Global Illumination' started by Matthew Scott, Mar 11, 2015.

  1. Matthew Scott

    Matthew Scott

    Joined:
    Jan 16, 2013
    Posts:
    33
    Hey everyone,

    For those of you who have experienced the strange bug that causes your scene to turn black and the lighting calculations to become stuck at 5/11 clustering while spewing out errors in the console window....

    I battled with it for hours trying everything to get the calculation to stop or even start over.

    In the end, all it took was deleting TWO of my BASIC unity cube shapes that I had put in my scene. Literally a temp prop for a floor and a wall.

    SO, if your having this issue...try deleting your Unity cubes from your hierarchy. This instantly allowed my baking to continue at lightning speed! =D

    Hope this helps anyone with a similar issue! Was almost prepared to shift my entire project to a new project file.
     
    UltraProgrammer and LaserWzzrd like this.
  2. hippocoder

    hippocoder

    Digital Ape Moderator

    Joined:
    Apr 11, 2010
    Posts:
    26,726
    Sounds like a bug to me.
     
    Miscellaneous and JamesArndt like this.
  3. Matthew Scott

    Matthew Scott

    Joined:
    Jan 16, 2013
    Posts:
    33
    Indeed it is, I sent the bug report already with the project file. I've seen a few posts about this issue but nobody really had a fix, but this is what worked for me...until it gets confused again...
     
    UltraProgrammer and hippocoder like this.
  4. hippocoder

    hippocoder

    Digital Ape Moderator

    Joined:
    Apr 11, 2010
    Posts:
    26,726
    Enlighten is one of those tricky beasts. It has to be optimised, and optimisations lead to bugs.
     
  5. KEngelstoft

    KEngelstoft

    Unity Technologies

    Joined:
    Aug 13, 2013
    Posts:
    1,240
    Hi! What is the bug number?
     
    UltraProgrammer likes this.
  6. strawberrydoll

    strawberrydoll

    Joined:
    Jan 15, 2014
    Posts:
    30
    My scene doesn't get "stuck" per se, but takes hours on what I assume is a decent rig I have. 5/11 Clustering and 7/11 takes 3+ hours on a scene with not very much in it, about 40k poly total geometry. It seems to only happen with "larger" meshes. I've an airport scene where deactivating the runway and planes fixes this issue and the GI precalculation takes a few seconds.
    Along with this, I get another strange error. I can only ever have 1 reflection probe bake in the scene if the "problem" objects are active, adding another reflection probe simply refuses to bake..
     
    LaserWzzrd likes this.
  7. KEngelstoft

    KEngelstoft

    Unity Technologies

    Joined:
    Aug 13, 2013
    Posts:
    1,240
  8. strawberrydoll

    strawberrydoll

    Joined:
    Jan 15, 2014
    Posts:
    30
    That did indeed solve the issue for clustering. However, the reflection probe issue persists. I've created a bug report, case 680250
     
  9. erana79

    erana79

    Joined:
    Jun 26, 2013
    Posts:
    62
    I just opened another thread with the "Light Transport" problem - I lowered the resolution and only have one object in the scene. Still - doesn't get beyond Light Transport..
     
  10. U7Games

    U7Games

    Joined:
    May 21, 2011
    Posts:
    943
    do you mean unity primitives ?..
    i don't have them.... and continuing getting black areas.. on my terrain...
    but thanks anyway !
     
  11. bac9-flcl

    bac9-flcl

    Joined:
    Dec 5, 2012
    Posts:
    803
    @KEngelstoft

    Can you elaborate on correct usage of the lightmap resolution parameter? My scene consists of one 50k poly shape approximately 100x300x300 meters in volume, and I'm getting half an hour long bake times for 1024x1024px lighmap on i7-3770k and 24Gb RAM. I don't use any lights, I don't use any other objects, and I don't use any directional modes. Doesn't seem right to me, at least in comparison to wildly different bake times in Beast. I tried using the resolution parameter, but all it did for me was reducing the area occupied by the object in the scene lightmap. Instead of occupying 1/4th of it (which is already strange, I'm not using directional modes so remaining quarters are empty black) it becomes even smaller, a tiny speck in the sea of black. I would guess your suggestion can not be boiled down to making already enormous texels of already highly stretched small lightmaps on large objects even bigger, so I would guess this is unintended result and I'm doing something wrong.
     
  12. KEngelstoft

    KEngelstoft

    Unity Technologies

    Joined:
    Aug 13, 2013
    Posts:
    1,240
    @bac9-flcl Sounds like you baked lightmap resolution is set correct, but how about indirect resolution (or realtime GI)? Perhaps you should lower that instead?
     
  13. bac9-flcl

    bac9-flcl

    Joined:
    Dec 5, 2012
    Posts:
    803
    @KEngelstoft

    Okay, I tried a new scene with newly configured settings and baking times became reasonable, setting at around five minutes. I'm not able to get the desired quality, though: in particular, resolution in unexpectedly low, there are lots of very noticeable seams and bleeding, and ambient occlusion is almost non-existent.

    I would guess the reason for the first set of issues is this strange UV2 layout I got from generator on mesh import:



    I'm not sure this kind of stretching should occur (and splits seem a bit strange, occurring all over areas far below hard angle threshold). Enormous jumps in texel density are also a bit unexpected. Or maybe UV mode of the scene view is displaying UV2 incorrectly and everything is right in actual UV2, I'm not sure.

    Edit: Yeah, Baked mode of the scene view displays texel density properly, no density jumps and stretching there. I guess UV charts mode only shows UV1 or maybe it shows realtime GI UVs?

    Also, maybe my settings would be useful:



    Final result at x4096 baking resolution:




    The map itself:



    What I'm after is simply a non-directional sky lighting + AO bake. In other words, I'm after a bake you got from Beast when you set it to Single Lightmaps, Skylight intensity of 1 and AO intensity of 1. I don't need dynamic lighting, GI transmission to dynamic objects and such. I obviously can't reuse my old 4.6 lightmaps with custom lightmapping shaders since every auto-generated UV2 layout is very different in Unity 5.

    How can I get that result?
     
    Last edited: Mar 18, 2015
  14. KEngelstoft

    KEngelstoft

    Unity Technologies

    Joined:
    Aug 13, 2013
    Posts:
    1,240
    You have set Baked GI Resolution to 2 pixels per unit. If you want higher resolution, you can either increase it or increase the scale in lightmap per object (in the object tab of the lighting window).

    Why did you set baked padding to 16? The default value of 2 should be fine for most things.
     
  15. bac9-flcl

    bac9-flcl

    Joined:
    Dec 5, 2012
    Posts:
    803
    Oh. The layout is enormous and the lighting window reports that the atlas size is maxed out even at one unit per pixel, so I did not get the impression that a higher resolution per meter would have any effect. Interesting thing is, "Baked" scene view mode depicting texel density of baked lightmaps shows density that seems high enough for depicting AO for that object with sufficient detail. Take a look, that doesn't look like the resolution that can't accomodate shadows under, say, tanks to the right:



    Sorry if I'm mistaken.

    I was under impression padding radius is the radius of an outward projection from border pixels of UV islands that prevents bleeding of background colors as you go down through mip levels. It's probably not something like distance between UV islands, since lightmapper has no say in how UV2 is laid out. If it's the former, 2px is a bit too low and would cause bleeding of background black on the very next mip level - at least in my experience with padding for AO bakes in xNormal and other environments. Am I misunderstanding what this setting does?
     
    Last edited: Mar 18, 2015
  16. KEngelstoft

    KEngelstoft

    Unity Technologies

    Joined:
    Aug 13, 2013
    Posts:
    1,240
    It is hard to tell what the scale of your model is, but it looks large. To get higher quality AO, you can increase AO max distance to take object further away into account. Final Gather will also give you higher quality AO at the expense of longer bake times.

    Good point about the padding, keep it the way you set it...

    Your UV unwrap contains lots of tiny objects and looks auto generated, is it generated by Unity?
     
  17. bac9-flcl

    bac9-flcl

    Joined:
    Dec 5, 2012
    Posts:
    803
    @KEngelstoft

    Sorry for hijacking the thread with this :)

    Yeah, it's approximately 300x300x100m object, although it's not meant to be seen too up close, as it's a cutout taking half the iPad screen in an edutainment game, not something like an FPS environment. So, texel density I show on the screenshot above, where AO gradients only get 4-8 pixels to play out, is very much acceptable to me (if those gradients are rendered right).

    For reference, here is the kind of clean result I'm getting out of Beast in 4.x and want to replicate in 5.0:




    Those are single x2048 per entire object (excluding the turbine on the second one), and as you can see, AO/skylighting looks quite different. More examples in this album, including Beast lightmap screenshots of the model I used in the previous posts:
    https://imgur.com/a/qtQ3r#0

    Core differences, it seems, is how Beast AO/skylighting always has at least one pixel of 100% occlusion on the visible side of the contact area between various surfaces, while Englighten AO/skylighting never goes to 100% occlusion in contact shadows, mostly keeping dark shades hidden deep in invisible portions of occluded surfaces. Or maybe it decays using more aggressive curve and therefore never gets a chance to go to significant degree of occlusion even at a pixel closest to a surface intersection. At least, to my eyes those are the best guesses.

    _______________________________

    Four meters is the height of those tanks and the height of those corridors on the left of the cross section, so I figured it's a good point for AO distance - setting it to infinite or, say, 24 meters would've made the interior to the right very dark with roof to floor occlusion. But sure, I'll try changing the distance next time.

    As about unwraps, I have tried several approaches:
    • Using automatic UV2 unwrap performed by Unity mesh importer with default settings
    • Using automatic UV2 unwrap performed by Unity mesh importer with low hard angle settings, e.g. set to 30 degrees (since default of 88 degrees seems to be a poor fit for hardsurface objects with tons of hard angles and might have produced inconveniently shaped islands in the layout, stitching together surfaces that would've been neat, easily packable rectangular islands otherwise - at least, that's what usually happens with high hard angle threshold in other auto-UV environments)
    • Flatten mapping in 3ds Max using Unwrap UVW modifier and 45 degrees angle / 0.005 padding (the latter setting is a bit weird and not set in pixels for some reason, so nevermind the low value, it gives an acceptable padding)..
    Unfortunately, I don't have the luxury of time to do UV2 manually - even with incredible tools like UVLayout an object like this can take hours. While automatic unwraps performed by Unity can't hold the candle to manual work, they are far, far superior to results of 3ds Max auto-unwrapping which seems fundamentally incapable of nicely splitting cylindrical surfaces and large sets of coplanar faces. Unwraps from 3ds Max had far more islands and therefore far more space eaten by the padding portion.

    Anyway, all three had exactly the same AO issues, with occlusion seemingly washed out and undersampled. Final gather did not help the quality, only introducing very noticeable noise but no improvement on contact shadow precision and AO brightness, with the last layout faring a bit worse due to it's lower effective texel density.

    Unfortunately I had to go with the last layout for the moment. Had to submit a build this night, so I used the following emergency workflow, so to speak:
    • Create UV2 using 3ds Max Flatten Mapping, disable UV2 generation in Unity 4.x project and Unity 5.0 project - you can't use Unity layout since generation results are different between Unity 4.x and 5.0 (you can't smuggle the coords between the projects, since different generated layout means different effective vertex count and different array order/length, so your mesh.uv2 from 4.x would not be compatible with the mesh from 5.0)
    • Bake Single Lightmap / AO 1.0 / Skylight 1.0 / Ambient 0.0 lightmap using Beast
    • As Unity 5.0, to my surprise, seemed to ditch RGBM encoding of .exr files into DXT, you can't use the resulting 32-bit lightmap with a custom lightmapping shader in Unity 5.0 (old approach of using DecodeLightmap inline won't work anymore).
    • I manually convert 32-bit .exr to 8-bit .png using Gamma and Exposure 32-to-8 conversion mode in Photoshop. I have no idea whether it's the right way to convert it and I was unable to match the results of DecodeLightmap from 4.x CG include, but using exposure of 1.0 and Gamma of 1.9 seemed to be the closest match. No combination of exposure and gamma ever gives you exactly matching gradients on both black and white extremes of a lightmap, so it's probably incorrect conversion approach, but every other Photoshop conversion mode is even worse for this particular goal, acting locally and subjectively and being tailored to (I would guess) HDR photography.
    • I then plug resulting 8-bit map into a custom shader using UV2 for PBR occlusion or unlit main map, depending on the goals of the scene
    Maybe that list will be helpful to someone else in the rush to get their custom lightmapping to work in some temporary form :)
     
    Last edited: Mar 19, 2015
  18. KEngelstoft

    KEngelstoft

    Unity Technologies

    Joined:
    Aug 13, 2013
    Posts:
    1,240
    One of the things that could cause the difference is that Beast applies AO on both direct and indirect lighting. Enlighten does the correct thing and only applies shadowing on the indirect lighting. We will make this configurable at some point so you can have it both ways.
    The patch release allows you to increase the AO exponent beyond 1.0 so that can help you get some more contrast.
     
    shkar-noori likes this.
  19. bac9-flcl

    bac9-flcl

    Joined:
    Dec 5, 2012
    Posts:
    803
    Ah, yeah, that might be it. Great to hear such an option is coming!

    By the way, there is another extremely valuable application for baking out clean AO with no direct light interference, aside from stylized games. It's insanely useful for baking lightmapping-independent maps! I always liked to steal per-object white/100% ambient/AO lightmaps from Beast for using them as occlusion maps in prefab pieces of procedural levels and for other such applications. Being able to bake a certain map in complete isolation is always useful, you can exploit the resulting texture to drive DDO-style masks, stylized shading, stuff in lightmapping-independent dynamic objects and so on.

    So yeah, every step towards enabling options like those is very much welcome. Another example is sharpness - if I understand how it works in some other environments like Mudbox correctly, you can invert some parts of AO calculation to get a convexity/sharpness map that is extremely valuable for driving stuff like UV2 edge wear on buildings. For example, I exploited Beast to generate maps for procedural levels made of pieces like these:



    Alternatively, a way to export auto-generated UV2 layout into a file or a way to permanently apply it to your mesh would be very useful, allowing you to take Unity UVs outside of the engine and allowing you to use specialized tools like Knald and xNormal for specialized map baking, without bloating the lightmapper itself with related features.

    At the moment there are some third-party map baking solutions working on C# within the editor (in particular, Worn Edges toolset from the Asset Store), but they are, obviously, lightyears away performance-wise from GPU-accelerated external tools you can use to get very same maps - if only you had external access to UV2.
     
    Last edited: Mar 19, 2015
  20. KEngelstoft

    KEngelstoft

    Unity Technologies

    Joined:
    Aug 13, 2013
    Posts:
    1,240
    There should be nothing stopping you from writing a script that reads the different UV channels and does whatever you please with them.
     
  21. bac9-flcl

    bac9-flcl

    Joined:
    Dec 5, 2012
    Posts:
    803
    Ha, I overlooked the existence of community-authored .obj exporters, just found those on the wiki. To think of it, Mesh is exposing enough info to write one, after all. That makes things easier. :)
     
  22. randytayler

    randytayler

    Joined:
    Mar 24, 2015
    Posts:
    7
    I didn't have any primitives that could be the guilty party, so I tried this:

    1. In Window->Lighting->Lightmaps, turn off Continuous Baking.
    2. In your scene, disable (uncheck) every last object. You miiiiiiight be able to create a giant empty and push everything into it, then just disable IT, but whatever. I was lucky and only had 7 or so gameobjects when I did this. (I was originally trying them one at a time, to see if a particular object was the culprit. Sure enough, one object no different than the others was the one where Unity would stall out during the light baking procedure.)
    3. Hit BUILD on the lightmaps tab. You're building the lightmap, not the game. It should pretty fast if everything's been disabled.
    4. Now you have a lightmap snapshot. Yay.
    5. Re-enable all the objects in your scene.
    6. Hit BUILD again, re-baking the lightmaps.
    7. You should NOW be able to build your game. Not sure if I can go back to continuous baking or not -- I'm trying that now, but wanted to share what I found working for me.
     
  23. mos99z

    mos99z

    Joined:
    Apr 20, 2015
    Posts:
    2
    My Fix - I had some walls set to static, I unchecked static and it started working... just throwing out there what fixed my issue, hope it helps.
     
    Savikain likes this.
  24. hippocoder

    hippocoder

    Digital Ape Moderator

    Joined:
    Apr 11, 2010
    Posts:
    26,726
    Unity would love you to send that scene to them!
     
    errandfox likes this.
  25. Tsilliev

    Tsilliev

    Joined:
    Jan 21, 2014
    Posts:
    34
    mos99z THANKS. What I was doing is just on a fresh project without any objects or anything I had only terrain, I import heightmap.raw and it was stuck at 5/11 clustering. unchecking static from the terrain fixed that!
     
  26. sonnolo

    sonnolo

    Joined:
    Feb 22, 2015
    Posts:
    26
    Hello i ave found cool solution for unity 5 version,just UNINSTALL AND REINSTALL STABLE VERSION 4 or waste ur time and Subscription money ^^
     
    IgorAherne and LaserWzzrd like this.
  27. Max_Bol

    Max_Bol

    Joined:
    May 12, 2014
    Posts:
    124
    If I had to say something about the Lightmap Parameters, it would be that it's well documented for its features uses... but poorly documented on understanding their actual values. The Unity Documentation currently lack what was available prior to Unity 5.x and that is "results comparisons" (similar to what's in the image effect section). So many options with "tiny effects" but since those tiny effects, in masses, can make things look ugly or great and the actual built time for, in this example, lightmaps is freaking huge whenever you don't have a high-end pc at hand. This make the idea of changing even 1 of the lightning options scary and painful (a real minefield).

    A common thing to do when explaining features that affect visuals is to put comparative pictures, even if they are simple with cubes and planes. Otherwise, everyone is on a free trip for days just wandering the options, waiting totals of hours if not days just to understand what a simple value actually do visually in their scene and what risks are involved in changing them.
    This is, in my idea, the bare minimum required in the documentation :
    - Names of each options/function : Already done;
    - Description (technical) : Already done;
    - Some picture showing actual results from a change of the option. (Either set to off/low versus on/high) : Not available yet.
    - Actual realistic values suggestions : Not available yet.

    The pictures could not only help understanding each options, but also helping the developers at understanding if they actually need the options. Sure, it would not be a 100%-get-the-right-value solution, but instead of trying more or less 30% of the options to get the right result at the right quality (not too high, not too low), it could be as low as 5%-10% of the option that actually need some twinkling.
    There's an example, the Default Parameters the General GI offer 4 options : Default, DefaultHighResolution, DefaultLowResolution and DefaultVeryLowResolution and the ones we can create. The thing is... we don't even know what those Default settings are at and then we are forced to create our own which is okay... but still makes us wonder "why not using one of those 4 during the building or maybe they are alright for the final... or maybe they don't fit for my scene". It's like if you're given the choice between 4 ice cream flavors with wicked names without knowing what they're made with or a "create your own" 5th choice. It's getting easily mixing things up.

    Just my 2 cents.
     
    AaronBrownLM and tryptic like this.
  28. MyGenericUsername

    MyGenericUsername

    Joined:
    Sep 6, 2014
    Posts:
    95
    I get this "Bug" with the latest patch of unity 5... Waste of time
     
    LaserWzzrd likes this.
  29. Random10000000000000000000000

    Random10000000000000000000000

    Joined:
    Apr 14, 2015
    Posts:
    1
    I just got this bug too, however it seems that it was because of a model in blender that I did a limited dissolve on to get rid of extra vertices I didn't want. It speed up when I deleted this model from my scene. I will post again if this is not the problem as I have a copy of the model before I got rid of all the extra vertices.
     
  30. Narmer

    Narmer

    Joined:
    Mar 5, 2014
    Posts:
    18
    daros99 likes this.
  31. Narmer

    Narmer

    Joined:
    Mar 5, 2014
    Posts:
    18
    The problem occurred when I used one of the included trees and set it as "static" in Inspector.
     
    daros99 likes this.
  32. codejoy

    codejoy

    Joined:
    Aug 17, 2012
    Posts:
    204
    I am not sure if this is lighting related or what... I am trying to just do the roll ball tutorial and build it out for android and it takes FOREVER. goes fast if building to pc....but not android gets stuck at 5/11 anything I can disable to speed this up? (fancy lighting?) still hasn't completed its a simple scene with terrain (And its standard assets) and a smiley face ball.
     
  33. MadeFromPolygons

    MadeFromPolygons

    Joined:
    Oct 5, 2013
    Posts:
    2,606
    Ive found that using a lower resolution lightmap on any large flat road-like surfaces (like roads, runways, highways, playgrounds, flat ground etc) really speeds up the process. I had a massive green plane of grass surrounding my city, and everything else would go fast but 1 job at 5/11 and 7/11 would take forever, lowering the resolution for said plane made that job go as fast as the others. Hope that helps
     
    codejoy likes this.
  34. ImpossibleRobert

    ImpossibleRobert

    Joined:
    Oct 10, 2013
    Posts:
    331
    It could be really helpful if unity would spit out some status info so that we could track down "expensive" objects easily.
     
  35. ZiadJ

    ZiadJ

    Joined:
    Sep 3, 2011
    Posts:
    60
    In a scene containing just a static cube baking is almost instantaneous. After I scaled it to 50 while keeping its original height of 1 the baking takes ~15mins! I then stretched the scale to 100 while keeping the original height to 1 again and the baking stuck at 5/11 after 30mins. I aborted and reduced the realtime resolution to 1 texel per unit(originally 2) and the baking took ~15mins again.

    It seems the problem is either related to mesh scaling rather than complexity. Can anyone else reproduce this? Haven't tried it yet but I'm pretty sure I'd get the same results using other meshes.
     
  36. Teo

    Teo

    Joined:
    Oct 31, 2009
    Posts:
    564
    Is this a SINGLE mesh?
     
  37. S_P_S

    S_P_S

    Joined:
    Feb 25, 2015
    Posts:
    91
    Same problem here, when baking it says "5/11 Clustering | 1 jobs" and didn't go further, or takes very long.
    I have no terrain in my scene, "only" many high poly models.
     
  38. Teo

    Teo

    Joined:
    Oct 31, 2009
    Posts:
    564
    Well, I've asked him if this is a single mesh for a reason, still waiting for reply.
     
  39. bac9-flcl

    bac9-flcl

    Joined:
    Dec 5, 2012
    Posts:
    803
    Yes, it's a single mesh. I need just one lightmap per object and one object per scene, objects are relatively low poly and all surfaces share one material, so it never made any sense to split them into multiple meshes.
     
  40. Teo

    Teo

    Joined:
    Oct 31, 2009
    Posts:
    564
    Why? Any solid reason?

    To have a quality lightmap for such big and complex mesh you need a huge lightmap. Not counting what problems you will have texturing that.

    Just split and reuse as much as you can from mesh.
     
  41. bac9-flcl

    bac9-flcl

    Joined:
    Dec 5, 2012
    Posts:
    803
    As I've pointed out in that earlier post, the lightmap stretched over the whole object has more than enough resolution for my purposes. It's not an FPS environment, I don't need exceptional detail, I just need those low-resolution gradients to be properly aligned to geometry. As you can see on all old screenshots, Beast had no issue placing 16px/m gradients where they belonged, while Enlighten leaves huge seams. Splitting the objects and increasing the number of lightmaps won't fundamentally solve the issue, it will just hide the imprecision better.

    Splitting the object into multiple pieces makes no sense for few other reasons too:

    • I have to instantiate those objects across many scenes, and managing one mesh with one material with one lightmap is far more convenient than wrangling a mess with dozens of materials and lightmaps. File management becomes easier too.
    • Some scenes have high draw call counts or use expensive shaders, so I really, really prefer to keep objects split as little as possible for performance reasons
     
    Last edited: Aug 19, 2015
  42. Teo

    Teo

    Joined:
    Oct 31, 2009
    Posts:
    564
    I am not sure if it's best what you do. If you split and instance, you can get many benefits, like occlusion culling, easy texturing, maybe some physics advantages.
     
  43. bac9-flcl

    bac9-flcl

    Joined:
    Dec 5, 2012
    Posts:
    803
    In my use case I had no need for occlusion culling since scenes typically showcased a particular object in full view with the camera orbiting around the center of the scene or showing a carefully modeled view point where no unused geometry exists at all, by design of a model. Physics weren't ever used either.

    I'm not against reusable modular geometry, splitting of stuff and so on in general, I do traditional scenes too. But this particular case required one lightmap per mesh and no splits. That happens. If that makes it easier, imagine a scene with a slightly more traditional object. Say, an apple, or a barrel, or a pedestal, or a car. Nothing else, they are just suspended in the middle of the space with a camera orbiting around. It's kind of natural to want those physically smaller objects to use just one lightmap for everything, right? My buildings play the same role in that application.

    The particular case I have described in that old post is long solved, though. I used Unity 4, baked per-object lightmaps there, exported .obj models with UV2 coords from Unity 4 Mesh assets used to bake those lightmaps, imported resulting .obj models to Unity 5, wrote a lightmapped shader for U5 and plugged per-object lightmaps there. Pretty inconvenient, but I was able to ship on time.
     
  44. Teo

    Teo

    Joined:
    Oct 31, 2009
    Posts:
    564
    Okay, now now I can understand why you really want to use 1 mesh for whole model.

    If Enlighten do not produce expected lightmaps/AO you can bake them in other tool in your case. Blender produce real good AO maps and lighting.
     
  45. bac9-flcl

    bac9-flcl

    Joined:
    Dec 5, 2012
    Posts:
    803
    Yeah that's what I did in the end, using Unity 4 as an external tool in some sense.
     
  46. float

    float

    Joined:
    Jul 29, 2012
    Posts:
    42
    The Problem is still around in 5.2.0f3.

    Is it possible, that it starts when the UV's are larger than the 0-1 Space? Because at the begining of my Project i had a simple atlas-map with everything on it. UVSpace inside of 0-1. Worked fine.
    But after working on the UV's and textures i have UVs that are 100 times bigger than 0-1. At that Point it got stuck @ 5/11 all the time.

    For me it helped to scale the parent GO to 0.1, hit bake and scale the parent back to 1 again.
     
  47. amiel_ace

    amiel_ace

    Joined:
    Oct 25, 2014
    Posts:
    5
    it's now october 2015...
     
  48. Oscar-P

    Oscar-P

    Unity Technologies

    Joined:
    Sep 2, 2013
    Posts:
    9
  49. Watch Maker

    Watch Maker

    Joined:
    Apr 8, 2015
    Posts:
    2
    Did anyone try turning off the Precomputed Realtime GI? This issue was solved in our project by turning it off. We don't have any dynamic directional lights in our scene, so nothing was influenced. This option is on by default but I don't think most projects need it.
     
  50. MattGen

    MattGen

    Joined:
    May 12, 2015
    Posts:
    59
    Why is this "Continuous Baking" checked on initialisation of new projects ?
    Managing lightning and baking lightmaps is totally not one of the first steps of creating a game !
    Can't you see all those guys thinking that "unchecking "static" on my object solved the problem" ?
    The problem was that they were far from thinking at managing their lightning, but Unity has set continuous baking as a default parameter on new projects ! I can't get the logic there !
     
unityunity