Does anyone know if the new lightmapper in 4.0 work on procedurally generated scenes. In other words it would have to generate the dynamically lightmaps within the game. Thanks for any info.
Can the new lightmapper work on procedurally generated scenes?
- Edited
The CPU (3.x) and GPU (4.0) lightmappers' baking process is only available in editor builds, so it can't be used on procedurally generated levels. As far as I know, the same applies to GIProbe (VoxelGI in 4.0).
Lightmap baking takes a while in large scenes (especially on the CPU), so it most likely wouldn't be conductive to a good player experience anyway. It would make level generation speeds very slow unless you have a top-end CPU or GPU.
Overall, baking lightmaps in an exported project is a very uncommon thing to do – and I find it's rarely a good idea in games where it is actually employed. In fact, many games have backpedaled on this and ended up distributing lightmaps along with map files. This increases download sizes but leads to much faster initial load times.
In Godot 4.0, SDFGI will be usable in procedurally generated levels since it doesn't require any baking. SDFGI has higher performance demands compared to lightmapping, but you can make it run on relatively low-end GPUs by enabling half-resolution GI rendering in the project settings (along with reducing the number of SDFGI cascades).
What you could do is generate the procedural geometry locally on your machine, save it to disk, and then open it in the editor and bake the light maps. I think that should be possible. https://docs.godotengine.org/en/latest/tutorials/3d/procedural_geometry/arraymesh.html
@Calinou said: The CPU (3.x) and GPU (4.0) lightmappers' baking process is only available in editor builds, so it can't be used on procedurally generated levels. As far as I know, the same applies to GIProbe (VoxelGI in 4.0).
Lightmap baking takes a while in large scenes (especially on the CPU), so it most likely wouldn't be conductive to a good player experience anyway. It would make level generation speeds very slow unless you have a top-end CPU or GPU.
Overall, baking lightmaps in an exported project is a very uncommon thing to do – and I find it's rarely a good idea in games where it is actually employed. In fact, many games have backpedaled on this and ended up distributing lightmaps along with map files. This increases download sizes but leads to much faster initial load times.
In Godot 4.0, SDFGI will be usable in procedurally generated levels since it doesn't require any baking. SDFGI has higher performance demands compared to lightmapping, but you can make it run on relatively low-end GPUs by enabling half-resolution GI rendering in the project settings (along with reducing the number of SDFGI cascades).
Ok, thanks for the answer. About SDFGI, how would that perform on a PC with Intel integrated graphics?
- Edited
About SDFGI, how would that perform on a PC with Intel integrated graphics?
SDFGI is too slow to be usable on integrated graphics, unless you're targeting 30 FPS at low resolutions (1366×768 at most) and low GI settings.
If you still wish your game to be playable on integrated graphics, you can add a SDFGI toggle in your game's settings and rely on the environment lighting fallback (or constant ambient light) when SDFGI is disabled. Pretty much any 3D game needs a graphics settings menu anyway :)
2 years later
cybereality
Hey, I know this is an old thread, but I have a similar needs to the OP.
I wonder if this process you describe could be automated? I am thinking of creating a level editor with ability to bake maps for the levels. I don't mind long waiting times. So, would it be possible to spawn Godot as a process in the background, opened some project, load geometry and bake the lightmaps?
And maybe even better - have Godot running as a process in the background and my app communicating with Godot The Lightbaker via socket, sending the geometry for baking on the fly? This would allow for re-baking levels in a separate process, as the changes are made to the level in my editor app. Does that sound feasible?