There're scenarios in which morph targets is not zero but no weights in mesh

[floppyhammer]

Bevy version

0.11.2

What you did

When I load some glTF files, Bevy fails to initialize MorphWeights properly because there's no weight data in the glTF json. However, MeshMorphWeights is good.

A glTF json example:

With weights

Without weights

What went wrong

Bevy should handle non-existing weights properly if there're morph targets.

Additional information

To be specific, the said glTF files are VRM files. Like this one https://hub.vroid.com/en/characters/2843975675147313744/models/5644550979324015604.

[floppyhammer]

The related code is located here https://github.com/bevyengine/bevy/blob/87f7d013c0d4f45a93a4c29e5d48237f4b512ca2/crates/bevy_gltf/src/loader.rs#L813C1-L824C7

[nicopap]

There is another bit of code just a bit below that creates a MeshMorphWeigths if they are missing.

bevy/crates/bevy_gltf/src/loader.rs

Lines 852 to 855 in 87f7d01

	let weights = match mesh.weights() {
	Some(weights) => weights.to_vec(),
	None => vec![0.0; target_count],
	};

From https://registry.khronos.org/glTF/specs/2.0/glTF-2.0.html

All morph target accessors MUST have the same count as the accessors of the original primitive.

A mesh with morph targets MAY also define an optional mesh.weights property that stores the default targets' weights. These weights MUST be used when node.weights is undefined. When mesh.weights is undefined, the default targets' weights are zeros.

For context, there are two distinct components involved in morph target animations. Since usually a single morph target controls several primitive meshes, we have one component to control all meshes on a single node (MorphWeights) and one component to control individual meshes (MeshMorphWeights), the MeshMorphWeights is updated to follow the values of the parent's MorphWeights.

It seems the bug comes from the fact we don't insert a MorphWeights on the parent when the glTF file doesn't define weights, yet we still insert MeshMorphWeigths.

It's a bit tricky to fix, you need to know the children have a MeshMorphWeigths in order to spawn the MorphWeigths on the parent.

[floppyhammer]

I made a really crude solution: main...floppyhammer:bevy:vrm-support. Any idea?

[nicopap]

I made a really crude solution: main...floppyhammer:bevy:vrm-support. Any idea?

Does this fix the issue? It can be upstreamed if so.

[floppyhammer]

To some extent, yes. However, for the glTF model I'm using for test, the mesh has a lot of morph targets (it is 56). And the for primitive in mesh.primitives() loop goes several times. For each loop, the target_count is 56. As a result, it soon exceeds the morph target limit of 64. I had to change morph_weights.extend(weights.clone()) to morph_weights = weights.clone() for it to work, which is clearly not correct according to what you said. I need to take a closer look at this.

[floppyhammer]

This is a bit confusing.

primitive_label: Mesh0/Primitive0
target_count: 56
primitive_label: Mesh0/Primitive1
target_count: 56
primitive_label: Mesh0/Primitive2
target_count: 56
primitive_label: Mesh0/Primitive3
target_count: 56
primitive_label: Mesh0/Primitive4
target_count: 56
primitive_label: Mesh0/Primitive5
target_count: 56
primitive_label: Mesh0/Primitive6
target_count: 56
primitive_label: Mesh0/Primitive7
target_count: 56
primitive_label: Mesh0/Primitive8
target_count: 56
primitive_label: Mesh0/Primitive9
target_count: 56

Is it possible that primitive.morph_targets() always returns the same result for a certain mesh?

[nicopap]

Yes. It should just be all the same number of targets. So your change is the correct one.