Add optional UV2 logic for lightmapping to primitive shapes

[BastiaanOlij]

This PR introduces optionally adding UV2 texture coordinates to primitive shapes including support for padding along the seams of the mesh. It will also set the lightmap size hint based on a texel size that can be configured in project settings:

The default values of this is 0.2.

The Primitive Meshes related to particles have not been changed.

This PR supersedes #49932

[jcostello]

For what I can recall, emissive materials were working on baked lightmaps

[Calinou]

For what I can recall, emissive materials were working on baked lightmaps

In Godot 4, emissive materials require the mesh with the emissive material to have UV2, and have its GI mode set to Static. In Godot 3, meshes that don't have UV2 but had Use In Baked Light enabled could still contribute to lightmaps.

[BastiaanOlij]

Before this gets merged, had some more thoughts about improving the UV algorithm.
The current calculation for UV1 is based on texture maps that have even sides and should remain as is for backwards compatibility.
But it would be easy to adjust the calculations for UV2 to have the UVs proportional to the actual size of the faces which is much better suited for lightmapping or texture painting. So I want to make that change before we merge.

Also on chat there was a suggestion to automatically assign the lightmap size hint to something appropriate, we need to decide what this calculation is (basically we need to design on a pixel per meter metric).

[Calinou]

Also on chat there was a suggestion to automatically assign the lightmap size hint to something appropriate, we need to decide what this calculation is (basically we need to design on a pixel per meter metric).

I wonder how XAtlas determines this. It uses a Lightmap Texel Size property that is defined in the 3D scene's import options:

Since PrimitiveMesh doesn't have import options, we can add such a property to the PrimitiveMesh resource instead of making it an import option. Adjusting this property will cause the lightmap size hint to be updated.

[BastiaanOlij]

@Calinou hmm, I wonder if it doesn't make more sense to make it a project setting, else we'll start getting questions of people wanting it to calculate backwards when they update the lightmap size and we'll need to do some sort of aspect ratio fixation.

[BastiaanOlij]

Ok adjusted most UV2 calculations so they are based on actual sizes of the objects, just need to do BoxMesh and PrismMesh.

Also still need to add lightmap size hint calculation.

@Calinou the texelsize mentioned, if it's 0.2 does that mean that 1 pixel is 0.2 x 0.2 sized? So a square meter would have a 5x5 pixel grid for lighting data?

[Calinou]

The project setting approach sounds fine to me. Just make sure the default matches what imported meshes use by default.

@Calinou the texelsize mentioned, if it's 0.2 does that mean that 1 pixel is 0.2 x 0.2 sized? So a square meter would have a 5x5 pixel grid for lighting data?

It means each texel square is 0.2×0.2 units. Larger values result in less detailed lightmapping, as the object will have fewer texels on the lightmap texture.

For reference, the default was increased from 0.1 to 0.2 in #58071 to speed up baking significantly. When baking indirect lighting only (which is the default setup in Light3D), it ends up looking very similar in practice.

[BastiaanOlij]

I've changed this back to draft as I put the final things to it. It's been a bit of puzzling. I'm changing the UV2 calculation to be based on actual dimensions of the object and to update the lightmap size hint based on a new project setting.

So far I've adjusted:

• BoxMesh
• CylinderMesh
• CapsuleMesh
• PlaneMesh (/QuadMesh)
• SphereMesh

[BastiaanOlij]

Finished prism and torus, I don't think the meshes for particles/trails require the UV2 treatment so I've left those to the default logic.

Prism and Box meshes could use some improvement to better pack the faces and prioritize sizes for smaller textures but I'll leave that for someone with more time on their hands :P

[clayjohn]

Implementation looks fine to me, we need @reduz to approve the API additions though

[BastiaanOlij]

Android build failure seems to be an issue with the CI, not the code, @akien-mga ?

[akien-mga]

Thanks!