Por que o DirectX usa um sistema de coordenadas para a mão esquerda?

Eu sei que este é um post antigo, mas vi este post sendo referenciado e não gosto do tom da resposta escolhida.

Então eu fiz um pouco de investigação!

1. O DirectX é antigo . Foi lançado pela primeira vez em 1995, quando o mundo tinha muito mais do que Nvidia e ATI , DirectX vs OpenGL. São mais de 15 anos, pessoas.
2. Glide da 3dfx Interactive (um dos concorrentes da DirectX no passado. O OpenGL não era para jogos na época) usou a esquerda sistema de coordenadas à mão.
3. POV-Ray e RenderMan (software de renderização da Pixar), também usa um sistema de coordenadas para a mão esquerda.
4. O DirectX 9+ pode funcionar com os dois sistemas de coordenadas.
5. Os dois WPF e XNA (que funciona com o DirectX nos bastidores) usa um sistema de coordenadas para a direita.

A partir disso, posso especular sobre algumas coisas:

• Os padrões do setor não são tão comuns quanto as pessoas gostam.
• O Direct3D foi construído em um momento em que todos faziam as coisas do seu jeito, e os desenvolvedores provavelmente não sabiam melhor.
• O canhoto é opcional, mas é habitual no mundo do DirectX.
• Como as convenções se extinguem, todo mundo acha que o DirectX só funciona com o canhoto.
• A Microsoft acabou aprendendo e seguiu o padrão em qualquer nova API criada por eles.

Portanto, minha conclusão seria:

Quando eles tinham que escolher, eles não sabiam do padrão, escolheram o 'outro' sistema, e todos os outros apenas seguiram para o passeio. Nenhum negócio obscuro, apenas uma infeliz decisão de design que foi levada adiante porque a compatibilidade com versões anteriores é o nome do jogo da Microsoft.

Estou surpreso que ninguém tenha mencionado algo: o OpenGL também funciona em um sistema de coordenadas para a mão esquerda. Pelo menos, é quando você está trabalhando com shaders e usa o intervalo de profundidade padrão.

Depois de jogar fora o pipeline de função fixa, você lida diretamente com o "espaço de clipe". A especificação OpenGL define o espaço do clipe como um sistema de coordenadas homogêneo 4D. Quando você segue as transformações através das coordenadas do dispositivo normalizadas, e até o espaço da janela, você encontra isso.

O espaço da janela está no espaço dos pixels de uma janela. A origem está no canto inferior esquerdo, com + Y subindo e + X indo para a direita. Isso soa muito como um sistema de coordenadas para a mão direita. Mas e quanto a Z?

O intervalo de profundidade padrão (glDepthRange) define o valor próximo de Z como 0 e o valor Z distante como um . Então o + Z está indo para longe do visualizador.

Esse é um sistema de coordenadas para a mão esquerda. Sim, você pode alterar o teste de profundidade de GL_LESS para GL_GREATER e alterar o glDepthRange de [0, 1] para [1, 0]. Mas o estado padrão do OpenGL é trabalhar em um sistema de coordenadas canhoto . E nenhuma das transformações necessárias para chegar ao espaço da janela a partir do espaço do clipe nega o Z. Assim, o espaço do clipe, a saída do sombreador do vértice (ou geometria) é um espaço canhoto (meio. É um espaço homogêneo 4D, então é difícil definir a lateralidade).

No pipeline de função fixa, as matrizes de projeção padrão (produzidas por glOrtho, glFrustum e similares) se transformam de um espaço destro para um canhoto . Eles invertem o significado de Z; basta verificar as matrizes que eles geram. No espaço dos olhos, + Z se move em direção ao observador; no espaço pós-projeção, ele se afasta.

Eu suspeito que a Microsoft (e GLide) simplesmente não se preocupou em realizar a negação em suas matrizes de projeção.

É pura história. Antigamente, os primeiros programadores de gráficos das cavernas pensavam na superfície de visualização do monitor (teletype? Stonetype?) Como papel gráfico bidimensional. Em matemática e engenharia, as convenções usuais para plotar os pontos de dados no papel milimetrado são: x = right, y = up. Então, um dia, cerca de uma semana após a invenção da roda de silício, alguém pensou em gráficos 3D. Quando a lâmpada desta idéia piscou acima de sua cabeça, por qualquer motivo, eles escolheram adicionar Z = longe do espectador. (Ai, minha mão direita dói imaginando isso.)

É tolice basear o sistema de coordenadas 3D na superfície da tela. É o modelo que conta - os triângulos e polígonos e planos que descrevem uma casa, cadeira, ogro ou galáxia verde acima do peso. Hoje em dia todos nós projetamos e modelamos coisas em sistemas XYZ destros, e fazemos isso em termos do mundo do modelo, mesmo antes de pensarmos como ele será renderizado. A câmera é adicionada em algum momento, possivelmente feita para voar de maneira maluca, e sua infraestrutura invisível que converte o modelo em pixels que, dentro de suas entranhas, precisam ser combinadas com transformações coordenadas do sistema.

