Why does OpenGL use degrees instead of radians?

Question

The OpenGL designers were never afraid of mathematics, and knowledge of linear algebra is essential for all but the simplest OpenGL applications. I think it can safely be assumed that OpenGL programmers are familiar with angles in radians.

Mathematically, radians are more elegant than degrees in every respect. They also have practical advantages:

• The C standard library uses radians.
• Pretty much any other library out there uses radians as well.
• Radians are more convenient in some computations, e.g. the length of a circular arc.

Why, then, did the OpenGL designers decide to specify functions like glRotatef and gluPerspective to use degrees?

(I know it's of no practical importance, and it's not going to change anyway. I'm just curious, and I couldn't find the answer on OpenGL.org.)

Answer 1

Because normal people are more used to calculating degrees -- OpenGL is meant to be used simple. Note that all the functions that operate on degrees are "high level" functions.

For OpenGL itself, it's no difference whether it receives radians or degrees -- they are internally converted to transformation matrices anyway, so there's no computational gain of using one or the other.

So why complicate stuff for people if you can allow them using degrees? Anyone coding seriously in OpenGL will provide their own matrices computated from quaternions anyway.

In the same spirit we could ask, why have glRotatef and gluPerspective anyway, since matrices are more elegant in every respect, and allow a higher grade of control.

Point by point:

• Elegancy - matrices are more elegant in every aspect
• C library - C library uses them because of computational reasons, GL functions taking angles are not meant to be used for computational heavy tasks (use matrices directly), and probably the implementation has a lookup table for degrees anyway.
• any other library - following C library for the same reasons as Clib -- also, it's untrue -- many C++ libraries allow a choice, some use the latter
• Computation conviniency - doesn't matter -- internal representation is matrices, calculations probablye done using lookup tables if meant to be efficient -- there's no direct operation on angles, so representation doesn't matter

Also note: all of the functions using degrees are in the current standard (3.2) deprecated. glRotatef is the only function taking degrees, or as a matter of fact, an angle at all. glu is a utility library not meant for heavy-duty deployment, hence it's tailored towards readability, and gluPerspective(... 60.0f..) is much more readable and "standard" in terms of supplying FOV than gluPerspective( ... M_PI / 3.0f ... ) would be.

Final notes: