Allow any floating-point value for Lightmap Scale in MeshInstance instead of just 1×/2×/4×/8×

[jcostello]

Describe the project you are working on

3D environments

Describe the problem or limitation you are having in your project

Related with #3213

The mesh scale on the lighmap is controlled by an enum. This is not optimal to control neither the quality or space of lightmap. In this case x8 is almost enought but not a granular control

x1

x8

Describe the feature / enhancement and how it helps to overcome the problem or limitation

Allow float numers instead of a fixed enum in the scale.

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

N/A

If this enhancement will not be used often, can it be worked around with a few lines of script?

Nope

Is there a reason why this should be core and not an add-on in the asset library?

Lightmap is core

[Calinou]

There's probably a reason as to why only power-of-two scales are allowed. My guess is that the atlas is only designed to work with power-of-two sizes, as you'd end up with wasted space if you used a non-power-of-two size (since the reserved space in the atlas would "grow" to the next power of 2).

cc @JFonS

[jcostello]

There's probably a reason as to why only power-of-two scales are allowed. My guess is that the atlas is only designed to work with power-of-two sizes, as you'd end up with wasted space if you used a non-power-of-two size (since the reserved space in the atlas would "grow" to the next power of 2).

cc @JFonS

lightmap_size_hint allow any Vector2.
When importing a model, the meshes/lightmap_texel_size allows any float number. It directly impact on the lightmap_size_hint of all meshes imported

Probably we should unify the ways to improve the texel size. I understand that a power of 2 could be ideal to preserve space in the lightmap texture but is flexible enought. And you can waste space anyway with the lightmap_size_hint

[Calinou]

It turns out this is actually trivial to do: godotengine/godot#75164

I haven't spotted negative side effects from this change so far, but please test this in more complex scenes.

[WickedInsignia]

It's generally optimal in the workflow if this scales down, not up.
So 0.1, 0.5, 0.8 etc. rather than 2, 4, 8. Having the latter is important but less-used.
It's more common that most meshes in a scene will adhere to a set global texel density, and a handful of larger or further-away meshes will be reduced in lightmap size to save space. It rarely happens that artists scale upwards because that would need to be applied to most meshes in the scene and is the most time-consuming approach.

Granularity should be present in both directions but the current system prioritizes scaling-up in a way that should be dropped in future iterations.