Só para aumentar a confusão, algumas bibliotecas gráficas reconhecem que os CRTs escaneiam a imagem de cima para baixo e, portanto, Y = para baixo. Isso é usado até hoje em todos os sistemas de janelas e gerenciadores de janelas - X11, fvwm, gtk +, Win31 API etc. Como novos sistemas de GUI 3D como Clutter, Beryl etc. lidam com Z, é uma questão separada da modelagem de gráficos 3D. Esta necessidade diz respeito apenas aos programadores de aplicativos e designers de GUI.

Ambos são essencialmente equivalentes, já que um pode ser facilmente transformado para o outro. A única vantagem que posso encontrar para o sistema canhoto é: como os objetos estão mais distantes do observador, em qualquer direção (x, y ou z), a distância é um valor mais alto. Mas eu não tenho idéia se é por isso que a Microsoft escolheu uma sobre a outra.

O POV-Ray também usa um sistema corrido de mão esquerda.

O desenvolvedor principal do DirectX (e do Direct3D) Alex St. John recentemente comentou sobre isso. Em um artigo sobre a história do Direct3D ele escreveu:

I [...] was asked to choose a handedness for the Direct3D API. I chose a left handed coordinate system, in part out of personal preference. [...] it was an arbitrary choice.

Fonte: link

Tudo isso desapareceu quando sistemas de coordenadas destros se tornaram o padrão da indústria.

Já existem sistemas de coordenadas em uso comum, sem dobrar o número, introduzindo uma questão de destreza manual. Veja Minkler & Minkler, "Sistemas de Coordenadas Aeroespaciais e Transformações" . Se você estiver no negócio de coordenadas aeroespaciais, fazendo, por exemplo, simulação de vôo, você PRECISA de reservar.

Meu palpite é que a Microsoft não tinha NINGUÉM no projeto do DirectX que soubesse qualquer coisa sobre os padrões do setor, não percebesse que havia um padrão do setor e percebeu que isso não importava.

A outra possibilidade, que eles conheciam sistemas destros, era o padrão da indústria, e eles deliberadamente fizeram o DirectX canhoto, de modo a torná-lo difícil para as pessoas converterem o código que usou o DirectX para usar o OpenGL, não suporta consideração. Se eu descobrisse que esse era realmente o caso, eu acharia necessário embarcar em uma carreira nova e presumivelmente de curta duração como um assassino em Redmond.

A resposta real para o canhoto precoce do Direct3D é muito menos sinistra do que alguns de vocês estão especulando. O DirectX começou quando a Microsoft comprou o RenderMorphics em 1995.

Naquela época, o texto gráfico padrão usado nos escritórios do RenderMorphics era "Princípios da computação gráfica interativa", de Newmann e Sproul, que faz tudo usando coordenadas canhotos. É o mesmo livro que usei na faculdade. Olhando para o código D3D, você pode até vê-los usando nomes de variáveis que combinam com as equações do livro.

Não é uma conspiração da Microsoft. A decisão foi tomada antes que a Microsoft aparecesse.

Para todos aqueles que acham que não há vantagem para destro ou canhoto, você está absolutamente errado. A destreza dos sistemas de coordenadas cartesianas vem da definição do produto vetorial cruzado. Para vetores de base XYZ u , v e w , w = u X v .

Esta definição é fundamental para matemática vetorial, cálculo vetorial e muito da física. Suponha que você esteja tentando simular interações eletromagnéticas. Você tem um vetor de campo magnético, M e uma partícula carregada movendo-se nesse campo com velocidade v . Qual o caminho que a carga acelera? Fácil - na direção de M X v . Exceto que algum idiota pensou que seria divertido tornar seu sistema de exibição canhoto, então ele acelera na direção de -M X v .

Basicamente, qualquer interação física entre duas grandezas vetoriais é definida como destra e, assim, sempre que você precisar simular essa interação, é melhor esperar que seu sistema gráfico seja destro ou que você precise lembrar sinais negativos em toda a sua matemática.

Nenhum dos dois é melhor que o outro - você está mapeando coordenadas 3D para uma superfície 2D, então a terceira dimensão (que na verdade torna as coisas 3D) pode ser escolhida arbitrariamente, apontando para o observador ou para a tela. Você vai colocar as coisas em uma matriz 4x4 de qualquer maneira, então não há razão técnica para escolher uma sobre a outra. Funcionalmente, pode-se argumentar:

• Existe um consenso bastante amplo na computação e em outros campos para que o eixo X seja executado da esquerda para a direita (as aviações, aparentemente, são uma exceção notável).
• Na matemática, o eixo Y aponta para cima. (Também, é onde as bolhas vão).
• No computador, o eixo Y aponta para baixo (porque é assim que as telas CRT funcionam, e também porque essa é a ordem na qual a maioria dos scripts humanos organiza linhas).
• Quando você olha para o lado "visível" de uma superfície no plano X / Y, a normal deve apontar para o observador (como quando você vê imagens de satélite; a "altura acima do nível do mar" aponta para o satélite , não no centro da Terra). Como a normal para o plano X / Y é o vetor do eixo Z, segue-se que o eixo Z também deve apontar para o visualizador.
• Quando você observa imagens 3D em uma tela de computador, os pontos mais distantes do visualizador devem ter um componente Z maior. Assim, o eixo Z deve apontar para a tela.

