Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Avoiding Trigonometry (2013)

iquilezles.org

Post reply on HN
Print view View original

11–20 of 92 posts

Re: Avoiding Trigonometry (2013)

#11

Post by the__alchemist »

I think this is more subjective than the author makes it out to be. I take a third approach: You can change out Matrices for Quaternions. Then do almost every operation using these two types, and a few operation between them. The operation implementations are a mix of dot products, quaternion multiplication, trig etc.

I find this flow works well because it's like building arbitrarily complex transformation by composing a few operations, so easy to keep in my head. Or maybe I just got used to it, and the key is find a stick with a pattern you're effective with.

So:

> For example, you are aligning a spaceship to an animation path, by making sure the spaceship's z axis aligns with the path's tangent or direction vector d.

Might be:

  let ship_z = ship.orientation.rotate_vec(Z_AXIS);
  let rotator = Quaternion::from_unit_vecs(ship_z.to_normalized(), path.to_normalized());

  ship.orientation *= rotator;
I should break this down into individual interoperations to compare this to the two examples in the article. To start, `from_unit_vecs` is based on the cross product, and `rotate_vec` is based on quaternion-vector multiplication. So no trig there. But `quaternion::from_axis_angle()` uses sin and cos.

I need to review for the sort of redundant operations it warns about, but from a skim, I'm only using acos for SLERP, and computing dihedral angles, which aren't really the basic building blocks. Not using atan. So maybe OK?

edit: Insight: It appears the use of trig in my code is exclusively for when an angle is part of the concept. If something is only vectors and quaternions, it stays that way. If an angle is introduced, trig occurs. And to the article: For that spaceship alignment example, it doesn't introduce an angle, so no trig. But there are many cases IMO where you want an explicit angle (Think user interactions)

Re: Avoiding Trigonometry (2013)

#12

Post by dxuh »

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.

Re: Avoiding Trigonometry (2013)

#14

Post by 20k »

>poorly designed third party APIs

I think this is missing the reason why these APIs are designed like this: because they're convenient and intuitive

Its rare that this kind of performance matters, or that the minor imprecisions of this kind of code matter at all. While its certainly true that we can write a better composite function, it also means that.. we have to write a completely new function for it

Breaking things up into simple, easy to understand, reusable representations is good. The complex part about this kinds of maths is not the code, its breaking up what you're trying to do into a set of abstracted concepts so that it doesn't turn into a maintenance nightmare

Where this really shows up more obviously is in more real-world library: axis angle rotations are probably a strong type with a lot of useful functions attached to it, to make your life easier. For maths there is always an abstraction penalty, but its usually worth the time saved, because 99.9999% of the time it simply doesn't matter

Add on top of this that this code would be optimised away with -ffast-math, and its not really relevant most of the time. I think everyone goes through this period when they think "lots of this trig is redundant, oh no!", but the software engineering takes priority generally

Re: Avoiding Trigonometry (2013)

#15

Post by aleph_minus_one »

the__alchemist wrote: post #11

I think this is more subjective than the author makes it out to be. I take a third approach: You can change out Matrices for Quaternions. Then do almost every operation using these two types, and a few operation between them. The operation implementations are a mix of dot products, quaternion multiplication, trig etc. I find this flow works well because it's like building arbitrarily complex transformation by composi…

> You can change out Matrices for Quaternions.

Better use spin groups: they work in every dimension.

Re: Avoiding Trigonometry (2013)

#16

Post by eska »

dxuh wrote: post #12

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…

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

Re: Avoiding Trigonometry (2013)

#17

Post by simonreiff »

Nice article! I'm not a graphics programmer but mathematically it makes full sense that cross-product would be a vast optimization over using `sin()`. From a complexity perspective, the computation of a cross-product reduces to calculating a formal determinant, a fixed number of arithmetic operations, and hence resolves to O(1) complexity. By contrast, computing `sin()` is O(M(n)log(n)) (even though faster algorithms are often possible in practice). See Brent, Fast multiple-precision evaluation of elementary functions (1976).

Re: Avoiding Trigonometry (2013)

#18

Post by hrmtst93837 »

dxuh wrote: post #12

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…

[flagged]

Re: Avoiding Trigonometry (2013)

#19

Post by the__alchemist »

aleph_minus_one wrote: post #15
the__alchemist wrote: post #11

I think this is more subjective than the author makes it out to be. I take a third approach: You can change out Matrices for Quaternions. Then do almost every operation using these two types, and a few operation between them. The operation implementations are a mix of dot products, quaternion multiplication, trig etc. I find this flow works well because it's like building arbitrarily complex transformation by composi…

> You can change out Matrices for Quaternions. Better use spin groups: they work in every dimension.

Hah! We can throw bivectors onto the pile too for the fans!

Re: Avoiding Trigonometry (2013)

#20

Post by virgil_disgr4ce »

OK I have a genuine question outside the topic of TFA. Do people really prefer "orientate" over "orient"? This pattern baffles me. You don't get out of the subway and "orientate" yourself, you "orient" yourself.

I mean I'm perfectly aware that language is a descriptive cultural process etc etc but man this bugs the crap out of me for some reason

Post reply on HN