Hacker News Reader

Comment by pcwalton | Hacker News Reader

> For some reason I can't quite put my finger on, some experienced game programmers are reluctant to use atan2() and prefer the dot product.

It's because atan2, along with all the other inverse trigonometric functions, is incredibly slow. On a GPU, sin and cos may be a couple of cycles, but asin/acos/atan/atan2 may be upwards of 30 or 40.

Often times, angles are best avoided when possible for this reason. Normalized vectors end up faster and simpler in many cases.

Relevant anecdote: I recently wrote some code to compute normals in 2D and thought I would be clever by encoding the normal as an angle to save space. It turned out that the atan2 call at the end was so slow that it outweighed the cost of everything else I was doing several times over. Lesson learned…

View on HN

Yeah, there are multiple reasons. Perf is important: inverse trig functions are generally much slower both on the CPU and on the GPU [1]

But also - most of the time gamedev happens in 3D space not in 2D space (even if it gets rendered down to 2D). So it's more natural to do a dot product of two 3d vectors, than try to mess around with trig functions that work on scalar angles. Same with rotations: it's easier and better to use quaternions in 3D space than try to rotate along each axis separately.

[1] GPU intrinsic estimated costs: http://www.fractalforums.com/programming/shader-function-or-...

Quaternions have a bunch of properties that make them awesome:

* Compact storage compared to matrices

* No gimbal-lock

* Multiplication is cheap (mult + add, very similar to vector operations)

* Interpolation is cheap

You really only pay the sin/cos costs when translating out to a Mat3x3 at the end.

> You really only pay the sin/cos costs when translating out to a Mat3x3 at the end.

You don’t need sin/cos for that either.

Here’s a code that does that:

https://github.com/Microsoft/DirectXMath/blob/master/Inc/Dir...

You're right, I was mixing that up with the initial conversion from axis+angle to quaternion.

Until you need to differentiate a quaternion ...

Also, you don't pay the sin/cos costs when converting to a rotation matrix. For angle axis

  R = I + (sin x) * S + (1 - cos(x)) * S^2

Where S is the 3x3 skew symmetric matrix.

A unit quaternion representing a 3D rotation is sort of like angle axis

  q = cos(x/2), sin(x/2) <axis>

But

  sin(x)    = 2*cos(x/2)*sin(x/2)
  (1-cos(x) = 2*sin(x/2)*sin(x/2)

Where you pay the cost is in the construction of the quaternion.

What is the problem with differentiating a quaternion? E.g. the time derivative of the quaternion w.r.t. a fixed angular velocity is given here: https://fgiesen.wordpress.com/2012/08/24/quaternion-differen... .

I've more often encountered the need to integrate a quaternion, e.g. from inertial measurements or a rigid body physics model, but this is also a textbook lookup away.

In other words...there is no atan3().

All triangles are 2d. Using atan2 to find the angle between 3d vectors would require projection onto an orthonormal basis.

atan2 requires this even in 2d, we just assume the natural basis and assume the other vector is x hat.

Dot product avoids all this in any dimension.

Just as atan2() returns 1 angle (XY), atan3() would return 2 angles (XY, XZ).

I agree dot product is often better, for other reasons.

I don't follow what this hypothetical atan3 implements?

> 1/x, sin(x), cos(x), log2(x), exp2(x), 1/sqrt(x) - 0 or close to 0, as long as they are limited to 1/9 of all total ops (can go up to 1/5 for Maxwell).

This is what surprised me to learn recently, that some transcendentals are free, as long as you don't use too many of them.

I also think the dot product and other vector operations are more naturally the thing you're actually trying to do in the end. We generally start with a vector (say a movement command to take our unit to a certain location) and want to end up with a vector (acceleration to apply) so going through angles as the intermediate step makes little sense logically. This is true even in 2D and without speed constraints. Moreover, angles often leave you with a tricky case to handle where you are going "over 360 degrees"and there is an unnatural discontinue discontinuity.

relevant, in case anyone needs it: https://geekshavefeelings.com/posts/fixed-point-atan2

Exactly. And if you understand what you’re doing, you can avoid referencing the angle explicitly. Because macro arc length is rarely needed.

Reply on news.ycombinator.com