Rework APIs that use radians to use degrees instead

[englercj]

Stated benefits:

• Easier to use end-user API
• Easier to reason about and read user-code
• Easier to persist degree values rather than radian values
• More consistent with other web-based, and other 2D engines

[mreinstein]

A few cons that come to mind:

• built-in javascript math functions standardize on radians
• built-in glsl functions standardize on radians
• radians are a more convenient format for dealing with some types of computations (e.g., I can lerp from 0-> Math.pi * 2 and get a full rotation clockwise.)

[ivanpopelyshev]

I'm math guy, and I prefer to use either degrees either 0..1 either 0..512 because of persistance and shader format reasons. If you asked me same question two or more years ago I could say that radians are better because they are "pure" in math meaning.

However, storing 2 x Math.PI in files is a problem (persistance), and "360" is just faster to write than 2*PI, it cant be represented clearly in binary form.

Flash-based engines are working moslty with degrees:

https://libgdx.badlogicgames.com/nightlies/docs/api/com/badlogic/gdx/graphics/g2d/Sprite.html#getRotation--

http://cocos2d-x.org/docs/programmers-guide/sprites/index.html

http://help.adobe.com/en_US/ActionScript/3.0_ProgrammingAS3/WS5b3ccc516d4fbf351e63e3d118a9b90204-7def.html

https://www.youtube.com/watch?v=zAsDbHXlFWI

Also editors like Spine work and store angles in radians.

One more strange thing is that we use SKEW which is graphics designer thing and is just "(shear.y , -shear.x)" in math sense, we allow such a abomination and force user to use rads at the same time.

Its conflict between "low-level renderer" and "2d graphics renderer with its own stage and tools support", and I think pixi is closer to the second.

[ivanpopelyshev]

@englercj I have to work at that code too, I already have something like that in my fork: https://github.com/gameofbombs/gobi/tree/master/src/core/transform
https://github.com/gameofbombs/gobi/blob/master/src/core/math/FlatTransform2d.ts

@mreinstein I have to ask to look at that code too since you know something about pixi transforms ;)

[englercj]

Suggestions from @bigtimebuddy & @GoodBoyDigital, make the API configurable:

// useDegrees
CONVERSION = Math.PI / 180;

// useRadiens
CONVERSION = 1;

set rotation(rot)
{
    this._rotation = rot * CONVERSION;
}

[OSUblake]

Maybe like Phaser does it? Angle is for degrees, rotation is for radians.

[ivanpopelyshev]

@englercj Agree. That's the simplest way there. Engines based on pixi can just fix their "CONVERSION" constant.

[1j01]

@englercj Processing does this, and I think it's a really bad design decision. It hurts modularity. If you have one piece of code that does something one way and try to use another piece of code (maybe in a library) that assumes the other way, it won't work. If you make sure to set the unit mode before every call to an angle-related function, then it might ensure your code works but break the library code. And if there's a piece of library code that uses angles, should it set the angle mode? That might guarantee its code works as intended but break the user's code. It's almost like the Prisoner's Dilemma of API design.

@OSUblake That seems more reasonable. While the names angle and rotation don't explicitly denote or proscribe a unit, there's definitely associations there that make this more reasonable than like a 50/50 guess.

I think angleDeg and angleRad would be better though. Why not make it explicit?

[mreinstein]

Angle is for degrees, rotation is for radians.

That may be how phaser does it but that's not universally agreed upon. rotation is the action, and angle is the amount of that action that happened. Sometimes referred to as "angle of rotation". So technically angle or rotation could be overloaded to refer to the same thing, and could be expressed in either unit (degrees or radians.)

Any math operations involving rotations is much easier with radians. It's really not that hard to grasp; Math.PI is halfway around the circle; Math.PI * 2 is a full rotation.

The only time degrees is appropriate is when you're exposing a visual user interface to people that involves rotation, and your audience is a group that doesn't understand basic geometry (i.e., most people.)

I recognize this is opinion but just go with radians. All of the Math APIs in javascript operate on radians, not degrees, as do most non-toy geometry libraries.

If we really must support everyone for everything then I agree with @1j01 to make it explicit. Maybe .degrees or .radians ?

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.