Por que o DirectX usa um sistema de coordenadas para canhotos?

Eu considerei postar no Stack Overflow, mas a pergunta me parece muito subjetiva, pois não consigo pensar em uma explicação técnica razoável para a escolha da Microsoft nesse assunto. Mas essa pergunta me incomoda há tanto tempo e o problema continua aparecendo em um dos meus projetos, e eu nunca vi uma tentativa de explicar isso:

O OpenGL usa um sistema de coordenadas destro, onde a parte + Z do sistema de coordenadas mundial se estende em direção ao visualizador.

O DirectX usa um sistema para canhotos, onde a parte + Z do mundo se coordena e se estende para a tela, longe do visualizador.

Eu nunca usei a API Glide , por isso não sei como ela funcionou, mas pelo que posso entender, ela também usa um sistema para canhotos.

Existe uma razão técnica para isso? E, se não, existe alguma vantagem conceitual para uma entrega específica de um sistema de coordenadas? Por que um escolheria um sobre o outro?

Eu sei que este é um post antigo, mas vi esse 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, pessoal.
2. O Glide da 3dfx Interactive (um dos concorrentes do DirectX na época. O OpenGL não era para jogos naquela época) usava um sistema de coordenadas para canhotos.
3. O POV-Ray e o RenderMan (software de renderização da Pixar) também usam um sistema de coordenadas para canhotos.
4. O DirectX 9+ pode funcionar com os dois sistemas de coordenadas.
5. O WPF e o XNA (que funcionam com o DirectX nos bastidores) usam um sistema de coordenadas destro.

A partir disso, posso especular sobre algumas coisas:

• Os padrões da indústria não são tão padrão quanto as pessoas gostam.
• O Direct3D foi construído em uma época em que todos faziam as coisas do seu jeito, e os desenvolvedores provavelmente não sabiam melhor.
• Canhoto é opcional, mas habitual no mundo DirectX.
• Como as convenções perdem força, todo mundo acha que o DirectX só pode funcionar com a mão esquerda.
• A Microsoft finalmente aprendeu e seguiu o padrão em quaisquer novas APIs que eles criaram.

Portanto, minha conclusão seria:

Quando eles tiveram que escolher, eles não sabiam do padrão, escolheram o sistema 'outro' e todos os demais foram dar uma volta. Nenhum negócio obscuro, apenas uma decisão de design infeliz que foi levada adiante porque 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 canhotos. Pelo menos, acontece quando você está trabalhando com shaders e usa a faixa de profundidade padrão.

Depois de jogar fora o pipeline de função fixa, você lida diretamente com o "espaço do clipe". A especificação OpenGL define o espaço do clipe como um sistema de coordenadas homogêneo 4D. Ao seguir as transformações por meio de coordenadas normalizadas do dispositivo 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 parece muito com um sistema de coordenadas destro. Mas e o Z?

O intervalo de profundidade padrão (glDepthRange) define o valor próximo de Z para 0 e o valor distante de Z para um . Portanto, o + Z está se afastando do visualizador.

Esse é um sistema de coordenadas para canhotos. 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 para canhotos . E nenhuma das transformações necessárias para obter o espaço da janela do espaço do clipe nega o Z. Portanto, o espaço do clipe, a saída do sombreador de vértice (ou geometria) é um espaço para canhotos (meio. É um espaço homogêneo em 4D, então é difícil definir a mão).

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

Suspeito que a Microsoft (e o GLide) simplesmente não se deram ao trabalho de negar suas matrizes de projeção.

É pura história. Antigamente, os primeiros programadores de gráficos de cavernas pensavam no monitor (teletipo? Pedra?) Vendo a superfície como um papel gráfico bidimensional. Em matemática e engenharia, as convenções usuais para plotar pontos de dados em papel milimetrado são: x = à direita, y = para cima. Então, um dia, cerca de uma semana após a invenção da roda de silicone, alguém pensou em gráficos 3D. Quando o bulbo de vela dessa idéia piscou acima da cabeça, por qualquer motivo, eles escolheram adicionar Z = ao visualizador. (Ai, minha mão direita dói só de imaginar isso.)

