- 編集済み
Unity bone rotation override inverted
Hi guys,
I have a simple skeleton imported into Unity. I have used the skeleton utility scripts to add an override to a bone that overrides its rotation. I have then made the parent reference a game object that is at the same level in the heirachy as the skeleton utility script named "Rotator".
When I rotate the "Rotator", it is designed to only rotate in the z-axis. This all works with the one issue that the spine model rotates in the opposite direction! All the other values on the transform are zero, so it seems that somewhere, something is flipping the x-axis by 180 degrees in the calculations.
If I manually rotate the spine model bone that has the override script attached, the gizmo's in Unity rotate in the correct direction. When i rotate using the Rotator object, the gizmos rotate in the wrong direction.
Any suggestions why this might be?
I'm using latest Spine and Unity 2019.1.10f1
Here is the default:
Here is rotated via the "Parent Reference" transfom:
And here is rotated directly:
x35mm wroteIf I manually rotate the spine model bone that has the override script attached, the gizmo's in Unity rotate in the correct direction. When i rotate using the Rotator object, the gizmos rotate in the wrong direction.
Any suggestions why this might be?
This is happening because the parentReference is not designed to act as a "copy this rotation" object, but (as the name suggests) as a parent point of reference.
Long story: It can be seen as if you calibrated a kitchen scale to e.g. 45 grams via the "zero" button - if you then put a total weight of 85 grams on it, it will subtract the reference 45 and result in displayed 40 grams. If you now put nothing on the scale, it will display -45 grams. The -X degrees you receive are the result of moving the reference-angle around.
In short: don't use parentReference, use e.g. a simple script to just copy the rotation values over.
Ah makes sense, thanks for clarifying 
I incorrectly assumed that "parent reference" was simply an object reference to a parent transform, not as you explained.
You're welcome .