Using Box3.expandByObject for SkinnedMesh considers its transform

Questions
, ,
1

When I use Box3.expandByObject (or Box3.setFromObject) for SkinnedMeshes, it considers the world transform of the skinned mesh.
I know it’s invalid or inappropriate to put a transform to SkinnedMeshes, yes. But I thought it will also be ignored by the engine side.
Do you think it is a correct behavior…?

Demo: Glitch :･ﾟ✧

I’m aware that the bounding box calculation for SkinnedMesh has been added in r151.

We might want to put a code to ignore world matrix for skinned meshes here.

@Mugen87 @donmccurdy How do you think about it?

2

I can’t open the glitch. The website always shows an alert with the message:

There was an error starting the editor. Maybe try to reload?

Unfortunately, the reload does not fix it.

Um, why do you think this is true? Transforming a skinned mesh should be no problem.

The engine also honors the world transformation when doing view frustum culling.

3

This is something that glTF advises against. The glTF validator will warn if it sees a skinned mesh parented to other objects, and transforms inherited by the skinned mesh are supposed to be ignored. Only the transform of the bones should be applied. Of course if the bones are parented to the mesh, it’s all one and the same, and that’s fine.

I don’t necessarily think that three.js needs to match glTF here (we have skinnedMesh.bindMode settings, for one thing), other than being able to support that behavior – which we can. But I do think there’s an issue with bounds we may not be fully matching, e.g. if the inverse bind matrices have a particular transform baked in, then accounting for the SkinnedMesh transform directly might lead to the wrong bounding box?

1 Like
4

I can’t open the glitch. The website always shows an alert with the message:

Is it chronic, do you get the same symptom regardless of the glitch author…?
Which sandbox platform do you prefer?

Um, why do you think this is true? Transforming a skinned mesh should be no problem.

What donmccurdy says (thank you). I thought Three.js also intends to ignore the transform.

I don’t necessarily think that three.js needs to match glTF here (we have skinnedMesh.bindMode settings, for one thing), other than being able to support that behavior – which we can.

I wasn’t aware that skinnedMesh.bindMode exists!

And now I found that I misunderstood the behavior that the SkinnedMesh.computeBoundingBox also respects the bind mode and its world matrix. I simply forgot to call
SkinnedMesh.updateMatrixWorld (to update bindMatrixInverse) and SkinnedMesh.computeBoundingBox after I move the mesh.

5

Updated the Glitch to show what happens when we forget to call updateMatrixWorld before using computeBoundingBox.