search

go-gl / mathgl

A pure Go 3D math library.
BSD 3-Clause "New" or "Revised" License
554 stars 65 forks source link

Radians vs Degrees #14

Closed UserAB1236872 closed 10 years ago

UserAB1236872 commented 10 years ago

I was just testing some quaternion functions and hit a brick wall: my simple test case was failing!

I mean, it checked out against every other in-program method of computing the rotation, but not my hand computed one. My inkling was to check the source. Yup, QuatRotate and HomogRotate3D use degrees.

It seems like the package is split between degrees and radians, with some functions taking one and some taking another. I think I chose degrees on the methods I did because both GLM and the deprecated OpenGL functions used degrees.

Is there a preference on this? Personally, I prefer radians simply because that's what the math package likes. I don't think degrees are THAT much more intuitive to work with, and it's not a huge deal to make a DegToRad utility function anyway, but I don't want to shake things up too much without input.

pwaller commented 10 years ago

As a physicist, I have a strong preference for radians.

pwaller commented 10 years ago

(But that is just my 2c and my opinion doesn't count for everything :smile:)

dmitshur commented 10 years ago

I prefer radians. But much more than that, I prefer consistency.

UserAB1236872 commented 10 years ago

Resolved: the package now always uses radians. This was especially jarring where constructing a an Angle/Axis rotation matrix and constructing an Angle/Axis quaternion used different units...

I ultimately decided on radians because:

  1. The math package uses radians. This means that if you take degrees you have to convert to radians anyway, but what's especially bad is that if you use radians you have to convert TO degrees and then the function will convert BACK.
  2. I'm more likely to write functions to use radians, so I don't have to remember to use degrees.
  3. The functions to convert are trivial anyway, and are provided with the package.
  4. Everyone who commented prefers radians.

There is a small snag in that now the library doesn't match most 3D math libraries' (esp. GLM/OpenGL's) convention of using degrees, but oh well.