Unable to bake lightmap with CSG due to the lack of ability to generate UV2 for CSG nodes

[theraot]

Godot version:
Godot 3.2.4-beta6 to Godot 3.3-rc8

OS/device including version:
Windows 10
NVIDIA GeForce GTX 750 Ti
GLES2/GLES3

Issue description:

BakedLightmap does not work with CSG nodes. As far as I can tell, this worked up to beta 5.

As far as I can tell the CSG node does not have a UV2 layer. And I cannot use "Create Outline Mesh" + "Unwrap UV2 for Lightmap/AO" with it (The Mesh option in the toolbar does not appear for CSG nodes).

Steps to reproduce:

• Create new Godot project (GLES2 or GLES3, does not matter).
• Create new Spatial scene.
• Save it, any name.
• Add CSGBox (or any other CSG node) to the scene. Observe there is no Mesh icon in the bar when the CSG node is selected.
• Set use_in_baked_light = true of the CSG node.
• Add BakedLightmap node (make sure the CGS node is inside).
• Click BakeLightmap, select any path, click "Save".

Result: Message appears "No meshes to bake. Make sure they contain UV2 channel and Bake Light flag is on."

Expected Result: The light is baked (which is no light, since we didn't add any, and thus the CSG should appear dark).

Minimal reproduction project:
BakeMeUp.zip

[Calinou]

Add CSGBox (or any other CSG node) to the scene. Observe there is no Mesh icon in the bar when the CSG node is selected.

This is intended, since CSGBox doesn't inherit from MeshInstance.

To be fair, we'd need godotengine/godot-proposals#182 to be implemented first to make this a reliable option. Baking UV2 on a CSG node whose geometry can change on a whim isn't necessarily a good idea…

[theraot]

Baking UV2 on a CSG node whose geometry can change on a whim isn't necessarily a good idea…

For context, I wanted to test with CSG nodes because they would give a quick cycle of reshaping them, baking lights, see changes, repeat. The intention was to try to find issues with baked lights.

Edit: this is what I was trying to test: https://gamedev.stackexchange.com/questions/191503/godot-engine-why-is-baking-light-making-my-scene-darker

Edit2: An issue was opened for that case at #47785

[kalbfled]

I authored the StackExchange question @theraot references above. I attempted the same basic test he describes, except I used MeshInstances with CubeMesh and PlaneMesh as the mesh data. I couldn't bake light with that setup because Godot refuses to unwrap meshes that are not instances of ArrayMesh.

This doesn't make sense to me when these meshes already have a mapping in uv1. Maybe this is a candidate for an enhancement--allow baking with PrimitiveMesh instances.

I worked around by creating a plane+cube scene in Blender and transferring it into Godot as .glb.

[theraot]

@kalbfled I ended up working around that by using "Create Outline Mesh" which would create ArrayMesh from the MeshInstances I had, and then "Unwrap UV2 for Lightmap/AO". I arrived to that searching online. This is also the motivation to mention on this issue that that is not an option with CSG.

[theraot]

Is this UV2 not the same UV2? Because this seems to have UV2, but still can't bake:

[Zireael07]

If you are referring to the uv2 property of the detail section of the material - nope, that's only telling the material how to scale UV2 IF it exists. And CSG doesn't have UV2.

[theraot]

@Zireael07 Well, it scaled something. The material is showing a texture applied according to the Uv 1 property section, combined to a texture applied according to the Uv 2 property section, combined according to the Detail property section. I also tried converting that to shader code, and it used UV2. So, if anything, that is confusing.

Was it a decision to remove UV2 from CSG? Or was it that baking didn't use UV2 before? (As I stated in OP, baking worked in beta5 and older, including stable).

[Calinou]

Was it a decision to remove UV2 from CSG? Or was it that baking didn't use UV2 before? (As I stated in OP, baking worked in beta5 and older, including stable).

Baking always used UV2, and baking UV2 was never supported on CSG nodes, unless you converted them to a MeshInstance + ArrayMesh setup with a script.

[theraot]

@Calinou

Alright, what I'm understanding is that CSG does not have UV2, and that baking working before was as accident. In that order of ideas, I propose a solution for this issue: remove the baking light properties from CSG nodes (use_in_baking_light, generate_lightmap and lightmap_scale).

Also, somebody may want to see into the naming of Uv2. The CSG has something called like that, that works.

[Zireael07]

Yep, I have to admit the naming in your specific situation is confusing indeed. Regarding the materials being actually displayed, it's even more confusing.... some sort of a silent fallback to UV1 because UV2 doesn't exist?

[Calinou]

In that order of ideas, I propose a solution for this issue: remove the baking light properties from CSG nodes (use_in_baking_light, generate_lightmap and lightmap_scale).

Those properties are available in any GeometryInstance node, and CSG nodes inherit from GeometryInstance. I don't think it makes sense to hide them there, or even if it's technically possible.

[theraot]

@Calinou I suppose we have a wontfix then.

Just to be clear, this was not supported: https://youtu.be/vEFYSpxnfdE

[ee0pdt]

Those properties are available in any GeometryInstance node, and CSG nodes inherit from GeometryInstance. I don't think it makes sense to hide them there, or even if it's technically possible.

I could understand it not being technically possible - but surely it makes a lot of sense to hide them if it is possible?

I just wasted a fair amount of time trying to understand why CSG meshes were not baking! Could we at least have a warning added?

[ee0pdt]

@Calinou I'm not aware of any, but that is not the only option we could explore here. I'm just suggesting we find a way to inform users that these properties have no effect for a given node.

The closest thing I can think of is the warning on a Container node:

[Calinou]

@ee0pdt I removed my old comment because it was incorrect. It should be possible to hide the properties only in CSGShape3D and its descendents using _validate_property() as done here:

godot/modules/csg/csg_shape.cpp

Lines 571 to 579 in 27d4e2f

	void CSGShape3D::_validate_property(PropertyInfo &property) const {
	bool is_collision_prefixed = property.name.begins_with("collision_");
	if ((is_collision_prefixed || property.name.begins_with("use_collision")) && is_inside_tree() && !is_root_shape()) {
	//hide collision if not root
	property.usage = PROPERTY_USAGE_NOEDITOR;
	} else if (is_collision_prefixed && !bool(get("use_collision"))) {
	property.usage = PROPERTY_USAGE_NOEDITOR | PROPERTY_USAGE_INTERNAL;
	}
	}

Edit: We'll have to use the node configuration warning approach as the use_in_baked_light property is used with GIProbe (and its sucessor is used with SDFGI in master). These GI approaches do work with CSG nodes (or are intended to at least). However, the node configuration warning should only be emitted if there's a BakedLightmap node in the scene tree. This makes the issue significantly harder to resolve.

I tried to make UV2 available in CSG nodes, but it's not trivial to do correctly. Due to UV padding and seam issues, it would likely better be done by exposing a nondestructive CSG -> MeshInstance conversion workflow and letting Godot use xatlas on the generated mesh instead.

[Zireael07]

Speaking of xatlas, IIRC it doesn't like the built in meshes (e.g. cubemesh to use 4.0 terminology) either?

[Calinou]

Speaking of xatlas, IIRC it doesn't like the built in meshes (e.g. cubemesh to use 4.0 terminology) either?

It's not xatlas' fault – it's because Godot does not have a way to store custom UV2 for primitive meshes. This would need to be added, but it's not really a priority as primitive meshes are rarely used in "final" level designs.

[akien-mga]

Is this still reproducible in 3.5 beta 5 or later?

[Calinou]

Is this still reproducible in 3.5 beta 5 or later?

Yes, as far as I know, nothing changed on the subject. This isn't easy to fix, and will probably require a proposal to decide how to store the generated UV2 for a non-imported, generated mesh. I assume this would also be useful for @Zylann's terrain add-on to an extent.