Add texel_scale property to LightmapGI

[marcinn]

This PR adds texel_scale property to LightmapGI.
Closes godotengine/godot-proposals#3893.

---

Side notes:

1. This patch also adds BakeError:BAKE_ERROR_LIGHTMAP_TOO_SMALL together with a new warning message. I'm unable to generate editor/translations/editor.pot by using extract.py due to message duplicate error (editor.pot becomes empty). I have read the README files and contribution docs, but still don't know what exactly to do when adding new messages. As I'm not sure if the new BakeError (along with the new message) will be accepted, I decided to submit this potentially unfinished PR.

2. The new BakeError should help in other lightbaking cases (errors or incorrect user input) that result in an incorrect image size (width or height equal to zero). In such cases the editor should display a warning instead of freezing.

[jcostello]

This should affect #62987 once its ready. IDK which one will be merge first @techiepriyansh

[jcostello]

BTW, works well

[marcinn]

This should affect #62987 once its ready. IDK which one will be merge first @techiepriyansh

I'm not sure how related it is. If Texel Scale should affect visualisation of texel density, its value must be stored somewhere and must be accessible in runtime (as a copy in each baked mesh?). Currently it is stored only in LightmapGI node and affects lightmap_size only during offline baking.

[jcostello]

IMO, it should affect the visualization of texel density in the debug view. Lets hear @techiepriyansh opinion

[Calinou]

I'm unable to generate editor/translations/editor.pot by using extract.py due to message duplicate error (editor.pot becomes empty).

Don't worry – you don't need to generate those files yourself, as this is done periodically by Akien 🙂

[techiepriyansh]

IMO, it should affect the visualization of texel density in the debug view. Lets hear @techiepriyansh opinion

Yes, technically, it should. But it won't be needed if the users only care about the relative texel density of different meshes in the visualization.

[jcostello]

IMO, it should affect the visualization of texel density in the debug view. Lets hear @techiepriyansh opinion

Yes, technically, it should. But it won't be needed if the users only care about the relative texel density of different meshes in the visualization.

If it can be easily done I suggest to have it to have coherence with the lightmap size in the mesh attributes

[clayjohn]

Please note, I have marked this as "for pr review", technically, we are in a feature freeze right now, so new features should not even be considered for merging. However, this is a relatively small change, so it may be able to sneak in.

[marcinn]

@clayjohn Thanks.

[jcostello]

@clayjohn I would appreciate it

[jcostello]

@clayjohn please consider this to 4.0 🙏

[Calinou]

Tested locally (rebased on top of master 4714e95), it works as expected.

Testing project: test_pr_64908.zip

I noticed a small issue in the editor however:

This message is spammed when you adjust the Texel Scale property to its minimum value in the LightmapGI inspector:

./scene/3d/lightmap_gi.cpp:1437 - Condition "p_multiplier < 0.01" is true.

I'm surprised this happens, considering the property hint disallows values lower than 0.01.

[marcinn1]

I'm surprised this happens, considering the property hint disallows values lower than 0.01.

I bet this could be floating point precision issue, not related to my patch.

[Calinou]

I bet this could be floating point precision issue, not related to my patch.

In this case, I'd suggest changing the check in the setter method to compare against 0.01 - CMP_EPSILON.

[marcinn1]

I bet this could be floating point precision issue, not related to my patch.

In this case, I'd suggest changing the check in the setter method to compare against 0.01 - CMP_EPSILON.

I've rebased and added this change. I see no spam messages at 0.01.

BTW: On my setup the longest part of generating lightmap with texel_scale=0.5 for this project is denoising.

[Calinou]

BTW: On my setup the longest part of generating lightmap with texel_scale=0.5 for this project is denoising.

Denoising is performed on the CPU using OpenImageDenoise. Latest versions support GPU denoising, but we can't update to the latest version because of the new ISPC dependency which makes building OIDN from source very difficult.

Since lightmapping on the GPU is quite fast (especially with modern high-end GPUs), denoising will often take more time than baking lightmaps if you have a GPU that is fast compared to the CPU. This is the case even on top-end setups with "matching" CPU and GPU (such as i9-13900K + RTX 4090), as GPU processing speed is evolving much faster than CPU speed (even in multicore tasks).

Also, once this PR is merged, I could adapt #80518 to add a setting that automatically multiplies texel scale for preview bakes. You can choose to forcibly disable denoising in preview bakes too, although I've left it enabled by default because bakes look pretty bad with denoising disabled.

[marcinn1]

Denoising is performed on the CPU using OpenImageDenoise

Oh, it uses just 1 core/thread. There are threading limitations introduced for Godot, like this:

   // -- GODOT start --
   #endif
   numThreads = 1;
   // -- GODOT end --

[clayjohn]

Denoising is performed on the CPU using OpenImageDenoise

Oh, it uses just 1 core/thread. There are threading limitations introduced for Godot, like this:

   // -- GODOT start --
   #endif
   numThreads = 1;
   // -- GODOT end --

See: #81659

[clayjohn]

Seems fine to me! I haven't tested locally, but I trust the other reviewers

[AThousandShips]

Needs a rebase

[akien-mga]

@marcinn @marcinn1 Are you available to rebase this PR?

[marcinn1]

Yes, give me a moment please

[marcinn1]

@akien-mga done!

[akien-mga]

Thanks!