What causes a lightmap bake that never finishes?

An enormous texel count, an unreachable convergence target, or a degenerate mesh forces the baker to iterate endlessly without ever reaching its sample target.

How do I catch this when it only happens for some players?

Capture it automatically from the player's device with the full stack trace, the device and OS, the build, and a breadcrumb trail of what they did. That turns a vague complaint into a specific, reproducible issue you can fix without owning the hardware it happens on.

How to Fix a Lightmap Bake That Never Completes or Hangs at a Percentage

Quick answer: Lower resolution and bounce counts, set a reasonable sample/convergence cap, remove broken meshes, and bake a small region first to confirm the pipeline works.

A bake that sits at the same percentage for hours is almost never about to finish. It is usually drowning in texels or chasing convergence on a tiny noisy area. Cutting the workload makes it converge.

How to fix it

1. Slash resolution and bounces first

Temporarily drop lightmap resolution and indirect bounce count to minimums and bake. If that finishes quickly, your production settings were simply too heavy for the texel count.

2. Cap samples and convergence

Set an explicit direct/indirect sample cap (Unity's sample sliders, Unreal Lightmass quality, Godot's bake quality) so the baker stops at a fixed budget instead of chasing a target it cannot reach.

3. Hunt for degenerate geometry

Zero-area triangles, NaN vertices, or meshes with no lightmap UVs can make a single chart never converge. Check the console for per-object bake warnings and fix or exclude that mesh.

4. Bake a subset to isolate it

Disable Contribute GI on most of the scene and bake a single room. If that succeeds, re-enable objects in batches to find the one mesh that stalls the whole bake.

Catching the ones you can't reproduce

The hardest version of this to fix is the one you can't reproduce — it only happens on a player's hardware, OS, driver, or save state, under conditions that simply aren't present on your machine. A report that says “it crashed” or “it froze” gives you nothing to act on, so the bug survives release after release while quietly costing you players.

Automatic error capture closes that gap. Each failure arrives with its full stack trace, the device and OS, the build number, and a breadcrumb trail of what the player did right before it broke, so even a failure you have never seen becomes a specific, reproducible issue. Fold identical failures into one signature ranked by how many players each hits, and your worklist sorts itself worst-first instead of arriving as a stream of vague complaints.

This is where a tool like Bugnet earns its place. Its SDK captures every error automatically with the full stack trace plus device, OS, memory, build, and game-state context, folds duplicates into one grouped issue with an occurrence count, and ties each to the build it first appeared on — so you fix the problem that hurts the most players first and confirm it is gone when its signature disappears from the next release.

Reproduce it once with full context and the fix writes itself. The hunt is the expensive part.