LightmapGI: Stripes on curved surfaces

[passivestar]

Tested versions

v4.3.dev6.official [89850d5]

System information

Godot v4.3.dev6 - macOS 14.4.1 - Vulkan (Forward+) - integrated Apple M1 Max - Apple M1 Max (10 Threads)

Issue description

I'm getting weird stripes when baking some geometry with LightmapGI and I can't get rid of them by tweaking any settings.

I first reported this in #90929 but I'm opening a separate issue for this as suggested by @lander-vr, because this seems to be a separate issue

Steps to reproduce

MRP

Minimal reproduction project (MRP)

MRP_lightmap_stripes.zip

[DarioSamo]

As I said in the issue, how was the shape generated? Can you compare the result to when you do it from importing an OBJ?

[lander-vr]

These are really strange artifacts:

It looks like it's happening after denoising and dilation. Changing denoising parameters doesn't affect the shape, but does make it smoother. The dilated pixels themselves look normal to me.

After denoising:

Using a higher texel scale, those bands remain at the same width of 3 pixels.

[passivestar]

As I said in the issue, how was the shape generated? Can you compare the result to when you do it from importing an OBJ?

I imported gltf. Both gltf and the blend file that it came from are in the MRP

Tried exporting as OBJ, same result

[lander-vr]

Can you compare the result to when you do it from importing an OBJ?

I don't think this is a UV issue that's carrying over into the raytracer, unless I misunderstood the issue you referenced in the other post. It seems to happen after all that somehow. Otherwise the dilated pixels would carry over the same values as those stripes, and the denoiser would at the very least make the shape of those stripes significantly less sharp.

[DarioSamo]

I wonder if it's something that can trigger due to the nature of the concave shape and the rays probably hitting inside of the cylinder rather than outside. It's a bit odd it happens on the seams but it could explain why if it's being traced at the very edge of the seam. That's why I ask about the UV2, since it could be pushing it towards one of the edges perhaps since I only see one side of the seam being blurry. That hints that it's tracing from the right side on the pixel at one edge but not on the other edge.

[lander-vr]

I enabled debug_textures in lightmapper_rd. It seems to happen during the blendseams step.
This is the secondary light pass:

After blend seams:

All other passes look completely fine to me.

[lander-vr]

I wonder if it's something that can trigger due to the nature of the concave shape and the rays probably hitting inside of the cylinder rather than outside.

I don't think it's related to the shape, I'm fairly certain I've seen the same issue on one of my modular test scenes using planes in which it's also unaffected by denoiser settings:

[DarioSamo]

I enabled debug_textures in lightmapper_rd. It seems to happen during the blendseams step.

Interesting. I haven't really delved into the seams blend step yet so I can't give much info about that.

[passivestar]

Also encountered it on beveled geometry, so it's not limited to concave shapes. Only sharp edges currently bake with no bugs. Updated the MRP to include this

[lander-vr]

Paging @reduz since he implemented the lightmapper (along with the blendseams step). Maybe he's got some ideas on what may be happening here. It would be nice to also hear what the blendseams step is trying to achieve.
To me the lightmaps seem to look fine after the secondary pass as is, so it might be worth exploring some bakes without the blendseams step. That said though, that may be a naive suggestion because I don't really understand blendseams.

[passivestar]

godot/modules/lightmapper_rd/lm_blendseams.glsl

Line 102 in 78cce19

dst_color = vec4(1, 1, 0, 1);

This is what lm_blendseams.glsl draws in debug mode:

The sharp edge might mean that it's using a wrong uv offset when blending

This is the part of the shader that blends lines:

godot/modules/lightmapper_rd/lm_blendseams.glsl

Lines 44 to 70 in 78cce19

	#ifdef MODE_LINES
	uint seam_idx = params.base_index + gl_VertexIndex / 4;
	uint seam_subidx = gl_VertexIndex % 4;
	uint src_idx;
	uint dst_idx;
	if (seam_subidx == 0) {
	src_idx = seams.data[seam_idx].b.x;
	dst_idx = seams.data[seam_idx].a.x;
	} else if (seam_subidx == 1) {
	src_idx = seams.data[seam_idx].b.y;
	dst_idx = seams.data[seam_idx].a.y;
	} else if (seam_subidx == 2) {
	src_idx = seams.data[seam_idx].a.x;
	dst_idx = seams.data[seam_idx].b.x;
	} else if (seam_subidx == 3) {
	src_idx = seams.data[seam_idx].a.y;
	dst_idx = seams.data[seam_idx].b.y;
	}
	vec2 src_uv = vertices.data[src_idx].uv;
	vec2 dst_uv = vertices.data[dst_idx].uv + params.uv_offset;
	uv_interp = vec3(src_uv, float(params.slice));
	gl_Position = vec4(dst_uv * 2.0 - 1.0, 0.0001, 1.0);
	#endif

These are the stages that blend seams in lines mode using that shader:

godot/modules/lightmapper_rd/lightmapper_rd.cpp

Lines 1929 to 1939 in 78cce19

	/* step 1 use lines to blend the edges */
	{
	seams_push_constant.base_index = seam_offset;
	rd->draw_list_bind_render_pipeline(draw_list, blendseams_line_raster_pipeline);
	seams_push_constant.uv_offset[0] = (uv_offsets[0].x - 0.5f) / float(atlas_size.width);
	seams_push_constant.uv_offset[1] = (uv_offsets[0].y - 0.5f) / float(atlas_size.height);
	seams_push_constant.blend = uv_offsets[0].z;
	rd->draw_list_set_push_constant(draw_list, &seams_push_constant, sizeof(RasterSeamsPushConstant));
	rd->draw_list_draw(draw_list, false, 1, slice_seam_count[i] * 4);
	}

godot/modules/lightmapper_rd/lightmapper_rd.cpp

Lines 1951 to 1963 in 78cce19

	/* step 3 blend around the triangle */
	rd->draw_list_bind_render_pipeline(draw_list, blendseams_line_raster_pipeline);
	for (int j = 1; j < uv_offset_count; j++) {
	seams_push_constant.base_index = seam_offset;
	seams_push_constant.uv_offset[0] = (uv_offsets[j].x - 0.5f) / float(atlas_size.width);
	seams_push_constant.uv_offset[1] = (uv_offsets[j].y - 0.5f) / float(atlas_size.height);
	seams_push_constant.blend = uv_offsets[0].z;
	rd->draw_list_set_push_constant(draw_list, &seams_push_constant, sizeof(RasterSeamsPushConstant));
	rd->draw_list_draw(draw_list, false, 1, slice_seam_count[i] * 4);
	}

[passivestar]

It would be nice to also hear what the blendseams step is trying to achieve

Without it you get... seams

BTW even when it's not doing the "same color for the entire stripe" artifact, it's still not doing a super great job at blending seams:

This is what it looks like when you don't blend with original color (if you swap this for Vector3(0, 0, 1.0)):

godot/modules/lightmapper_rd/lightmapper_rd.cpp

Line 1918 in 78cce19

Vector3(0, 0, 0.5), //using zbuffer, so go inwards-outwards

I also had some artifacts before where individual triangles of a mesh got outlined with stripes. So there's more than one problem to solve with seam blending

[Lateasusual]

BTW even when it's not doing the "same color for the entire stripe" artifact, it's still not doing a super great job at blending seams

It doesn't seem like the colour actually is the same for the whole stripe, that's an optical illusion due to the gradient :)
The main issue here is that the seam indexing is wrong, and some seams are back to front. Flipping the seam UV on the X axis fixes all the seams in those screenshots, but all the other seams that weren't previously broken become broken in the exact same way.

[passivestar]

It doesn't seem like the colour actually is the same for the whole stripe

Yeah you're right I just double checked at 100% opacity, they aren't single color