Remix.run Logo
dxuh 7 hours ago

I agree that use of trigonometry is almost always a smell, but e.g. in games there are so many cases where angles are just more useful and intuitive. I just grep-ed for "angle" in a game of mine and I find it for orienting billboard particles (esp. for particles a single angle is much better than a quat for example). Also for an FPS camera controller. It's much simpler to just store a pitch and a yaw and change that with mouse movement, than storing a quat. You can't really look at a quat and know what kind of rotation it represents without opening a calculator. And I also use it for angle "fudging" so if you want to interact with something if you are roughly looking at it, you need to configure an angle range that should be allowed. It just makes sense to configure this as an angle, because we have some intuition for angles. So I guess for computations angles are probably usually wrong, but they are great for intuition (they are low-dimensional and linear in amount of rotation). That makes them a better human interface for rotations. And as soon as you computations start with angles, of course they find their way into the rest of the code.

hrmtst93837 5 hours ago | parent | next [-]

Storing pitch and yaw breaks down once you want arbitrary camera rolls, or if you need to interpolate between orientations, because of gimbal lock. Using angles for small UI bits or flat objects is fine, but when those billboard particles need more than one axis of freedom, you usually end up needing quats anyway. Quats are opaque, but conversion functions and debug views help when you actually need to read what's going on. Trig shortcuts mostly pay off for simple or highly constrained motion, but scaling them up tends to introduce messy edge cases.

bob1029 3 hours ago | parent | next [-]

Quaternions break down for other situations. They cannot represent a rotation greater than 360 degrees. In an engine like Unity (which stores rotation as quats), you can use arbitrary Euler angles in the editor and it will work fine, but the scene file has to store 2 things. There is an additional m_LocalEulerAnglesHint property that covers this edge case.

the__alchemist 2 hours ago | parent [-]

You're right that quaternions don't work for those. Vec3 is the move IMO. Direction is axis; len is magnitude.

nananana9 5 hours ago | parent | prev [-]

I'd pretty much always store pitch/yaw for a first/third person controller. This makes it trivial to modify the values in response to input - `pitch += mouse_delta.y` and to clamp the pitch to a sane range (-90 to 90 deg) afterwards.

You can then calculate a quaternion from the pitch/yaw and do whatever additional transforms you wish (e.g. temporary rotation for recoil, or roll when peeking around a corner).

the__alchemist 2 hours ago | parent [-]

Interesting. I do it in quaternion, but mostly work in unclamped 6DOF systems.

eska 6 hours ago | parent | prev [-]

Now, don't get me wrong. Trigonometry is convenient and necessary for data input and for feeding the larger algorithm.