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.)
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:
I'd say that since OpenGL was designed with the end-user in mind, degrees were used because one can specify important angles (90, 180, 270 ...) with integers only, and so there is no need for a floating point GL_PI constant.
I think it is because you should be able to get an exact rotation matrix for certain angles like 90 or 180 degrees. Like other people here has specified, if you use pi/2 instead of 90 degrees, rounding errors may lead to a transformation matrix that almost performs a rotation by 90 degrees.
Code is easier to read, it eases learning curve for newbies and allows quick hacking.
As stated already - degrees HAVE advantage - humans are better used to degrees, compare: 0.78539816339744830961566084581988... to 45 degrees for example :/.
For advanced uses of OpenGL you provide your own matrices anyway.
Well, what happens in most cases is that you use a Math library to convert from radians to degrees and back to radians. I agree with most of what was said by the previous awesome posters.
It's more human readable.
来源：https://stackoverflow.com/questions/2146884/why-does-opengl-use-degrees-instead-of-radians