41
\$\begingroup\$

I've been looking up the definition of radians and found out that mathematicians prefer them because they are derived from pi instead of being completely arbitrary like degrees.

However, I have not found a compelling reason to use them in game development, possibly due to my complete lack of related mathematical understanding. I know that most sin/cos/tan functions in languages what radians, but someone could just as well create library functions in degrees (and avoid the inherent rounding errors when using pi).

I don't want this to be an opinionated poll, I would just like to hear from people that have done game development (and the associated math research) where radians offer a superior experience over degrees, as opposed to "We're using radians because we always used them", just for the sake of helping me (and possibly others) to understand what they are good for.

\$\endgroup\$
1
  • 2
    \$\begingroup\$ One answer is that they are faster. You dont have to covert degrees to radians before using them in functions like sin. I should be more specific and say that one method of computing sin(x) is using a Taylor expansion - and "x" needs to be in radians for the expansion. \$\endgroup\$ Dec 24, 2013 at 0:42

4 Answers 4

53
\$\begingroup\$

Radians are used in math because

  1. They measure arc-length on the circle, i.e. an arc of angle theta on a circle of radius r is just r * theta (as opposed to pi/180 * r * theta).
  2. When trig functions are defined in terms of radians, they obey simpler relationships between each other, such as cosine being the derivative of sine, or sin(x) ~= x for small x. If defined in terms of degrees, the derivative of sine would be pi/180 * cosine, and we'd have sin(x) ~= pi/180 * x for small x.

It's not that mathematicians just like pi. Radians are actually a more natural choice of angle measure than degrees, for the above reasons. They are the angle measure in which factors like pi/180 disappear.

So IMO, the question is not "why use radians", but "why not use radians". In other words, one doesn't need a reason to use radians; they are the default choice of angle measure. One needs a reason to use degrees. For example one might choose to show angles in degrees in the user interface of an app, because they're more familiar to many people (especially artists). However, personally I've gotten quite used to thinking about angles in terms of radians rather than degrees.

I don't have any specific gamedev examples to give you because this isn't really a gamedev issue, but a mathematical one, and would be the same in any field that uses math.

(By the way, there are no more "inherent rounding errors when using pi" than when using degrees...angles should always be real numbers, not integers, else how are you going to represent an angle of half a degree? :))

\$\endgroup\$
10
  • 4
    \$\begingroup\$ Agreed with the above. I will add that I once saw a game library that used its own standard, based on 256ths of a circle. The reason seemed to be that their trig functions used a lookup table with 256 entries and interpolated between them. If you're not doing that, but calculating sin/cos/tan from their series expansions, or using FSIN/FCOS instructions on an FPU (most typical), those will both expect an input in radians - so you save a conversion by keeping it in radians throughout. \$\endgroup\$
    – DMGregory
    Dec 22, 2013 at 7:11
  • 11
    \$\begingroup\$ "why not use radians" - I'm willing to bet the only good answer there is "because 4th grade homework would be a nightmare with radians" which is likely the only reason any of us even ever heard of degrees. :) \$\endgroup\$ Dec 22, 2013 at 8:21
  • 6
    \$\begingroup\$ @SeanMiddleditch 4th grade classes must migrate to Tau. Tau is the radian version of 360. It streamlines the math and professionals must also start adopting it. \$\endgroup\$
    – Val
    Dec 23, 2013 at 12:30
  • 2
    \$\begingroup\$ 256ths of a circle or 16384ths of a circle means you can use unsigned bytes or 16bit numbers respectively, and the overflows / underflows of adding / subtracting do the right thing. With radians, you probably end up using floating point, which means you get more precision the closer your angle is to zero, and less as it moves away, which is kind of useless / silly most of the time. \$\endgroup\$
    – rjmunro
    Dec 23, 2013 at 12:52
  • 2
    \$\begingroup\$ @Val: Tau doesn't solve the same problems degrees do. Degrees make it easy to measure relatively small angles with integral numbers. This is important when trying to teach early geometry when the students are still doing everything by hand and aren't very comfortable with fractions. Consider the usual "clock hand angle" problems students are given and how those cleanly map to degrees but not Pi/Tau radians. This is similar to the reason degrees were at one point popular in games: using a lookup table of degrees was easier/faster (back then) and gave "good enough" resolution for their needs. \$\endgroup\$ Dec 23, 2013 at 18:35
5
\$\begingroup\$

