Pixi.js: Retrabalhe APIs que usam radianos para usar graus ao invés

Alguns contras que vêm à mente:

• funções matemáticas javascript integradas padronizadas em radianos
• funções glsl integradas padronizam em radianos
• radianos são um formato mais conveniente para lidar com alguns tipos de cálculos (por exemplo, posso ler de 0-> Math.pi * 2 e obter uma rotação completa no sentido horário).

Sou o cara da matemática e prefiro usar os graus 0..1 ou 0..512 por causa da persistência e do formato do sombreador. Se você me fizesse a mesma pergunta há dois ou mais anos, eu poderia dizer que os radianos são melhores porque são "puros" no significado matemático.

No entanto, armazenar 2 x Math.PI em arquivos é um problema (persistência), e "360" é apenas mais rápido de escrever do que 2 * PI, não pode ser representado claramente na forma binária.

Os mecanismos baseados em Flash estão funcionando principalmente com graus:

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

Também editores como a Spine trabalham e armazenam ângulos em radianos.

Outra coisa estranha é que usamos SKEW, que é uma coisa de designer gráfico e é apenas "(shear.y, -shear.x)" em sentido matemático, permitimos tal abominação e forçamos o usuário a usar rads ao mesmo tempo.

Seu conflito entre "renderizador de baixo nível" e "renderizador gráfico 2D com seu próprio estágio e suporte a ferramentas", e eu acho que pixi está mais perto do segundo.

@englercj Também tenho que trabalhar nesse código, já tenho algo parecido em meu fork: https://github.com/gameofbombs/gobi/tree/master/src/core/transform
https://github.com/gameofbombs/gobi/blob/master/src/core/math/FlatTransform2d.ts

@mreinstein, eu tenho que pedir para olhar esse código também, já que você sabe algo sobre transformações pixi;)

Sugestões de @bigtimebuddy & @GoodBoyDigital , torne a API configurável:

// useDegrees
CONVERSION = Math.PI / 180;

// useRadiens
CONVERSION = 1;

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

Talvez como Phaser faça? O ângulo é para graus, a rotação é para radianos.

@englercj Agree. Essa é a maneira mais simples de fazer isso. Motores baseados em pixi podem apenas consertar sua constante de "CONVERSÃO".

@englercj Processing faz isso, e eu acho que é uma péssima decisão de design. Isso prejudica a modularidade. Se você tiver uma parte do código que faz algo de uma maneira e tentar usar outra parte do código (talvez em uma biblioteca) que assume a outra maneira, não funcionará. Se você se certificar de definir o modo de unidade antes de cada chamada para uma função relacionada ao ângulo, isso pode garantir que seu código funcione, mas interromperá o código da biblioteca. E se houver um trecho de código de biblioteca que usa ângulos, ele deve definir o modo de ângulo? Isso pode garantir que seu código funcione conforme o esperado, mas quebra o código do usuário. É quase como o Dilema do Prisioneiro sobre o design da API.

@OSUblake Isso parece mais razoável. Embora o ângulo e a rotação dos nomes não denotem ou proíbam explicitamente uma unidade, definitivamente há associações que tornam isso mais razoável do que uma estimativa 50/50.

Mas acho que angleDeg e angleRad seriam melhores. Por que não torná-lo explícito?

O ângulo é para graus, a rotação é para radianos.

Pode ser assim que o phaser faz, mas isso não é universalmente aceito. rotação é a ação e ângulo é a quantidade dessa ação que aconteceu. Às vezes referido como "ângulo de rotação". Portanto, tecnicamente, o ângulo ou a rotação podem ser sobrecarregados para se referir à mesma coisa e podem ser expressos em qualquer unidade (graus ou radianos).

Qualquer operação matemática envolvendo rotações é muito mais fácil com radianos. Realmente não é tão difícil de entender; Math.PI está na metade do círculo; Math.PI * 2 é uma rotação completa.

O único momento em que os graus são apropriados é quando você está expondo uma interface de usuário visual para pessoas que envolve rotação, e seu público é um grupo que não entende geometria básica (ou seja, a maioria das pessoas).

Eu reconheço que isso é opinião, mas apenas vá com os radianos. Todas as APIs de matemática em javascript operam em radianos, não em graus, como a maioria das bibliotecas de geometria que não são de brinquedo.

Se realmente devemos apoiar todos em tudo, então concordo com @ 1j01 para torná-lo explícito. Talvez .degrees ou .radians ?

Este problema foi marcado automaticamente como obsoleto porque não teve atividades recentes. Ele será fechado se nenhuma outra atividade ocorrer. Obrigado por suas contribuições.

Este tópico foi bloqueado automaticamente, pois não houve nenhuma atividade recente depois que ele foi fechado. Abra um novo problema para bugs relacionados.