engine icon indicating copy to clipboard operation
engine copied to clipboard

glb-parser: incorrect skinning

Open querielo opened this issue 3 years ago • 2 comments

Description

It looks like we have a bug connected with skin meshes that has a non-identity transform.

Right now, glb-parser saves transform of a node with mesh and skin and does not treat it as special case somewhere here. It causes incorrect model skinning.

Details: According to glTF spec: "The matrix defining how to pose the skin’s geometry for use with the joints (also known as “Bind Shape Matrix”) should be premultiplied to mesh data or to Inverse Bind Matrices.". But glb-parser stores node transform as is. And in a vertex shader this transform is applied on the left side. But according to the spec the transform is premultiplied to mesh data.

How it is done on other tools?

Blender glTF importer

As you can see here Blender stores bind tsr but "a skinned mesh is instantiated has no effect on its world space position". So, they ignore the node transform.

Babylon.js

Babylon.js does not have explicit bind matrix in scene node (similar to Playcanvas). And they also just throw away transform of node with mesh and skin. You can find it here.

Three.js

Bind matrix is stored as a special matrix while binding skeleton to mesh. And they use it while world matrix recalculation. Also, a user can change bind mode.

Suggestion

I might be wrong but we need to process node transform here as special case and maybe just remove node transform as Babylon does.

querielo avatar Sep 01 '22 21:09 querielo

You could be right here, but it would need a deeper investigation / testing.

For reference, more info here: https://github.com/KhronosGroup/glTF-Tutorials/blob/master/gltfTutorial/gltfTutorial_020_Skins.md#the-joint-matrices (search for 'Bind Shape Matrix')

mvaligursky avatar Sep 02 '22 09:09 mvaligursky

For now, perhaps a work-around would be to export gltf files with the mentioned node matrix as identity, if this is an option.

mvaligursky avatar Sep 02 '22 09:09 mvaligursky