It might work. But what is GUARANTEED to work is to keep the angle as a private field and just add to it each time or create a Quaternion.fromAngles( 0, time, 0) and multiply it by the existing quaternion.
You make a lot of assumptions doing it the way you are… for one, it assumes that the other two eulers are always 0. For another, it assumes that toAngles() will produce the same results that were passed to fromAngles(). This is probably true for the y-axis but is definitely not guaranteed to be true for the other axes.
A set of Euler angles will produce exactly one Quaternion… but one Quaternion can produce a potentially large number of Euler angle sets. It’s dangerous to assume that you will get out what you put in and it will be confusing later if something else changes that causes odd behavior.
Just as an academic example of what I’m talking about, think of a quaternion that represents Euler angles: 0, 90, 90. Then think of a quaternion that represents -90, 0, 90. These are the same quaternion. (Not exactly sure about the - on the x-axis but my point should be clear.) This same reordering can happen with many kinds of combinations if all three axes are in play. If you mange gimbal lock then an infinite number of Euler angle sets can produce the same Quaternion. Euler angles are not as exact as a Quaternion at representing an orientation… so you cannot expect them to always be reciprocal.
1 Like