How are related morphAttributes.position arrays to attributes.position

Questions
1

Using ThreeJs r164.1

How are related geometry.morphAttributes.position arrays to geometry.attributes.position.
I inspected 2 fbx loaded models and I observed that geometry.morphAttributes.position[n].count is less than geometry.attributes.position.count.

In the big picture I want to optimise the model and recreate meshes and skinned meshes around new geometry grouped by materialIndex.
I do that by iterating on groups for each mesh and extracting from attributes the vertices that are related for that group.materialIndex === mesh_material_index

Everything went fine until I tried to port the morphAttributes into new skinned meshes.
The issue is that if their length would be equal I could apply the same slicing method.
But since their count is different …

I found a comment in FBXLoader saying that: “Normal and position attributes only have data for the vertices that are affected by the morph”.
But if for example I check the ThreeJS code for Mesh.getVertexPosition I see it assumes their count is equal.

I am looking for a clue, some info that I miss that would map geometry.morphAttributes.position[n] to
geometry.attributes.position.

BTW: ChatGPT also assumes they are equal.

If I play around with morphTargetInfluences they work fine (I can see the character changing with meaning: like smile face expression)

Opening the model in Blender I can see the shape keys and that they are related to the base shape (same number of vertices).

2

The lengths of base and morph attributes are indeed expected to be equal. While formats like FBX or glTF can store sparse data where morph targets for unchanged vertices are not stored, I would expect that to be unpacked by the loader into morph attributes of the full length… if the BufferAttribute lengths differ for your model, I don’t know what the results would be, and it could be a bug.

2 Likes
3

Thank you @donmccurdy I think I should raise an issue then for FBXLoader

4

@donmccurdy , I created an issue here: FBXLoader morphAttributes.position[n].count is less than attributes.position.count · Issue #28378 · mrdoob/three.js · GitHub and added you in the loop to help in finding a resolution if it is a bug or not.