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

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.

 

Sounds like a bug to me.

 

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...

 

Enlighten is one of those tricky beasts. It has to be optimised, and optimisations lead to bugs.

 

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..

 

That did indeed solve the issue for clustering. However, the reflection probe issue persists. I've created a bug report, case 680250

 

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..

 

do you mean unity primitives ?..
i don't have them.... and continuing getting black areas.. on my terrain...
but thanks anyway !

 

@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.

 

@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?

 

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?

 

@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

 

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.

 

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.

 

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.

 

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.

 

Unity would love you to send that scene to them!

 

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!

 

Hello i ave found cool solution for unity 5 version,just UNINSTALL AND REINSTALL STABLE VERSION 4 or waste ur time and Subscription money ^^

 

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.

 

I get this "Bug" with the latest patch of unity 5... Waste of time

 

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.

 

This bug appeared when I added Unity's Terain Assets into my scene https://www.assetstore.unity3d.com/en/#!/content/6

 

The problem occurred when I used one of the included trees and set it as "static" in Inspector.

 

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.

 

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

 

It could be really helpful if unity would spit out some status info so that we could track down "expensive" objects easily.

 

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.

 

Is this a SINGLE mesh?

 

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.

 

Well, I've asked him if this is a single mesh for a reason, still waiting for reply.

 

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.

 

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.

 

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

 

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.

 

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.

 

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.

 

Yeah that's what I did in the end, using Unity 4 as an external tool in some sense.

 

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.

 

it's now october 2015...

 

Hello. Can you please give the steps in the link below a go.

https://support.unity3d.com/hc/en-u...tor-is-unresponsive-opening-lightmapped-scene

 

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.

 

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 !