Hi.

After days and weeks struggling with BakeLightmap issues, I got baking light working pretty well.
Problems I found:

  • Denoising consumes huge amount of memory. The bigger size of lightmap texture is created, the denoiser needs more memory
  • Meshes rasterization also slows down, when lightmap texture size increases. Overall baking time can be slow, regardless of the quality settings.
  • In case where multiple BakeLightmaps shares same mesh, the last baked will take over the mesh and bind the lightmap to it.
  • Godot editor is not always refreshing the baked lightmap.

My conclusions:

  • To avoid "fighting" for the shared mesh, use just one BakedLightmap per scene.
  • High resoultion of the lightmap is not needed. Reducing the texture size will speed up baking and avoiding out-of-mem crashes while denoising.

How to reduce the lightmap texture size? There are two possibilities in Godot:

  • setting up lightmap_size_hint on each MeshInstance
  • reducing default_texels_per_unit on BakedLightmap node.

The problem is that "default_texels_per_unit" are overridden by lightmap_size_hint and in most cases gives nothing, so you must adjust lightmap_size_hint manually for each mesh. This is problematic when the scene is composed of many meshes or imported via tools like Qodot.

I solved the issue by introducing an experimental parameter to BakedLightmap: force_lighmap_scale. It scales down or up the lightmap texture size.

Setting it to 0.1 or 0.2 results in very fast light baking and solves crashing issues during denoising, also for high quality settings. Downscaling the lightmap about 5x times gives still very good results. For my scene sized about 300 x 60 x 200 units, setting lightmap_scale to 0.2 gives final exr texture of 1024x2048 size, and short baking time (about 1-2 minutes for all lights direct+indirect+shadows, HDR, color).

Now I can do light baking in Godot. The one thing I'm missing now is ambient occlusion baking.


Final recommendations for Godot developers:

  • Please consider adding "lightmap scale" property to BakedLightmap, maybe together with min an max props to limit the maximum and avoid too small sizes. This will give a handy possibility of fine tuning the light quality, baking times, memory consumption, and will give easy way of avoiding crashes.
  • Please consider upgrading OIDS (denoiser) to the recent version. Some memory and performance issues were already addressed.
  • Please consider adding ambient occlusion baking. That would give best quality results without using slow and not best SSAO.

Kind Regards,
Marcin

If you set lightmap hint to 0, 0 then you can use the texel size. But I find lightmap hint gives better control.

    Note that godot 4 is getting a whole new lightmapper.

      cybereality

      Yes, but this still requires changing all mesh instances. And lightmap size hint will reset after reimport (this happens when rebuilding the level with Qodot).

      Global scale factor is super easy to use. You can assume that default lightmap size hints are fine, and still have possibility to upscale/downscale final lightmap size without touching hints, their proportions (if it's matter). It's time saving.

        Megalomaniak

        Yes, I know. But Godot 4 is not stable yet, and as far I know the new lightmapper has it's own issues, including crashes. https://github.com/godotengine/godot/issues/56080

        Godot 3.5 is here, it's stable, engine it's pretty fast, and when you fix/avoid issues like this, you're able to finish a game that doesn't look like it came from MatLab. GIProbe from 3.x is too leaky and slow, so classic lightmapping is the best way to go. And you can target on potato pc (or something a little bit better) 🙂

            marcinn Yes, I know. But Godot 4 is not stable yet, and as far I know the new lightmapper has it's own issues, including crashes.

            Yes, my point was that the feedback you give will probably not be very applicable to the new lightmapper. I suppose theres a chance of someone perhaps being willing to add a feature or two to godot 3.x lightmapper yet, but remember that breaking changes are very unlikely to happen.

                Megalomaniak

                Megalomaniak Yes, my point was that the feedback you give will probably not be very applicable to the new lightmapper

                Agreed.

                Megalomaniak but remember that breaking changes are very unlikely to happen.

                I know. This proposal is fully backward compatible when force_lightmap_scale is set to 1.0 (a default value). Upgrade of OIDS should be backward compatible too, because it is a just dependency, and it is not exposed to the end user.

                        We are probably around a year away from Godot 4.0 stable, so I think 3.x support is still useful. Also, Godot 3.x will likely be supported for some time, even after 4.0, releases, and some people may choose to continue using it past that point if they have (or are targeting) low spec machines.

                        marcinn This proposal is fully backward compatible when force_lightmap_scale is set to 1.0 (a default value). Upgrade of OIDS should be backward compatible too, because it is a just dependency, and it is not exposed to the end user.

                        Yes, I'm not saying these are necessarily breaking(though that's likely up to implementation) changes but just that breaking changes are unlikely but not completely impossible to happen(there have been rare exceptions in the past).

                        I probably should have added to say that these changes are not likely to happen soon but could maybe manifest in say 3.7 or 3.8 if there's a willing developer.

                        For the most part though developers are rather focused on 4.0 and most new features in 3.x are backports at this point, which bring me back around to saying that 4.0 will feature an entirely new lightmapper that this feedback is probably not very applicable to.

                            Megalomaniak

                            Ok, let's simplify the case:

                            1. The lightmapper in 3.5 is NOT usable in most cases.
                            2. My proposal introduces a small improvement, which make the lightmapper usable for most cases (opposite to the current state). Due to backward compatibility it will not work for everyone by default, but gives a possibility to solve the issue.

                            Without this little change, lightmapping is impossible. This is a usability bug, which should be fixed in the upcoming release. I will try to prepare a PR.

                            The only new feature I wrote about is ambient occlusion baking, which will probably never be added (and I understand that).

                                marcinn This is a usability bug, which should be fixed in the upcoming release. I will try to prepare a PR.

                                Then that's a whole other story. I wish you success.