Pixi.js: Retravailler les API qui utilisent des radians pour utiliser des degrés à la place

Quelques inconvénients qui me viennent à l'esprit :

• les fonctions mathématiques javascript intégrées se normalisent sur les radians
• les fonctions glsl intégrées standardisent sur les radians
• les radians sont un format plus pratique pour traiter certains types de calculs (par exemple, je peux lerp de 0-> Math.pi * 2 et obtenir une rotation complète dans le sens des aiguilles d'une montre.)

Je suis un mathématicien et je préfère utiliser les degrés 0..1 ou 0..512 pour des raisons de persistance et de format de shader. Si vous m'avez posé la même question il y a deux ans ou plus, je pourrais dire que les radians sont meilleurs parce qu'ils sont "purs" au sens mathématique.

Cependant, stocker 2 x Math.PI dans des fichiers est un problème (persistance), et "360" est juste plus rapide à écrire que 2*PI, il ne peut pas être représenté clairement sous forme binaire.

Les moteurs basés sur Flash fonctionnent principalement avec des degrés :

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

De plus, des éditeurs comme Spine travaillent et stockent les angles en radians.

Une autre chose étrange est que nous utilisons SKEW qui est une chose de graphiste et qui est juste "(shear.y , -shear.x)" au sens mathématique, nous autorisons une telle abomination et forçons l'utilisateur à utiliser des rads en même temps.

Son conflit entre le « rendu de bas niveau » et le « rendu graphique 2D avec son propre support de scène et d'outils », et je pense que pixi est plus proche du second.

@englercj Je dois aussi travailler sur ce code, j'ai déjà quelque chose comme ça dans mon fork : https://github.com/gameofbombs/gobi/tree/master/src/core/transform
https://github.com/gameofbombs/gobi/blob/master/src/core/math/FlatTransform2d.ts

@mreinstein, je dois demander à regarder ce code aussi puisque vous savez quelque chose sur les transformations pixi ;)

Les suggestions de @bigtimebuddy & @GoodBoyDigital , rendent l'API configurable :

// useDegrees
CONVERSION = Math.PI / 180;

// useRadiens
CONVERSION = 1;

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

Peut-être comme Phaser le fait ? L'angle est pour les degrés, la rotation est pour les radians.

@englercj D'accord. C'est le moyen le plus simple. Les moteurs basés sur pixi peuvent juste fixer leur constante "CONVERSION".

@englercj Processing fait cela, et je pense que c'est une très mauvaise décision de conception. Ça fait mal à la modularité. Si vous avez un morceau de code qui fait quelque chose dans un sens et que vous essayez d'utiliser un autre morceau de code (peut-être dans une bibliothèque) qui suppose l'autre sens, cela ne fonctionnera pas. Si vous vous assurez de définir le mode unité avant chaque appel à une fonction liée à l'angle, cela peut garantir que votre code fonctionne mais casser le code de la bibliothèque. Et s'il existe un morceau de code de bibliothèque qui utilise des angles, doit-il définir le mode d'angle ? Cela pourrait garantir que son code fonctionne comme prévu, mais casser le code de l'utilisateur. C'est presque comme le dilemme du prisonnier de la conception d'API.

@OSUblake Cela semble plus raisonnable. Bien que les noms angle et rotation ne désignent pas ou ne proscrivent pas explicitement une unité, il existe certainement des associations qui rendent cela plus raisonnable qu'une estimation 50/50.

Je pense que angleDeg et angleRad seraient mieux. Pourquoi ne pas l'expliciter ?

L'angle est pour les degrés, la rotation est pour les radians.

C'est peut-être ainsi que le phaser procède, mais ce n'est pas universellement convenu. la rotation est l'action et l'angle est la quantité de cette action qui s'est produite. Parfois appelé "angle de rotation". Donc, techniquement, l'angle ou la rotation pourraient être surchargés pour faire référence à la même chose et pourraient être exprimés dans l'une ou l'autre unité (degrés ou radians.)

Toutes les opérations mathématiques impliquant des rotations sont beaucoup plus faciles avec les radians. Ce n'est vraiment pas si difficile à saisir; Math.PI est à mi-chemin du cercle ; Math.PI * 2 est une rotation complète.

Le seul moment où les degrés sont appropriés est lorsque vous exposez une interface utilisateur visuelle à des personnes qui implique une rotation et que votre public est un groupe qui ne comprend pas la géométrie de base (c'est-à-dire la plupart des gens.)

Je reconnais que c'est une opinion, mais allez-y simplement avec des radians. Toutes les API mathématiques en javascript fonctionnent sur des radians, pas sur des degrés, comme le font la plupart des bibliothèques de géométrie non ludiques.

Si nous devons vraiment soutenir tout le monde pour tout, alors je suis d'accord avec @1j01 pour le rendre explicite. Peut-être .degrees ou .radians ?

Ce problème a été automatiquement marqué comme obsolète car il n'a pas eu d'activité récente. Il sera fermé si aucune autre activité ne se produit. Merci pour vos contributions.

Ce fil a été automatiquement verrouillé car il n'y a eu aucune activité récente après sa fermeture. Veuillez ouvrir un nouveau problème pour les bogues liés.