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…?
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?
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.