SharpGLTF: Struggling with Invalid Matrix

I’ve been struggling with matrices lately, and I’m wondering whether Matrix4x4.Decompose is too strict or the matrix is truly poorly formed.

I’m using the SceneBuilder API to put together a node hierarchy. For each node, I set the local matrix like so:

var nb = nodeBuilder.CreateNode(bone.Name);
nb.UseTranslation().Value = bone.Position;
nb.UseRotation().Value = bone.Rotation;
nb.UseScale().Value = bone.Scale;

Then, I create a mesh, and calculate the inverse bind matrices:

var nb = nodeBuilders[bb.BoneIndex];
var wm = nb.WorldMatrix;
Matrix4x4.Invert(wm, out Matrix4x4 wmi);
wmi.M44 = 1; // force to be one
return (nb, wmi);

Note: Somehow M44 becomes 0.999999, which is probably due to a precision error caused during the Invert method, and the gltf validator doesn’t like this so I forced it to a 1.

Now when I save the gltf file, I get a complaint that a matrix is invalid. I commented out the part that throws the exception just to force the file to save and I can inspect it on my own.

I believe this is due to the Matrix4x4.Decompose function returning false. I think it returns false because the determinant of the rotation part of the matrix is <0.985 as opposed to 1.0 and that’s enough to fail the “DecomposeEpsilon” threshold. When I use the gltf validator provided by Khronos, it says the file is valid.

I guess the question is whether these matrices are good enough and the Decompose method is too strict. I also wonder where the imprecison comes from. The local matrices are created from proper position, rotation, and scale data. Maybe if the hierarchy is deep enough, then computing the world matrix loses precision after so many local matrices are multiplied together.

I just wanted to get your thoughts on this, and what we can do about this. I have attached an example gltf. grnGltf.zip

Thanks!

I also posted a similar issue in the dotnet repo where Decompose returns false in an even simpler example. I was hoping someone could explain how precision was lost, and what to do about it. Initially I thought it was a bug, but now I think either the threshold is too strict, or there are precision problems. https://github.com/dotnet/runtime/issues/34874