Quat::to_euler outputs bigger than PI * 2 at certain angles about glam-rs HOT 13 CLOSED

Hey, I haven't had a chance to look at this.

The euler conversion code was contributed by someone so I unfortunately don't have any additional insight into how it works.

Prior to that being contributed I was actually planning on adopting a solution from another more mature math library. I may still do that. In any case I'll try look at why this is happening before taking the nuclear option.

from glam-rs.

It appears that these results are coming from change to the Euler conversion code to fix another issue, this if block in particular https://github.com/bitshifter/glam-rs/blob/main/src/euler.rs#L81-L92.

The original conversion code was contributed and based on a code listing from this blog post https://web.archive.org/web/20210506232447/http://bediyap.com/programming/convert-quaternion-to-euler-rotations/. That post doesn't have any background on where it came from.

Prior to this being contributed I was planning to implement something based on https://github.com/AcademySoftwareFoundation/Imath/blob/main/src/Imath/ImathEuler.h

The Imath code is based on this paper from Graphics Gems IV:

Shoemake, Ken, Euler Angle Conversion, p. 222-229, code: p. 225-228, euler_angle/.

There have been a few issues around the Euler conversion code and I wonder given its unclear origins if it would be easier to rewrite it using Shoemake's method which appears to be widely used since 1994.

In any case, leaving this here as a reminder for when I have time to look into it more.

from glam-rs.

fixed in #537

from glam-rs.

Awesome! My previous failing case works well now.

from glam-rs.

I wasn't able to repro this with those quaternions:

fn main() {
    dbg!(Quat::from_xyzw(-0.7114118, 0.008691366, 0.7026667, -0.008799534).to_euler(EulerRot::XYZ));
    dbg!(Quat::from_xyzw(0.71146613, -3.0716883e-8, 0.7027204, -3.1099173e-8).to_euler(EulerRot::XYZ));
}

[src/main.rs:91:5] Quat::from_xyzw(-0.7114118, 0.008691366, 0.7026667,
        -0.008799534).to_euler(EulerRot::XYZ) = (
    3.1168556,
    -1.5584388,
    7.5300115e-8,
)
[src/main.rs:92:5] Quat::from_xyzw(0.71146613, -3.0716883e-8, 0.7027204,
        -3.1099173e-8).to_euler(EulerRot::XYZ) = (
    -3.1415925,
    1.5584291,
    -0.0,
)

I was testing on x86_64 so it would be using SSE2, were you seeing this on x86_64 or was it another architecture?

Edit: I just realised I was on a branch that meant sse2 would not be used, so that could be why I didn't see the same thing.
Edit2: Can't repro on main either.

from glam-rs.

@cybersoulK there were some fixes to to_euler that were introduced in 0.24.2 in September 2023, is it possible that you were using an older version of glam when you were seeing this?

from glam-rs.

@bitshifter

I updated my own fork at the time, to make sure it happened in the main.
I ran the same tests you provided, and i get the same values as you, (apple m1 pro) (at the exact same fork that i had the issues in)

I am not sure why, maybe a println is missing some floating numbers? i will investigate further, do you think it's possible some floating numbers might be missing from my initial debug message?

from glam-rs.

so, when i run your tests using the following commit, which was 24.0,
glam = { git = "https://github.com/bitshifter/glam-rs", rev = "249023c06db3796aebba0c75143e042043e2a5c2" }

i still have the correct values, so something else must be at play here

from glam-rs.

Hrm, you weren't using libm or fast-math features?

It could be the printing losing precision, not really sure about that.

from glam-rs.

i don't see these 2 features enabled. I just ran the tests within the same project, to check that, but the output was correct.

Within 1 or 2 days, I should be able to test the same exact scenario in the game, to see if it glitches, and i can capture the Quat values.
Any advice to print them without losing precision?

from glam-rs.

I think debug printing (i.e. "{:?}") should be sufficient, but you can always print more precision if you want to be sure.

I did a little experiment here https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=472f213957510840510e2d5abc92ba07 based on https://randomascii.wordpress.com/2013/02/07/float-precision-revisited-nine-digit-float-portability/ and although you can print more decimals it's still the same float. You could always print as hex to be sure.

from glam-rs.

dbg!(glam::Quat::from_xyzw(0.0, 0.70599556, 0.0, -0.7082163).to_euler(glam::EulerRot::XYZ));
dbg!(glam::Quat::from_xyzw(0.0, 0.70554054, 0.0, -0.7086696).to_euler(glam::EulerRot::XYZ));
dbg!(glam::Quat::from_xyzw(0.0, 0.70813525, 0.0, -0.7060769).to_euler(glam::EulerRot::XYZ));
dbg!(glam::Quat::from_xyzw(0.0, 0.70819116, 0.0, -0.70602083).to_euler(glam::EulerRot::XYZ));

dbg!(glam::Quat::from_xyzw(0.0, -0.70860523, 0.0, -0.7056052).to_euler(glam::EulerRot::XYZ));
dbg!(glam::Quat::from_xyzw(0.0, -0.706111, 0.0, -0.7081012).to_euler(glam::EulerRot::XYZ));

dbg!(glam::Quat::from_xyzw(0.5765686, 0.4102857, -0.5761997, -0.4089355).to_euler(glam::EulerRot::XYZ));

dbg!(glam::Quat::from_xyzw(0.052489556, 0.7064261, -0.053010665, -0.70384437).to_euler(glam::EulerRot::XYZ));

  glam::Quat::from_xyzw(0.052489556, 0.7064261, -0.053010665,
      -0.70384437).to_euler(glam::EulerRot::XYZ) = (
  6.1328373,
  -1.5670617,
  0.0,
)

...

I found these! can you test them in x86?

from glam-rs.

yep, that reproduces the issue on x86_64 as well, thanks!

from glam-rs.