vec4 to quat conversion

[szabolcsdombi]

Hi,

I was wondering how to convert vec4 to quat using PyGLM.
The quat constructor does not accept vec4 instances so I tried:

 glm.quat(*glm.vec4(1, 2, 3, 4))

the example above obviously producing a bad result due to the quat constructor.
is there a solution to convert quat to vec4 and vec4 to quat using PyGLM?
if not I can make a PR extending the constructor logic. would that be welcome?

thank you

[Zuzu-Typ]

Hey there (:

I'm not exactly sure what behavior you would expect.
From my understanding, quaternions have a scalar (w) and a vector (xyz) part.

I'm guessing what you would expect is the following:

# given x, y, z and w are some numbers
vec = glm.vec4(x, y, z, w)
qua = glm.quat(*vec)
assert qua.x == x
assert qua.y == y
assert qua.z == z
assert qua.w == w

That is not the case however, because vec4s are ordered xyzw and quaternions are ordered w xyz.

Taking that into account, you can happily convert between quat and vec4:

>>> q = glm.quat(1, 2,3,4)
>>> q
quat( 1, 2, 3, 4 )

>>> v = glm.vec4(*q)
>>> v
vec4( 1, 2, 3, 4 )

>>> glm.quat(*v)
quat( 1, 2, 3, 4 )

Though it appears that this is not the behavior you need.
Could you please explain the use case or expected behavior, so I can understand a little better?

Thank you very much!

Cheers
--Zuzu_Typ--

[szabolcsdombi]

My use case involves compressing and decompressing quaternions.

my quaternion value is the result of vec3 and vec4 operations and right now i have to cast the vec4 to quat with glm.quat(*vec.wxyz)

I think it would make sens to support glm.quat(vec).

I am not expecting the following to work.

# given x, y, z and w are some numbers
vec = glm.vec4(x, y, z, w)
qua = glm.quat(*vec)
assert qua.x == x
assert qua.y == y
assert qua.z == z
assert qua.w == w

i know the "bad" quaternion parameter order is there in glm too and it should not be changed.
instead i would like to be able to cast vec to quat the way i explained above.

[Zuzu-Typ]

right now i have to cast the vec4 to quat with glm.quat(*vec.wxyz)

Yeah, that's sort of what I expected.
And if I recall correctly, there is no (easy) way to do this the other way around (i.e. from quat to vec4).

About the code snippet, I think I messed up explaining what I wanted to know.
What I meant to ask was if your expected behavior would be that when converting between vec4 and quat, x would correspond to x, y would correspond to y, z would correspond to z and w would correspond to w.
That is what you need right?

Okay, so I'm not sure about using the constructor glm.quat(vec4) for this purpose, because I would expect some sort of actual conversion behind it. But perhaps that's just me.
I'm thinking about using a dedicated function for converting from quat to vec4 and back.
Do you think maybe such a function (or rather two functions) would be too inconvenient..?

Thanks for your input!

[szabolcsdombi]

an explicit function call instead of the ambiguous constructor call would be a great idea.

i expect the quat_to_vec4 and vec4_to_quat to do the mapping right (x=x, y=y, z=z, w=w)

[Zuzu-Typ]

This PR should do the trick (:

I'm a little busy at the moment so I couldn't really do much testing. I believe this works as intended though.

[szabolcsdombi]

I get back with testing results :) thank you very much

[szabolcsdombi]

Visually the result seems to be correct.

https://github.com/szabolcsdombi/zengl/blob/0ae8c8e19fd31b71690dec5ab60d0edb7282bf34/examples/crate.py#L114-L127

However I have noticed a small bug with the memory layout of quat when converted to bytes:

https://github.com/szabolcsdombi/zengl/blob/0ae8c8e19fd31b71690dec5ab60d0edb7282bf34/examples/crate.py#L149-L150

The memory layout is w, x, y, z. I remember glm had x, y, z, w as layout. (i must check)

For now i can use another quat_to_vec4:

szabolcsdombi/zengl@ecf047d

[Zuzu-Typ]

Need to add documentation and need to check the possible bug

[SpecLad]

Type stubs for the new functions are also missing.