Nathan's answer is very concrete. I'd like to supply a more general view:

The most complex mathematical concept that is natively implemented in most processing units are floating point numbers as models for the field of real numbers ℝ. Visual geometriy is based on the three dimensional real vector space ℝ³. Coordinates are real numbers. Geometric quantities are based on the length, which is a real multiple of a unit.

Because of this base in real numbers and lengths, it is practical to also model angles by real numbers resp. lengths. Radians is the length of the arc of a unit circle with the given angle. Thus it is the model of an angle most compatible with all these other units based on real numbers resp. lengths. For example, the approximation sin x ~ x for small values of x is an approximation of the y-coordinate of a point on the unit circle by the arc from the x-axis to that point.

One should not forget, that an angle is not a length. It is one of the 4 parts of a plane created by two intersecting straight lines. It's quantity is bounded by the symmetriy of planes in ℝ³ and the euclidean metric.

It is more natural to model an angle by the semiopen interval [0,1) (or (0,1] ) glued together at its end points, given the value of an angle as part of a full turn. Degrees are just 1/360 of a full turn. (BTW: Number theoretically, this is a better choice than the decimal system used for real numbers.)

\$\endgroup\$
0
\$\begingroup\$

While I use radians too, for all the reasons specified, there's at least one good reason why degrees are preferred: Precision and accumulation of errors. Rotating through a full circle 1 degree at a time is exact. Rotating through a full circle 2PI/360 radians at a time is not. Performing a 90 degree rotation 4 times on a pixel grid gets you back to exactly where you started. Performing a 2PI/4 radian rotation on a pixel grid 4 times does not.

\$\endgroup\$
6
  • \$\begingroup\$ Testing this empirically, after four 90-degree rotations with a single precision float increment in radians, I find a total error of 1.75E-7 (less than 1 part in 5 million). On a pixel grid, the radius of the rotating object/frame would need to be in the millions of pixels before you would experience 1 pixel of error at the outer edge (a point more than 0.5 linear px from where it should be). In other words, precision loss is unlikely to be an issue in practice (especially if you use doubles). \$\endgroup\$
    – DMGregory
    Dec 23, 2013 at 20:15
  • \$\begingroup\$ From a numerical perspective you're correct, but from a visual perspective if ONE pixel from a hard edge pops to the wrong value, you're screwed. \$\endgroup\$
    – ddyer
    Dec 23, 2013 at 23:05
  • \$\begingroup\$ See the "millions of pixels" note above. For sprites of typical sizes (say, on the order of 2048 pixels wide, or smaller) the error will be substantially less than half a pixel, and so will be erased by the inherent rounding of the pixel grid itself. Also, note that rotating 360/7 degrees at a time will accumulate the very same errors. You can eliminate rounding errors with both systems by sticking to increments that are representable as a sum of powers of two (with some limit on the exponent range), but it's probably easier to change to code that doesn't accumulate many small increments. \$\endgroup\$
    – DMGregory
    Dec 23, 2013 at 23:47
  • \$\begingroup\$ @DMGregory That was what I meant with "inherent rounding error with Pi". The other option is to not use singles/doubles but a way to represent numbers as factors (so representing 2*pi/360 not as the result of the calculation but as that formula) and only calculate the result when needed. I don't know if any "real" programs do that, but stuff like Mathematica can always represent "1/3" as "1/3" instead of "0.333333.....". But after going through the numbers I guess you're right, the rounding error is there but insignificant \$\endgroup\$
    – Michael Stum
    Dec 24, 2013 at 3:34
  • 3
    \$\begingroup\$ An angle of 1 degree may be easier to represent accurately in degrees than in radians, rotating an object isn't exact either way, as it requires trigonometrical functions. cos 1° is as much subject to rounding errors as pi/180. \$\endgroup\$ Dec 24, 2013 at 10:59
-3
\$\begingroup\$

Let's agree, that it is better to choose any and stick to it than using two definitions und a little guessing which one of them is necessary for the current function. Then using arc length is more natural for the implementation of sin and cos which might be a reason for cmath to implement it that way. Since games are often written in C++ or C and there is already sin and cos implemented it makes sense to stick to that definition.

[Screw you legacy opengl]

\$\endgroup\$
1
  • \$\begingroup\$ This is not really answering the question. Did you mean to comment on another answer instead? \$\endgroup\$
    – user1430
    Jan 20, 2014 at 1:35

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .