Visible LOD artifacts in Basketball

[lyuma]

Godot version

4.0beta3 (also exists on 4.0alpha17, so not a new issue)

System information

Windows 10, Nvidia

Issue description

LODs on this basketball causes visible artifacts such as the black line disappearing.

View showing no artifacts when zoomed in:

View showing LOD artifacts when zoomed out:

View showing artifacts are gone when LODs are disabled.

Closeup view of the artifacts, made by @fire :

(unrelated to this issue, but this model's texture also has visible aliasing artifacts due to .glb, but that's a different bug. These texture artifacts do not happen if converted to .gltf + .jpg. please ignore texture artifacts for the purpose of this issue)

Steps to reproduce

1. Import the zipped .glb below into a project.
2. Right click the .glb and choose New Inherited Scene
3. Leave the editor in the default orientation and zoom out.
4. You should see some black lines flicker or disappear

Minimal reproduction project

basketball.zip

[fire]

Changing the lod bias to be 3 seems to make the distance when the lod level triggers to be unnoticable.

Maybe tune the constant to be 3x more conservative?

[lyuma]

Is that a change that can be applied engine-wide? Is this fix of multiplying LOD bias by 3 correct?

[fire]

The constant is tuned here

godot/scene/resources/importer_mesh.cpp

Lines 455 to 458 in 58ca303

	if (new_index_count < last_index_count * 1.5f) {
	index_target = index_target * 1.5f;
	continue;
	}

Edited:

I don't know which value is worth it.

[JFonS]

I took a look at the issue, and #68006 is definitely not correct. The sorting is needed for two reasons:

• We generate the LOD meshes in the reverse order that we want them to be in the LOD array.
• MeshOptimizer can give lower or higher error thresholds than the ones we request, so there's no guarantee that after running the generation the LODs will be sorted, in which case we would just need to reverse the array.

I did check the MRP in this issue, and the way we currently do LOD generation and selection is working fine. The problem with this particular model comes from the fact that the decimation process doesn't take into account texture coordinates.
Merging two vertices that lay in different sides of the basketball black lines results in a small error in terms of overall mesh shape (the only metric we account for now), but the break in the texture continuity makes a much bigger difference in the final renderer mesh.

Here you can see the break being produced by the texture coordinates, rather than an oversimplified mesh geometry.

I'm not sure that there is an easy solution for this issue other than checking if we can let MeshOptimizer know about texture coordinates for the mesh. But even then, a tiny change in texture coordinates can potentially have a huge impact in the final rendered mesh, so it's not a silver bullet.

[fire]

So there's two bugs.

1. is that the UVs are mirrored which is a change of sign rather than a discontinuity. It probably needs a recalculation of the uvs. Too difficult.
2. The lod levels decimate too soon.

Edited:

Testing reversing the list of lods.

It's strange that reversing the list works at all. Do you know why? It appears to be increasing the distance that the lods get selected, while still giving the correct lod index-mesh.

[fire]

May be fixed.