Here are my findings after having a look at it:
The problem comes from the bone._absoluteTransform
matrix that is updated when you call returnToRest()
and that is not recomputed when you call setPosition
/ setRotationQuaternion
.
Here’s your PG where the absolute transform matrix is saved along the position/quaternion before calling returnToRest()
and set after the call:
https://playground.babylonjs.com/#ZJIBBU#11
As you can see, it does work (note that I had to access the _absoluteTransform
directly to change it as there is no accessor for it).
You could avoid the hack of saving/setting the absolute matrix by hand by calling bone.computeAbsoluteTransforms()
. The problem is that the result of the computation is not the same as the matrix you saved before the call to returnToRest()
…
That’s something I don’t understand and people more knowledgeable than me regarding skinning may have a look at:
- just after loading, bone #0 and bone #1 both have a
_absoluteTransform
== identity - however, the scale of bone #1 is (100, 100, 100) and the quaternion is (-0.7071068286895816, 0, 0, 0.7071067336835166)
- so, it seems either the absolute transform is wrong or the computation is not the one I think it is
It would seem the absolute transform is not wrong as the mesh is displayed correctly with this matrix and wrongly when calling computeAbsoluteTransforms
… So, the computation is not the one I think it is, but computeAbsoluteTransforms()
is performing this very same computation (namely, multiply all the parent local matrices together down to the current bone) and that seems logical to me. So, I don’t understand the relationship between the local position/rotation/scale properties and the value of the absolute transform matrix of a bone.
Note that there is another possibility, which is that the position/quaternion/scale are wrong and it is the absolute transform which is ok…
[EDIT]
Another possibility is that both position/rotation/scale AND the absolute matrix are ok. But in that case I may need some explanations on how to compute the absolute transform and why computeAbsoluteTransforms
is doing it as it does currently (which would be wrong in that case).
[/EDIT]