What causes emissive materials not contributing to baked GI?

An emissive material lights itself but only injects indirect bounce light when its emissive GI contribution is enabled and both the material and renderer are marked for baking.

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 Emissive Materials Not Contributing to Baked GI

Quick answer: Set the material's emissive Global Illumination to Baked or Realtime, mark the renderer as Contribute GI, and rebake so the emissive surface feeds the lightmap.

Emissive that glows on screen but lights nothing means the bounce path is off. The material needs its emissive GI flag set and the object must be a static GI contributor before a rebake.

How to fix it

1. Enable emissive GI on the material

In the material, set the emissive Global Illumination dropdown to Baked (or Realtime) rather than None, so the lighting system samples the emissive color for bounce.

2. Mark the object as a GI contributor

The emissive renderer must be flagged Contribute GI / lightmap-static, or the baker ignores it as a light source entirely.

3. Use a high enough emission color

Emissive bounce is subtle; raise the emission HDR intensity so the contributed indirect light is actually visible, then rebake the lightmap.

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

Ship the fix, watch the signature disappear from the next build. That's how you know it's really gone.