OpenGL: ¿por qué se eliminó la matriz de matriz y qué están usando las personas ahora?

Question

Estoy leyendo OpenGL Superbible Fifth Edition y hablan sobre el uso de stacks en su propia clase. Eso es genial, pero mencionan que las pilas de matriz estaban en desuso. ¿Por qué fueron desaprobados y qué usa la gente en lugar de ellos?

Answer 1

La pila de la matriz (y el resto de las funciones de la matriz) se desaprobaron solo en el perfil central. En el perfil de compatibilidad, aún así debería poder usarlos.

Desde mi punto de vista, se eliminó porque la mayoría de los motores/frameworks tienen un código Math personalizado y un estilo uniforme de shader para enviar matrices a shaders.

Aunque para programas/tutoriales simples es muy inconveniente usar y buscar algo más.

sugiere emplear:

• GLM (http://glm.g-truc.net/)
• muy simple lib matemáticas (vsml)

Answer 2

Bueno, la primera y principal razón, para mí, es que con el aumento de sombreadores programables (que son obligatorios después de la tercera versión de opengl), todas las variables como GL_PROJECTION y GL_MODELVIEW que se transfirieron automáticamente a los sombreadores se están eliminando de los sombreadores, por lo que el usuario tiene que definir su propia matriz para usarlo en el sombreador. Como tiene que enviar la matriz manualmente usando las funciones uniformes, ya no necesita más variables fijas.

Answer 3

¿Por qué estaban en desuso

Debido a que en realidad nadie lo utilizó en programas OpenGL mundo real. Tome una simulación de física, por ejemplo: tendría toda la colocación de objetos almacenada en el sistema de física como una matriz de 4 × 4 de todos modos. Entonces solo usarías eso. Lo mismo ocurre con los sistemas de determinación y animación de objetos visibles. Todos ellos necesitan implementar la matriz matemática de todos modos, por lo que tener esto en OpenGL es bastante redundante, ya que la mayoría de las veces las matrices ya existentes simplemente se pusieron en glLoadMatrix.

y qué usan las personas en lugar de ellos?

lo que eran antes: Sus sistemas de animación, simuladores de la física, escenarios gráficos, etc.

Answer 4

La razón (s) son políticos, no técnicos, y se remontan a la década de 2000.

OpenGL 3 fue la primera versión que quería romper la compatibilidad con versiones anteriores. Los diseñadores querían crear una API para los usuarios expertos, los programadores de juegos y los codificadores de visualización de gama alta que sabían todo sobre los sombreadores y escribieron su propio código de matriz. La intención era que la API de OpenGL 3 coincidiera bastante con el hardware real. (Incluso en OpenGL 1/2, la pila de matriz generalmente se implementaba en el lado de la CPU, no en la GPU).

Desde el punto de vista del programador de un motor de juego, esto era mejor. Y bueno, si tienes que desarrollar un nuevo motor de juego cada dos años, ¿cuál es el problema de tirar el código anterior?

El resultado de este proceso de diseño es el perfil de núcleo OpenGL 3/4.

Una vez que se anunció la "nueva generación" de OpenGL, todos los codificadores no tan expertos de las universidades y las empresas se dieron cuenta de que estarían jodidos. Estas son las personas (como yo) que enseñan gráficos en 3D o escriben programas de utilidad para investigación o diseño. No necesitamos iluminación más avanzada que la simple ambiente-difusa-especular. A menudo tenemos que mezclar códigos de diferentes fuentes, y eso solo es fácil si todos usan exactamente las mismas convenciones de matriz, iluminación y texturización, como las provistas por OpenGL 2.

Además, he escuchado pero no puedo verificar, las grandes compañías de CAD/CAM se dieron cuenta de que también les iban a atornillar. Tirar dos millones de líneas de código de diez años de desarrollo no es una opción cuando tienes que pagar (y bien pagado: comparar precios para los clientes de Quadro vs GeForce, o FireGL vs Radeon).

Por lo tanto, tanto NVIDIA como ATI anunciaron que admitirían la antigua API todo el tiempo que pudieran.

El resultado de esta presión son los perfiles de compatibilidad. Y el OpenGL ARB ahora parece haberse dado cuenta de que si bien les gustaría que todos cambien al perfil central, simplemente no va a suceder: lea la especificación de extensión para sombreadores de teselación en OpenGL 4 y menciona que GL_PATCHES funcionará con glBegin.