Baked lightmap is almost completely dark

Godot Version

4.5.1.stable

Question

I have a basic scene I created in Blender. It has a room with a single emissive cube for lighting. The problem is that, when I add a LightmapGI node and bake the lightmap, only the ceiling lights up, and it looks horrible, with tons of splotchiness/acne. I would expect the lighting to be smooth, and shine on the walls and floor as well. Below is a screenshot demonstrating the problem.

I’ve tried adjusting all the various quality settings for the LightmapGI, but it only changes either the intensity or size of these little splotches. Increasing the emission intensity only increase the brightness of the ceiling; the walls and floor are always black.

How should I fix this?

I’m running Ubuntu 25.04, 12th Gen Intel Core i7-1255U × 12 with Intel Graphics (ADL GT2).

Is this a system-specific issue or a bug in Godot?

Lighting in Blender does not translate to Godot. You’ll have to add a light inside Godot and set it to the values you want.

Maybe try playing with light value seems over bright engine could have issues with rays if too much weight is placed. would be nice if docu went into how its calculating that stuff far easier to bug report if I knew it was multiple impotence map issues etc, but IDK how it’s baking or if it even has multiple impotence maps. Maybe I’m wrong I just couldn’t find a page on it if there is. Maybe try in next Godot stable version and previous. Also I’ve found to fill in gaps in a lot of docu downloading some example files/demos is well a look.

Per @dragonforge-dev’s suggestion I tried adding an OmniLight, but the light doesn’t bounce around at all, it only hits the places where the light is directly shining. I’ve confirmed it’s in Static GI mode.

After playing with the lighting as suggested by @BlankStudios, I’ve found that reducing the cube’s emission strength does improve the quality of the lightmap, but it’s still extremely dim, and only shines light on the ceiling.

I also tried this setup in versions 4.4 stable and 4.6 stable, with the same results.

1 Like

Omni.Range, Omni.Attenuation and Light.Energy are all in play

Here is a dim room, baked GI - OmniLight set as such

Now if you crank the Energy, without changing anything else (Light.Energy=50)
The light will be brighter, but it won’t light very much because the Range caps it:

If you increase the Range it allows the light to hit the walls that are further away (Omni.Range=100, Light.Energy=50) :


The Attenuation can also be changed, in order to set how “fast” brightness falls as you get away from the light (Omni.Range=100, Light.Energy=20 for the next examples)

Omni.Attenuation=0 - The light will perfectly cover all the range, then smoothly fade to black when reaching the range:


As you can see, this results in the “halo” around the light not being separate from the whole lit area.

Omni.Attenuation=1 - It’s the default, it’s trying to fade out the light by the time it reaches the range, resulting in a very progressive dimming:


This looks a lot less “nuked” / “deep fried” but it’s still quite bright

Omni.Attenuation=2 - “Realistic” attenuation, it’s quite a bit darker, and creates a nice “halo” around the light, while still allowing the light to shine distant objects:

If you set the Omni.Range too low, it does not matter which Omni.Attenuation or Light.Energy you use, you will always get a “halo” and then darkness. You should understand Omni.Range to represent the very maximum distance the light should reach, if you want a very dark room with moody lighting, this should be a pretty high number.

Hope this helps!

1 Like

Thanks, those explanations are really good! I realized I forgot to set my Omnilight’s bake mode to Static. When in Dynamic mode and configured with correct range, attenuation, and energy, the Omnilight looks just like in your screenshots. However, when I switch it to Static so that it’s only included in the lightmaps, it emits no light at all, and looks completely dark (I made sure to bake the lightmaps). I would expect it to shine light on the walls, and contribute to the overall illumination of the room.

This is why I think the problem is with the lightmap itself, and not with the lights.

After doing some more digging, I’ve concluded that this is a bug in Godot. Switching to Compatibility changes the way the lightmap looks, as shown in the screenshot below.

There are issues on Godot’s GitHub repository that are very similar to mine, most notably Vulkan: LightmapGI generates completely black output and probes on macOS (Intel driver bug) #80154.

A comprehensive list of all LightmapGI issues and pull requests can be found at [TRACKER] LightmapGI (GPU lightmapper) issues #56033. I might open an issue myself. I’ll link to it here if I do, in case anyone wants to keep an eye on this.

This is quite odd, I am not sure what is causing this.

Maybe check your models ? The model normals are important, and you need the walls to have a little thickness for baking to work properly.

I have recreated a scene similar to the one you made in 4.6 stable, and got it to work:


You can download it here on my GitHub and try it out - if it does not work, it might be an issue with Intel Integrated ? I am also on Ubuntu so it’s not a Linux issue (and from experience, Godot runs often better on Linux than on Windows)

1 Like

Well, now I’m more confused. I cloned your repository, baked the lightmaps, and it worked! I’m even able to change the color of the light:

I also know that the light is in the lightmap, because when I move the light around after baking, the brightness stays in the same spot on the walls. I also noticed that the little gizmos for your lightmap are 3d balls; mine are normally completely black. Do you think there is some setting I need to change in order for this to work in my projects?

After playing around with this a bit more, I’ve figured out a couple things.

  1. My emission cube works in @vonpanda’s scene, but it’s way way way too bright. I turned down the emission strength to about 10, and it looked good.
  2. My large cube used as a room doesn’t work in @vonpanda’s scene. It bakes the lightmap completely dark, just like it does with me.
  3. @vonpanda’s large cube takes much longer to bake the lightmaps than mine does.

With all this in mind, I think the issue is something to do with my Blender meshes. I’ll try experimenting more to see if I can narrow down the problem even further.

My large cube used as a room doesn’t work in @vonpanda’s scene. It bakes the lightmap completely dark, just like it does with me.

I think it’s your model and your normals, then.

In the repo I made the walls have a thickness and checked the normals are pointing inside - but if you just take a cube and put things inside of it, you will have issues:

In Blender, you can see the normals of your model in the “Mesh Edit Mode Overlays”, in the top right of your 3D canvas (only shown while in edit mode)

And you can see the normals, represented by a blue line.
If you just use the default cube, the normals are pointing towards the “outside”.

In comparison, here is the hollow cube I made

If I replace the hollow cube with a default cube, I get this:

If I invert the normals of the default cube, I get the scene to work, but there are artifacts of light bleed through the corners

If I now remove one face of the cube with inverted normals …


It renders properly at first, until I generate the UV2 for it:

Then, after baking the lightmap:

It’s all messed up…


There might, indeed, be a bug in there: I don’t think this is expected behavior.
Tho I am curious, could you show your model’s normals in Blender?

If the example I made works for you, I think you can circumvent your issues by using a totally closed box with appropriate normals. As to how and why the lightmap behaves that way, this is far beyond my knowledge.