Eles não tinham idéia de que algum dia seus descendentes se tornariam engenheiros, cientistas, artistas plásticos, artistas comerciais, animadores, designers de produtos etc. e considerariam úteis os gráficos 3D. Todas essas pessoas modernas e refinadas usam sistemas de coordenadas destros para serem consistentes entre si e com os textos de matemática e convenções de física mais estabelecidos.

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

Apenas para aumentar a confusão, algumas bibliotecas gráficas reconhecem que os CRTs digitalizam a imagem de cima para baixo e, portanto, têm Y = para baixo. Isso é usado ainda hoje em todos os sistemas de janelas e gerenciadores de janelas - X11, fvwm, gtk +, API Win31 etc. O modo como os novos sistemas de GUI 3D, como Clutter, Beryl etc. lidam com o Z, é uma questão separada da modelagem de gráficos 3D. Isso precisa envolver apenas programadores de aplicativos e designers de GUI.

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

O POV-Ray também usa um sistema de corrediça canhoto.

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

Pediram-me para escolher uma mão para a API Direct3D. Eu escolhi um sistema de coordenadas para canhotos, em parte por preferência pessoal . [...] foi uma escolha arbitrária .

Fonte: http://www.alexstjohn.com/WP/2013/07/22/the-evolution-of-direct3d/

O importante é entender que uma quantidade enorme de tempo do programador foi desperdiçada na conversão entre sistemas de coordenadas para canhotos e destros, e ainda mais tempo foi programado para lembrar qual sistema era necessário em um determinado momento.

Tudo isso desapareceu quando os sistemas de coordenadas destros se tornaram o padrão do setor.

Já existem sistemas de coordenadas suficientes em uso comum, sem dobrar o número, introduzindo uma questão de entrega. Veja Minkler & Minkler, "Sistemas e transformações de coordenadas aeroespaciais" . Se você estiver no negócio de coordenadas aeroespaciais, realizando, por exemplo, simulação de vôo, você PRECISA desse livro.

Meu palpite é que a Microsoft não tinha NINGUÉM no projeto DirectX que sabia algo sobre os padrões do setor, não sabia que havia um padrão no setor e achava que isso não importava.

A outra possibilidade, que eles sabiam que os sistemas para destros eram o padrão do setor e deliberadamente tornavam o DirectX canhoto, para tornar difícil para as pessoas converterem código que usava o DirectX para usar o OpenGL, não leva em consideração. Se eu descobrisse que esse era realmente o caso, consideraria necessário iniciar uma nova e presumivelmente curta carreira como assassino de machados em Redmond.

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

Essa definição é fundamental para a matemática vetorial, cálculo vetorial e grande parte 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 se movendo nesse campo com velocidade v. De que maneira a cobrança acelera? Fácil - na direção de M X v. Exceto por algum idiota que achou 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 quantidades de vetores é definida como destra; portanto, a qualquer momento que você precisar simular essa interação, é melhor esperar que seu sistema gráfico seja destro ou lembre-se de transportar sinais negativos em toda sua matemática.

A resposta real para a 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 da RenderMorphics era "Principles of Interactive Computer Graphics", de Newmann e Sproul, que faz tudo usando coordenadas canhotas. É o mesmo livro que eu usei na faculdade. Olhando para o código D3D, você pode até vê-los usando nomes de variáveis ​​que correspondem às equações do livro.

Não é uma conspiração da Microsoft. A decisão foi tomada antes mesmo da Microsoft entrar em cena.

Em última análise, nenhum é melhor que o outro - você está mapeando coordenadas 3D para uma superfície 2D, para que a terceira dimensão (que realmente torna as coisas 3D) possa ser escolhida arbitrariamente, apontando para o visualizador 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 corra da esquerda para a direita (aviação aparentemente sendo uma exceção notável).
• Em matemática, o eixo Y aponta para cima. (Além disso, é onde as bolhas vão).
• Nos monitores dos computadores, o eixo Y aponta para baixo (porque é assim que as telas de CRT funcionam e também porque é a ordem na qual a maioria dos scripts humanos organiza as linhas).
• Quando você olha para o lado "visível" de uma superfície no plano X / Y, o normal deve apontar para o espectador (como quando você olha para imagens de satélite; a "altura acima do nível do mar" aponta para o satélite, não para o centro da terra). Como o 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ê olha imagens 3D em uma tela de computador, os pontos que estão mais distantes do visualizador devem ter um componente Z maior. Portanto, o eixo Z deve apontar para a tela.

