Estoy aprendiendo sobre ellos, y me resulta desalentador que hayan quedado obsoletos. ¿Debería seguir invirtiendo en aprenderlos? ¿Aprendería algo útil para el modelo actual?¿Por qué las listas de visualización se desaprobaron en OpenGL 3.1?
Creo que, aunque puedo estar equivocado, dado que la mayoría de las aplicaciones de gráficos de alto rendimiento (principalmente juegos) prácticamente solo utilizaban buffers de vértices y similares (para exprimir hasta el último rendimiento de la tarjeta), eso hubo presión para dejar de preocuparse por elementos "frívolos" como las listas de visualización (e incluso las llamadas glVertex antiguas). En mi humilde opinión, esto proporciona una gran barrera para que las personas aprendan a escribir el código OpenGL, y (para mis propios fines) es un gran impedimento para impulsar un código rápido, legible y razonablemente bueno.
Tenga en cuenta que estas características se desaprobaron en 3.0, y en realidad se eliminaron en 3.1 (pero aún se proporciona compatibilidad a través de una extensión ARB). En OpenGL 3.2, trasladaron estas características a un perfil de 'compatibilidad' que es opcional para que implementen los escritores de controladores.
¿Qué significa esto? NVidia, al menos, se ha comprometido a continuar apoyando el modo de compatibilidad de la vieja escuela para el futuro previsible: hay una gran cantidad de códigos heredados que necesitan para ser compatibles. Puede encontrar la discusión de su apoyo en una presentación de diapositivas en:
http://www.slideshare.net/Mark_Kilgard/opengl-32-and-more
partir de alrededor de diapositiva # 32. No conozco la postura de ATI/AMD sobre esto, pero supongo que sería similar.
Por lo tanto, aunque las listas de visualización se eliminan técnicamente de la parte requerida del estándar OpenGL 3.2, creo que está seguro de usarlas durante bastante tiempo. Eventualmente, es posible que desee aprender la interfaz buffer/shader-centrada para OpenGL, especialmente si su objetivo final es la escritura de juegos que empuja el sobre, pero realmente es mucho menos intuitivo (¡no glRotate, incluso!), Así que lo recomendaría comenzando con el buen viejo OpenGL 2.x.
-Matt
Encontré lo siguiente en el documento técnico de AMD GL3 (http://developer.amd.com/gpu_assets/GL3_WhitePaper.pdf): "AMD actualmente no tiene planes de eliminar ninguno de estos elementos desaprobados y eliminados de contextos OpenGL compatibles con versiones anteriores . AMD planea respaldar las características e interfaces que actualmente se usan ampliamente entre muchas bases de código ". – Gretchen
* "esto proporciona una gran barrera para las personas que aprenden a escribir el código OpenGL, y (para mis propios fines) es un gran impedimento para impulsar un código rápido, legible y razonablemente bueno" * - OpenGL debe considerarse un API de gráficos de nivel, por lo tanto, hablar en términos de "objetos de memoria intermedia" y "indicadores de atributos" es apropiado. Para acelerar el código rápido, un motor de gráficos como Irrlicht u Ogre u Horde3D o quizás Cinder pueden ser más apropiados. – Kos
Dicho esto, aumentar el código rápido en el núcleo OpenGL 3 o 4 no es * tan * difícil. Agregar vértices a un 'std :: vector' no es más complicado que los comandos' glVertex', y los shaders son mucho más simples que 'glLight' y' glTextureEnv'. De hecho, hay que manejar un código repetitivo, pero la mayor parte es álgebra lineal que se resuelve mejor con una biblioteca como GLM. Yo digo: Olvídese de las listas de visualización, vaya con el núcleo OpenGL. – Kos
Debido OISCIV (objetos de búfer de vértices) son mucho más eficiente y puede hacer listas de todo lo que pueden hacer de visualización. En realidad, tampoco son más complejos, solo un poco diferentes. A menos que ya esté más familiarizado con el estilo antiguo glBegin/glEnd, probablemente sea mejor que aprenda acerca de los búferes desde el principio.
no, VBO no puede hacer todo lo que las listas de visualización pueden. p.ej. El estado de la tienda de controladores profesional de NVIDIA cambia en forma optimizada y potencialmente los ejecuta en un hilo secundario. – Bahbar
OpenGL Wiki Preguntas frecuentes dice "Si y solo si hay un requisito para mantener el código heredado existente y no hay forma de reescribir el sistema de representación, usar listas de visualización puede ser bastante ventajoso en comparación con las matrices de vértices para datos estáticos. requerido, no hay forma de encontrar arreglos de vértices ". – legends2k
@Bahbar: Eso es además del punto. Quizás VAO puede hacerlo casi de cerca y quizás se pierda en un número pequeño si se compara con la comida por pieza, pero mirando la imagen más grande hay una gran ganancia (tanto en rendimiento como en flexibilidad) para pasar a la tubería moderna basada en sombreadores. – legends2k
Mientras que Matthew Hall tiene una buena respuesta y cubre la mayoría de las cosas, hay algunas cosas que agregaré.
Si mira lo que ha quedado obsoleto, verá que hay mucha funcionalidad fija y del lado del cliente. Por lo tanto, es obvio que están tratando de alejar a las personas del código centrado en el cliente y hacer que la gente haga todo lo posible por el lado del servidor en la GPU.
Cuando se trata de qué contexto utilizar, bueno, eso depende de usted. Aunque si el rendimiento es importante, entonces 3.x es probablemente el camino a seguir. Personalmente, definitivamente quiero aprender OpenGL 3.x, pero dudo que renuncie a 1.x/2.x. Es mucho más fácil armar una aplicación rápida con lo que está disponible en un contexto 1.x o 2.x.
Si desea una lista de lo que ha estado en desuso, descargar el 3.0 specification y busque en "El Modelo Deprecation"
listas de visualización fueron retirados, ya que con OpenGL 3+ todos los vértices, los datos de textura y la iluminación se almacenan en el tarjeta gráfica, en lo que se denomina procesamiento de modo retenido (los datos se conservan, lo que le permite enviar un solo comando a la tarjeta para dibujar una malla, en lugar de enviar datos de vértice a la tarjeta en cada cuadro).Un cuello de botella importante en gráficos de computadora es el ancho de banda de datos entre RAM y gpuRAM. al generar mallas una vez y al retener esos datos, podemos transformarlos utilizando matrices de transformación homogéneas y dibujarlos fácilmente. Esto efectivamente reduce el cuello de botella, con el inconveniente de tiempos de carga más largos. Modo inmediato, sin embargo (pre 3.0) utiliza cantidades masivas de ancho de banda de gráficos para enviar datos de vértice en cada cuadro, pre-transformado, con normales recalculadas, etc. Los problemas con este enfoque son dobles: 1) uso excesivo de ancho de banda, y demasiado Tiempo de inactividad de la GPU. 2) Uso excesivo del tiempo de la CPU para cálculos que se podrían realizar en paralelo en más de 100 núcleos, en la gpu
La solución simple a esto, es el modo retenido.
Con el modo retenido, las listas de visualización ya no son necesarias. De ahí su eliminación del perfil central.
El modo inmediato sigue siendo muy bueno para aprender la teoría de los gráficos por computadora. (y es muy divertido, para arrancar) Simplemente sufre en términos del máximo rendimiento posible.
VBOs & Los VAO pueden ser, al principio, menos intuitivos, pero en términos de velocidad, es muy superior.
Hay varios tutoriales de Opengl 3.0 fáciles de entender en Internet. Una vez que haya abierto el OpenGL 2.0, debería considerar pasar a 3.0+, ya que le permite crear aplicaciones gráficas en 3D muy rápidas.
Hay una diferencia entre "en desuso" y "eliminado". FYI. Las cosas en desuso generalmente no se eliminan de inmediato. – cHao
@cHao Solo se eliminaron del núcleo, pero están disponibles en modo compatibilidad. Por lo tanto, no se eliminan por completo. – Calmarius
@ Calmarius Eso es exactamente lo que * deprecated * significa en GL. –