BoneMap retarget on FBX files or FBX2glTF conversions cause broken LODs

[lyuma]

Godot version

4.1.dev 6980b2b

System information

Windows 10

Issue description

By default, Blender exports .fbx models at 100x scale. If an FBX model is converted into gltf by hand or imported to Godot with automatic FBX2glTF conversion, it handles this 100x scale by applying it directly onto the root nodes of the scene, such as Armature:

I now adjust the import settings to have a BoneMap and a SkeletonProfileHumanoid:

and now the scale of Armature is 1,1,1, and the LODs are broken (due to Godot expecting a 100x scale difference):

You can see here that the scale was instead propagated into the skin bind pose:

Steps to reproduce

1. make a new scene and drag the the _rotated.fbx model or the _rotated_fbx2gltf.gltf models in.
2. Change advanced import settings of the _rotated.fbx model or the _rotated_fbx2gltf.gltf model Skeleton3D node to have A BoneMap and assign a SkeletonProfileHumanoid inside the BoneMap.
3. see these models in the scene.
4. Observe the LOD artifacts (can be confirmed by disabling LOD)

Minimal reproduction project

https://github.com/godotengine/godot/files/11437148/BoneMap_non_skinned.zip
(Model is permissively licensed and available from https://booth.pm/ja/items/2019040 "2A-7-4 / XXXX Coolk")

[lyuma]

This is related to #76891 and uses the same reproduction project, but it's a different problem.

Solving #76891 might help address some of the mesh scaling issues that cause this LOD issue.

Either the skin adjustment during retarget needs to lead to different LOD settings, or else there's still a bug when skin has 100x scale in bind poses.

[lyuma]

I did some investigating. here is the cause of this bug:

The issue is with bone_aabbs in RendererRD::MeshStorage::Mesh::Surface ... It seems that unused bones in this have a size of -1,-1,-1 instead of 0,0,0 as the code expects. Is this intentional?

To fix we either need to

1. change unused bones to have size of 0,0,0 instead of an invalid AABB?
2. Or detect an invalid AABB with -1,-1,-1 and avoid adding it to the laabb in the above code.

Now, as for why this matters, some meshes are scaled, so -1,-1,-1 can easily blow up to large bounding boxes like 100,100,100 as seen in the screenshot.

Due to another possible bug, the way LOD system chooses the lod_distance is the distance to the border of the AABB...... so if you're at the middle of a 100x100x100 AABB, the lod_distance will be 100, which makes Godot pick a very low quality LOD.
ideally, Godot would always pick the best LOD if the camera is within the mesh AABB, but that's a different bug / problem / design decision.

[lyuma]

#76184 should also contain the fix for this bug.. didn't test it yet.

[fire]

What is the test plan for this? How can I tell it works?

Can paper review too.

[fire]

May be fixed?