Conclusão : Existe algum consenso para o eixo X, mas para os outros dois, ambas as direções podem ser discutidas, produzindo duas configurações para a mão direita e duas para a esquerda, e todas fazem sentido.

Fato interessante.

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

É perfeitamente capaz de suportar os sistemas RH e LH. Se você procurar 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 o seu sistema coordenado de escolha. Inferno, você pode até usar a coluna principal no Direct3D, se desejar; é apenas uma biblioteca de matrizes de software e você não precisa usá-lo. Por outro lado, se você quiser usá-lo com o OpenGL, também verá que ele também funciona perfeitamente bem com o OpenGL (que talvez seja a prova definitiva da independência da biblioteca de matrizes em relação ao Direct3D).

Portanto, se você deseja usar um sistema RH no seu programa, use a versão -RH da função. Se você deseja 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 no OpenGL - basta glLoadMatrix uma matriz de projeção LH. Nada disso é importante e não chega nem perto do grande problema que às vezes você vê que parece ser.

Não há vantagem técnica em nenhuma das mãos, é completamente arbitrário. Ambos funcionam bem, desde que você seja consistente.

Por causa das vantagens da consistência, o ideal é simplesmente "usar o que todo mundo está usando" - mas isso é bastante difícil em muitos casos, porque também não existe uma convenção predominantemente "preferida": as duas mãos são amplamente usadas. Na melhor das hipóteses, há alguma consistência dentro de certas comunidades (por exemplo, OpenGL).

Portanto, acho que a resposta básica a essa pergunta é: Eles escolheram o que escolheram porque parecia certo (sem dúvida, eles tinham alguma experiência anterior com essa destreza) e havia poucas razões para não fazê-lo.

No final, faz pouca diferença - quem quer seriamente trocar ativos / códigos com outros sistemas / comunidades terá que estar preparado para lidar com a conversão de mãos de qualquer maneira, porque é um fato da vida nos gráficos 3D.

Fornecendo isso como material suplementar à minha resposta anterior aqui. De uma antiga especificação do OpenGL da década de 1990:

O OpenGL não força a mão esquerda ou a mão direita em nenhum de seus sistemas de coordenadas.

(fonte: http://www.opengl.org/documentation/specs/version1.2/opengl1.2.1.pdf ).

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

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

A especificação do OpenGL é oficialmente "neutra em termos de flexibilidade" e faz o possível para evitar esse problema - ou seja, colocá-lo no programador. No entanto, há uma "troca manual" entre as coordenadas oculares e as coordenadas dos clipes: no modelo e no espaço ocular em que estamos olhando, no espaço clip e no dispositivo que estamos observando. Estou sempre lutando com as consequências dessa complicação sem dúvida acidental.

O produto cruzado é nosso amigo, pois permite gerar um sistema de coordenadas 3D definitivamente destro ou canhoto a partir de um par de vetores. Mas qual 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 início

O padrão de coordenadas do setor realmente veio das coordenadas da mesa, quando as pessoas desenham tudo na mesa, que é o plano horizontal. X é esquerda / direita e Y é frente / trás, portanto, faz com que Z fique para cima e que nasceu Sistema de coordenadas destro

Mas você sabe que agora estamos usando a tela do monitor. É o plano vertical. X ainda está à esquerda / direita, mas Y é para cima e para baixo

Então, o que o sistema de coordenadas destro causaria? Faz + Z ficar para trás e -Z estar para frente Que diabos é isso? Cima é + e Baixo é - Direita é + e Esquerda é - MAS Forward é - e Backward é + ??? É tão estúpido se estamos fazendo esse personagem rodando no mundo 3D, mas precisamos menos z para seguir em frente. É por isso que o programador de jogos mais aprecia o DirectX

Pegar um padrão que veio da mesa e usá-lo no monitor é tão errado em muitos níveis desde o início. E agora devemos admitir que eles, OpenGL e Industry, estão errados. Eles apenas usam o que acham que os deixaria confortáveis, mas estão errados e o Sistema de Coordenadas para a Mão Direita é apenas um legado inútil que deve ser jogado fora o mais rápido possível