rotation timelines: 16384.499999999996

BinaryCats

float r = frames[frame + ROTATION] - prevRotation;
r -= (16384 - (int)(16384.499999999996 - r / 360)) * 360;
r = prevRotation + r * percent;
if (setupPose) {
   r -= (16384 - (int)(16384.499999999996 - r / 360)) * 360;
   bone.rotation = bone.data.rotation + r * alpha;
} else {
   r = bone.data.rotation + r - bone.rotation;
   r -= (16384 - (int)(16384.499999999996 - r / 360)) * 360;
   bone.rotation += r * alpha;
}

After some time with my boss, scratching our heads, this is pretty neat code for wrapping angles!

although... :punch:

I feel less happy about our solution to clamping the angles after alpha.

We had a problem long ago, where because of increasing bone rotations, and turning IK's on and off, Bones controlled by IK's would spine around when turning the IK on. This is due to the, bone.rotation += r * alpha as if bone.rotation = 179 and r = 180 and alpha = 1, bone.rotation can increase past the -180, 180 limits.

To stop this we did the following code at the end of the apply function in rotation timeline:

//ADDED
            float amount = bone.rotation;
            while (amount > 180)
                amount -= 360;
            while (amount < -180)
                amount += 360;
            bone.rotation = amount;
            //ADDED

which would wrap the rotation of the bone again.

above code still works, but I'm unsure of the maths to put it in your new fancy calculation.

I thought it might be something like:

bone.rotation -= (16384 - (int)(16384.499999999996 - bone.rotation / 360)) * 360;

is this correct (its a little hard to see if it is)

[/i]

17 Nov 2016, 12:30

(and that 16384.499999999996 really needs to be defined, because people reading this in a chat room where I posted it are yelling at me)

Nate

This code:

r -= (16384 - (int)(16384.499999999996 - r / 360)) * 360;

Is equivalent to:

while (r > 180)
   r -= 360;
while (r < -180)
   r += 360;

It works by subtracting the number of 360 degree rotations in r. It is certainly cryptic, but it's nice to do it without branching and it's in the runtime internals. A constant wouldn't make it any less cryptic.

I'd like to better understand the problem you are solving by adding another rotation wrap. When exactly is it needed?

BinaryCats

It is an old issue, which may have been solved. which was first explained here.

But, imagine you have an IK turned off, and you are keying the rotation of a bone in animations.

initial bone.rotation = 0

1) r comes through the timeline and is wrapped to -180,180, r=179
2) The line :
bone.rotation += r * alpha;
Sets bone.rotation = 179
3)repeat 10 times,

bone.rotation is now 1790, way outside -180,180.

When the IK is keyed on, the bone needs to rotate to that position, say 0'. So it will rotate around almost 5 times, to set its rotation to 0.

Our solution was to wrap the final bone position to -180,180

17 Nov 2016, 14:26

also, apparently

r -= (16384 - (int)(16384.499999999996 - r / 360)) * 360;

can be simplified to:

r += Mathf.Floor(0.5f - r * (1.0f / 360)) * 360.0f;

Nate

The point of the int cast is to avoid ceil (or floor) within a reasonable range (-(2^14) to max - 2^14). Your alternate form looks fine, or use:

r -= ceil(r / 360 - 0.5f) * 360;

I'll try to repro multiple rotations when mixing IK in.

BinaryCats

Ill see if I can dig up an old repo too, I cant quite rember if it was single bone ik's or double bone ik's

Pharan

Also use Math instead of Mathf in the spine-csharp classes. Mathf is a UnityEngine class.