Pixi.js: Rehacer las API que usan radianes para usar grados en su lugar

Algunas desventajas que me vienen a la mente:

• Las funciones matemáticas integradas de JavaScript se estandarizan en radianes
• las funciones glsl incorporadas se estandarizan en radianes
• Los radianes son un formato más conveniente para manejar algunos tipos de cálculos (por ejemplo, puedo leer desde 0-> Math.pi * 2 y obtener una rotación completa en el sentido de las agujas del reloj).

Soy un chico de matemáticas, y prefiero usar grados 0..1 o 0..512 debido a razones de persistencia y formato de sombreado. Si me hicieras la misma pregunta hace dos o más años, podría decir que los radianes son mejores porque son "puros" en su significado matemático.

Sin embargo, almacenar 2 x Math.PI en archivos es un problema (persistencia), y "360" es más rápido de escribir que 2 * PI, no se puede representar claramente en forma binaria.

Los motores basados ​​en flash funcionan principalmente con grados:

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

También editores como Spine trabajan y almacenan ángulos en radianes.

Una cosa más extraña es que usamos SKEW que es cosa de diseñador de gráficos y es simplemente "(shear.y, -shear.x)" en sentido matemático, permitimos tal abominación y forzamos al usuario a usar rads al mismo tiempo.

Su conflicto entre "renderizador de bajo nivel" y "renderizador de gráficos 2d con su propio escenario y soporte de herramientas", y creo que pixi está más cerca del segundo.

@englercj También tengo que trabajar en ese código, ya tengo algo así en mi bifurcación: https://github.com/gameofbombs/gobi/tree/master/src/core/transform
https://github.com/gameofbombs/gobi/blob/master/src/core/math/FlatTransform2d.ts

@mreinstein Tengo que pedir mirar ese código también, ya que sabes algo sobre las transformaciones de pixi;)

Las sugerencias de @bigtimebuddy y @GoodBoyDigital hacen que la API sea configurable:

// useDegrees
CONVERSION = Math.PI / 180;

// useRadiens
CONVERSION = 1;

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

¿Quizás como lo hace Phaser? El ángulo es para grados, la rotación es para radianes.

@englercj De acuerdo. Esa es la forma más sencilla de hacerlo. Los motores basados ​​en pixi pueden simplemente arreglar su constante de "CONVERSIÓN".

@englercj Processing hace esto, y creo que es una decisión de diseño realmente mala. Duele la modularidad. Si tiene un fragmento de código que hace algo de una manera e intenta usar otro fragmento de código (tal vez en una biblioteca) que asume lo contrario, no funcionará. Si se asegura de configurar el modo de unidad antes de cada llamada a una función relacionada con el ángulo, entonces podría garantizar que su código funcione pero romper el código de la biblioteca. Y si hay un fragmento de código de biblioteca que usa ángulos, ¿debería establecer el modo de ángulo? Eso podría garantizar que su código funcione según lo previsto, pero romper el código del usuario. Es casi como el dilema del diseño de API del prisionero.

@OSUblake Eso parece más razonable. Si bien los nombres ángulo y rotación no denotan ni proscriben explícitamente una unidad, definitivamente hay asociaciones allí que hacen que esto sea más razonable que una suposición 50/50.

Sin embargo, creo que angleDeg y angleRad serían mejores. ¿Por qué no hacerlo explícito?

El ángulo es para grados, la rotación es para radianes.

Puede que así sea como lo hace el phaser, pero eso no es un acuerdo universal. la rotación es la acción y el ángulo es la cantidad de esa acción que sucedió. A veces se denomina "ángulo de rotación". Entonces, técnicamente, el ángulo o la rotación podrían sobrecargarse para referirse a lo mismo, y podrían expresarse en cualquier unidad (grados o radianes).

Cualquier operación matemática que involucre rotaciones es mucho más fácil con radianes. Realmente no es tan difícil de entender; Math.PI está en la mitad del círculo; Math.PI * 2 es una rotación completa.

El único momento en que los grados son apropiados es cuando expones una interfaz de usuario visual a personas que implican rotación, y tu audiencia es un grupo que no comprende la geometría básica (es decir, la mayoría de las personas).

Reconozco que esta es una opinión, pero simplemente vaya con radianes. Todas las API de matemáticas en javascript operan en radianes, no en grados, al igual que la mayoría de las bibliotecas de geometría que no son de juguete.

Si realmente debemos apoyar a todos en todo, entonces estoy de acuerdo con @ 1j01 para hacerlo explícito. ¿Quizás .degrees o .radians ?

Este problema se ha marcado automáticamente como obsoleto porque no ha tenido actividad reciente. Se cerrará si no se produce más actividad. Gracias por sus aportaciones.

Este hilo se ha bloqueado automáticamente ya que no ha habido ninguna actividad reciente después de que se cerró. Abra un nuevo problema para errores relacionados.