Conclusão : Há algum consenso para o eixo X, mas para os outros dois, ambas as direções podem ser discutidas, produzindo duas configurações para destros e duas para canhotos, e todas elas fazem sentido.

Fato interessante.

Direct3D (não DirectX - DirectX também cobre entrada, som, etc) na verdade não tem um sistema de coordenadas para a mão esquerda.

É perfeitamente capaz de suportar sistemas RH e LH. Se você olhar na documentação do SDK, verá funções como D3DXMatrixPerspectiveFovLH e D3DXMatrixPerspectiveFovRH. Ambos funcionam, e ambos produzem uma matriz de projeção que pode ser usada com sucesso com seu sistema de coordenadas de escolha. Inferno, você pode até mesmo usar main-column no Direct3D se desejar; é apenas uma biblioteca matricial de software e você não é obrigado a usá-la. Por outro lado, se você quiser usá-lo com o OpenGL, verá que ele também funciona perfeitamente com o OpenGL (que talvez seja a prova definitiva da independência da biblioteca matricial do próprio Direct3D).

Então, se você quiser usar um sistema RH em seu programa, basta usar a versão -RH da função. Se você quiser usar um sistema LH, use a versão -LH. O Direct3D não se importa. Da mesma forma, se você quiser usar um sistema LH em OpenGL - apenas glLoadMatrix, uma matriz de projeção LH. Nada disso é importante e não está nem perto do enorme problema que você às vezes vê que é.

Não há vantagem técnica para a lateralidade, é completamente arbitrária. Ambos funcionam bem, desde que você seja consistente.

No final, faz pouca diferença - qualquer um que queira seriamente trocar ativos / códigos com outros sistemas / comunidades terá que estar preparado para lidar com a conversão manual, porque é um fato da vida em gráficos 3D. / p>     

Fornecer isso como material suplementar para minha resposta anterior aqui. De uma antiga especificação do OpenGL dos anos 90:

OpenGL does not force left-or right-handedness on any of its coordinates systems.

(fonte: link ).

Portanto, como nem o D3D nem o OpenGL impõem qualquer negatividade, a verdadeira questão é: por que as pessoas vêem isso como algo importante?

Eu odeio dizer a você, mas a 'mão' de um conjunto de coordenadas é realmente subjetiva - depende de como você imagina que está olhando para as coisas. Um exemplo, da especificação de mapa de cubo OpenGL: se você imaginar estar dentro do cubo olhando para fora, o sistema de coordenadas é canhoto, se você pensar em olhar de fora, é destro. Esse simples fato causa um luto sem fim, porque, para obter uma resposta numericamente correta, todas as suposições devem ser consistentes, mesmo que localmente não importe qual suposição você faz.

A especificação OpenGL é oficialmente "handedness neutral" e se esforça para evitar esse problema - ou seja, colocá-lo no programador. No entanto, há uma "mudança manual" entre as coordenadas dos olhos e as coordenadas do clipe: no modelo e no espaço ocular em que estamos olhando, no clipe e no espaço do dispositivo, estamos olhando para fora. Eu estou sempre lutando com as consequências dessa complicação acidental, sem dúvida.

O produto cruzado é nosso amigo, porque permite gerar um sistema de coordenadas 3D definitivamente destro ou canhoto a partir de um par de vetores. Mas qual é a mão depende de qual desses vetores você chama de "X".

Eu poderia dizer que o padrão da indústria está errado desde o primeiro lugar

O padrão industrial de coordenada, na verdade, veio da coordenada da mesa, quando as pessoas desenham tudo na mesa, que é o plano horizontal. X está à esquerda / direita e Y está na frente / trás, então isso faz com que Z seja para cima e que tenha nascido com o sistema de coordenadas destro

Mas Você sabe Nós agora usando com monitor de tela É plano vertical. X ainda está para a esquerda / direita, mas Y é para cima e para baixo

Então, qual sistema de coordenadas à direita causaria? Isso faz com que + Z seja para trás e -Z seja para frente O que diabos é isso? Up é + e Down é - A direita é + e a esquerda é - MAS Forward é - e Backward é + ??? É tão estúpido se nós fizermos o jogo esse personagem rodando no mundo 3D, mas precisamos z menos para seguir em frente. É por isso que o programador de jogos mais aprecia o DirectX

Para pegar um padrão que veio da mesa e usá-lo no monitor é tão errado em muitos níveis desde o primeiro lugar. E agora devemos admitir que eles, OpenGL e Industry, estão errados. Eles apenas usam o que eles acham que os deixaria confortáveis, mas eles estão errados e o Sistema de Coordenadas Destro é apenas um legado de lixo que deve ser jogado fora o mais rápido possível