Baking Static Lightmaps in Games
Lightmaps are a way to buy quality lighting at the cost of CPU/GPU time during development, not during gameplay. For mobile platforms and projects with limited performance budget, this is not just a convenient option—it's the only realistic path to beautiful lighting without FPS drops.
But the baking pipeline breaks easily. And most often—not because of lighting settings, but because of geometry.
An important point often missed: lightmaps are static by definition. Any object not marked Static doesn't participate in baking as a source or receiver of baked light. This means dynamic characters, doors, elevators, and everything else that moves must work with Light Probes to receive indirect lighting. Correct interaction between static lightmaps and dynamic Light Probes is a separate part of the lighting architecture that's established before work begins, not solved retroactively.
UV1 Unwrap: 80% of All Problems Live Here
Progressive Lightmapper bakes lighting to a separate UV channel—UV Channel 1 (Lightmap UV). If this channel isn't set up correctly, no baking parameters will help.
Three hard requirements for Lightmap UV: islands must not overlap, islands must have padding from the atlas edge (minimum 2 pixels at standard resolution), surfaces of identical size in world space must have proportional island size. The last requirement is most often violated during asset import—the artist creates unwrap for diffuse texture, and Lightmap UV is left as-is.
Unity can enable automatic Lightmap UV generation during import (Model → Generate Lightmap UVs), but this isn't a panacea. Auto-generation works poorly with architectural objects with sharp angles—the algorithm splits the surface into too-small islands, and dark lines appear at seams during baking due to padding artifacts. For such objects, it's better to make UV1 manually in Blender or Maya with explicit control over seams and padding.
Check unwrap before baking—via Lightmap UV Preview in Scene View (UV Charts button in Baked Lightmap mode).
Configuring Progressive Lightmapper
Progressive Lightmapper—CPU or GPU, depending on hardware. GPU version on modern cards works 5–15 times faster, but requires NVIDIA with CUDA support or AMD with Metal/OpenCL. On machines without discrete GPU or when working with very large scenes (over 4K objects), CPU version is more stable.
Key parameters that really affect the result:
Lightmap Resolution—texels per unit of world space. Standard 10–20 for near surfaces, 2–5 for distant. Single value for entire scene is a mistake. Correct path: Lightmap Parameters Assets of different quality classes, assigned via Mesh Renderer → Lightmap Parameters.
Direct Samples / Indirect Samples—number of rays for direct and indirect lighting. For production build, Direct 64, Indirect 512 is reasonable baseline. For noise in dark areas, increase Indirect to 1024. Increasing above 2048 rarely gives visible results with typical diffuse materials.
Max Bounces—number of indirect light reflections. 2 bounces sufficient for most scenes. 4+ for glass or mirror interiors where light reflects multiple times.
Denoising—definitely enable for final baking. Optix (NVIDIA) gives best result but unavailable without compatible card. OpenImageDenoise (Intel) works on any CPU.
Case Study: Lightmaps for Mobile Strategy
Project—mobile strategy with isometric view, 20+ level scenes. Requirement: lightmaps must not exceed 4 MB per scene (memory budget limit). With standard settings each scene generated 3–5 textures 1024×1024, yielding 6–8 MB even in ETC2.
Solution via Lightmap Packing: switched to single 2048×2048 atlas instead of multiple 1024×1024 (tighter packing via better bin-packing algorithm). For all distant background objects and rooftop surfaces invisible to camera, disabled Contribute GI completely. Result—1 texture 2048×2048 per scene, 2 MB in ETC2 while maintaining visual quality on near plane.
Lightmap Compression and Formats
After baking, Unity saves lightmaps in Lightmap-dir as float32 EXR. During build they convert according to platform settings. For Android, I recommend explicitly setting Lightmap Encoding in Project Settings → Player → Lightmap Encoding: Normal Quality uses RGBM coding (8 bit), High Quality—BC6H on desktop or RGBA Half Float on mobile, giving better HDR data preservation.
On iOS with Metal, ASTC 6×6 is preferable—it gives better quality/size ratio than ETC2. Configured via Texture Importer for lightmap folder (Select All → Override for iOS).
Staged Baking Work
Start with UV unwrap audit and fixing problem objects. In parallel—set up Lightmap Parameters Assets for different object classes. Then test bake with low quality (Direct 8, Indirect 32) to check lighting structure—at this stage UV problems and source placement issues are visible. After agreement—final bake with production parameters, denoising, atlas size verification. Final—test in build on target platform.
| Scale | Timeline |
|---|---|
| 1–3 small scenes (up to 100 objects each) | 2–4 days |
| 10–20 medium scenes | 1–3 weeks |
| Large level with open space | 1–2 weeks |
| Full pipeline with UV fixes and optimization | 3–6 weeks |
Cost determined individually after UV unwrap audit and analysis of current project state.