Page 1 of 1

Quaternion issue

Posted: Tue Jul 23, 2019 1:09 pm
by Maci
Hi all,
I have the following code fragment;

Code: Select all

            var body = new BodyReference(BodyHandle, characters.Simulation.Bodies);
            ref var pose = ref body.Pose;
            pose.Orientation = Quaternion.CreateFromYawPitchRoll(input.CameraAngle, 0, 0);
            Quaternion.TransformUnitZ(pose.Orientation, out var viewDirection);
            Quaternion.GetAxisAngleFromQuaternion(pose.Orientation, out var axis, out var angle);
            Console.WriteLine($"CS:{input.CameraAngle} VD:{viewDirection} A:{axis} ANGLE:{angle}");
I get the following sample output:
CS:90.15236 VD:<0.8156362, 0, -0.5785651> A:<0, 1, 0> ANGLE:2.187765
CS:96.18495 VD:<0.9336317, 0, -0.3582342> A:<0, 1, 0> ANGLE:1.937172
CS:128.3905 VD:<0.4029752, 0, -0.9152108> A:<0, 1, 0> ANGLE:2.726827
CS:144.3713 VD:<-0.1414784, 0, 0.9899414> A:<0, -1, 0> ANGLE:0.1419543

Why is my angle variable wildly different from input.CameraAngle? If I create a Quaternion using CreateFromYawPitchRoll() and then invoke Quaternion.GetAxisAngleFromQuaternion() shouldn't I get the same numbers?
I'm confused...

Maci

Re: Quaternion issue

Posted: Tue Jul 23, 2019 10:32 pm
by Norbo
Orientation quaternions don't distinguish between 2 * PI and 164 * PI, since they correspond to the same orientation. It's also worth noting that all angles are in terms of radians, not degrees.

Note that (128.3905 % PI) ~= 2.726827.

Re: Quaternion issue

Posted: Wed Jul 24, 2019 7:08 am
by Maci
I had completely missed that angles were in radians...
Shame on me...

Maci

Re: Quaternion issue

Posted: Wed Jul 24, 2019 9:19 pm
by Norbo
It's okay, you're not the first, nor will you be the last :P

Re: Quaternion issue

Posted: Mon Dec 23, 2019 1:23 am
by lidgren
Slightly related; what are the reason System.Numerics quaternion isn't used? It's a only a slight nuisance having to convert every time but still...

Re: Quaternion issue

Posted: Mon Dec 23, 2019 1:51 am
by Norbo
It's been a while since that decision was made- originally, there were some concerns about codegen around parameters and a couple of numerical issues, like in slerp corner cases.

It would not surprise me if the codegen concerns are lesser or gone now. There are still some functions not offered in the Numerics type, but that's pretty easy to handle without a full custom name-colliding type. So at this point, it's just because I haven't yet confirmed codegen quality and put in the time to do it.