Bake Lightmap problem

Sneaky_amxx

I've tried modifying settings, lowering everything. And even tried to just bake a small section of the scene, nothing made a difference and it always gets stuck at that exact same position of "denoise and fix seams" no idea what to do anymore.

EDIT : uploaded the scene after i converted it to only use 1 texture to save download space. https://github.com/Sneaky-amxx/godot-bakemap

Megalomaniak

Anything come up in the console window perhaps? A warning or an error?

Sneaky_amxx

@Megalomaniak said: Anything come up in the console window perhaps? A warning or an error?

When the client stops responding i get this error. But i mean i have 32gb ddr4, why would memory be an issue in baking such a small map to begin with?

cybereality

32GB is fine. I baked on my old computer with 16GB. But that floor object looks big. Even though it is only partially inside, maybe it's trying to bake that too and it's too much. Are they separate objects or one big map?

Sneaky_amxx

@cybereality said: 32GB is fine. I baked on my old computer with 16GB. But that floor object looks big. Even though it is only partially inside, maybe it's trying to bake that too and it's too much. Are they separate objects or one big map?

There are multiple objects within 1 single gltf file. The floor is it's own object inside the gltf scene

cybereality

Does everything have a UV2 map?

Sneaky_amxx

@cybereality said: Does everything have a UV2 map? Yes it does.

Sneaky_amxx

I reduced the scene textures to 1 file so the project is a quick small download and uploaded it if someone wants to help

https://github.com/Sneaky-amxx/godot-bakemap

cybereality

So, I got the same crash on my system, and I have a 16-core CPU and 64GB of RAM, so it should be no problem. But it looks like the level was just too big. I mean it was the wrong scale. I scaled it down to 0.25 and then the bake worked. Note that 1 unit in Godot is typically 1 meter in real life (though it is somewhat arbitrary, you should follow it because many systems like physics and lighting rely on this convention). So your model was 4x the size of real life, I guess that was the problem.

Sneaky_amxx

@cybereality said: So your model was 4x the size of real life, I guess that was the problem.

wait what? but the size of the model is the size i need it to be.. And surely theres scenes with much larger models so i don't understand how that makes any sense at all.... my player is 4m tall and the level's walls, doorways and ceilings are proportioned to fit a 4m player which is constantly bunnyhopping / jumping and getting airborn.. are you saying 4m player size is abnormally large?

Calinou

First, I recommend decreasing the lightmap texel density as you did. When you only bake indirect lighting (the default), you don't need a very high texel density to begin with, as indirect lighting is low-frequency data.

For future readers: If decreasing the texel density does not resolve this, try disabling denoising in the BakedLightmap inspector, as OpenImageDenoise can be very RAM-intensive. To combat noise in your "final" light bake, increase the bake quality before baking lightmaps.

The out of memory issue likely happens because Godot 3.x's CowData limits individual data structures to 2 GB each (32-bit integer). This may be fixed in 4.0, which also has a GPU lightmapper rewritten from scratch (it's much faster on a dedicated GPU).

cybereality

I see what the issue is. The light baking was working fine. It was the capture that was messed up (used for lighting dynamic objects based on the baked light). If you set Capture > Enabled to False then everything works. But in a real game you probably want this Enabled for the best graphics. You can also leave Capture On and set Capture > Cell Size to 4 and then it also works.

Calinou

The lightmap dynamic object capture algorithm is pretty bad in 3.x (it generates huge data). It's much better in master, but it can't be backported as it relies on GPU baking. Unfortunately, JFons currently doesn't have much time to continue working on the 3.x lightmapper, so I doubt 3.5 will get a better dynamic object capture implementation.

woopdeedoo

You might want to reduce the amount of faces the lightmap must compute. Any faces the player never sees should be removed from the level. I don't know if this helps fix any issues, but I suppose so, as it probably reduces the amount of memory it uses and the amount of data it generates.

Well, at the very least it will reduce the time it takes to compute lightmaps, so it's always a good idea anyway.

Calinou

Any faces the player never sees should be removed from the level.

This can introduce light leaking (especially when using GIProbe/VoxelGI or SDFGI), so beware. The lightmapper may handle this situation better, but there still are valid reasons to keep unseen faces in your level in some cases.