Light baking

[marcinn]

Hi.

I'm trying to bake lights and shadows for the best performance. Is possible to modify the plugin to work with baked lightmaps, especially for "All (Direct+Indirect)" bake mode? I would like to preserve LODs and detail layers (foliage). I know that this could be a quite complex task, but I'd like to know is this doable with Godot and Heighmap Plugin.

Thanks.

[Zylann]

This needs to be added somehow but I have no idea how, since light baking in Godot is hardcoded to work exclusively with static meshes. The way this plugin renders the heightmap is not using static meshes, instead it's using a dynamic system of variable-size chunks displaced with shaders... The most fitting way for this technique is to have GI data encoded in one texture map the size of the terrain (alongside splatmap, heightmap etc) so the shader can access it, but I feel Godot is missing something for that to be done? There is an option to generate a temporary giant monolithic mesh for generating navmeshes (which also is hardcoded to work with meshes and no heightfields), so maybe it could exploit something like that for producing the lightmap for the terrain, but I'm not sure the generated data will be optimal, and since that mesh will have to be removed I wonder if that would also delete its baked light (where does it go?), or if it would even be in an individual texture (also the editor might die a little if the terrain is large).

[Calinou]

For lightmap baking to work:

• UV2 needs to be generated or manually authored for the terrain chunks.
• Terrain needs to have its final shape on the CPU (that means, no distortion via a shader).
• Terrain must be rendered within the editor.
• Baking must be done within the editor, or by running the project from the editor (when calling bake() on the BakedLightmap node). Baking lightmaps is not supported from an exported project (but baking GIProbe is).

Since Godot can already bake lightmaps for non-terrain meshes, maybe a custom light baking solution for the terrain could be a good idea. This would sidestep the issue with shader-based displacement not being visible from the lightmapper's point of view (which would result in incorrect lighting).

[marcinn]

Thank you for the explanation.