Hoy me he dedicado a 2 cosas (3 si contamos el catarro): hacer una página web para melt y aprender los conceptos básicos de OpenGL. Tras tener una ventana de renderizado y despejar un poco haciendo el html de la web, hoy iba dispuesto a aprender cómo hacer el bucle de renderizado, almacenar la geometría de los objetos, las texturas, etc. Todo el mundo dice que OpenGL tiene una buena API para aprender, y tienen bastante razón.
Yo ya conocía algunos de los procedimientos tras haber utilizado las DirectX administradas, aunque la parte de carga de modelos la hacía con las clases de utilidad y los cambios de estado se gestionaban cambiando tal o cual objeto. Sin embargo me encuentro ahoar con la posibilidad de usar varios sistemas para dibujar las geometrías, e implican almacenar los vértices y demás de maneras concretas.
La primera es el modo inmediato. Es la que todos habréis visto en los tutoriales de NeHe y realmente es algo muy sencillo. Pero tener que llamar a una función por cada vértice, por cada coordenada de textura y demás no la hacen demasiado eficiente, así que queda descartada.
Luego tenemos las display lists, que son como si empaquetásemos instrucciones del modo inmediato. Son mucho más eficientes y técnicamente puedes meter cualquier cosa. Sin embargo no me quedan muy claras. ¿Debería crear una lista por cada geometría? ¿Solo por las geometrías que están dentro del frustum? ¿Vale también para “empaquetar” instrucciones relacionadas con los materiales (asignar texturas y valores ambiental, difuso, …) ?
También están los vertex arrays que son precisamente arrays de vértices que le pasamos al renderizador con una sola función, pero no está cacheado como las display lists. Sin embargo, permite modificar los vértices a posteriori, cosa que las display lists no.
Por último tenemos los Vertex Buffer Objects o VBO. Se supone que tenderán a ser el estándar para este menester, pero ahora parece que están todavía muy verdes. Pueden ser dinámicos o estáticos, con lo que deberían ser equivalentes a los métodos anteriores. Sin embargo, los VBO estáticos parecen estar por debajo de las display lists en todos los benchmarks, y los VBO dinámicos tienen problemas de rendimiento.
Mis dudas son que no sé qué estructura crear y como utilizarlas. No sé si tengo que crear dichas estructuras cada frame una vez hecho el culling. Además, son estructuras que maneja internamente OpenGL, así que nosotros no reservamos memoria para ellas pero ¿dónde se almacenan? porque si es en la tarjeta gráfica, no creo que sea buena idea almacenar todo ahí.
Ahora, he de decir que la API en sí está muy bien diseñada y resulta sencilla de entender. Aunque puede que cuando empiece a utilizar las diversas extensiones la cosa se desmadre un poco. Menos mal que la página web ha quedado sencilla a la par que elegante. En cuanto tenga algo de contenido os la mostraré, no hay prisa.
- Cursillo de motores (II)
- Sistemas de partículas en la GPU
- Programando en OpenGL
- Enlaces variados sobre gráficos
- Progreso con Melt
- 25 de Octubre de 2007 a las 2:34 pm
KnudoW dice:
Y a qué hora te levantas para darte tiempo a hacer “todo esto”?
P.D. – Sí, la pregunta es tonta, pero es que a partir del primer párrafo me perdí, xD
Miguel Herrero dice:
Al final voy a intentar usar VBOs estáticos, ya que la mayor parte de mi geometría es estática (luego puedo manipularla mediante transformaciones). Ya os contaré el resultado…
Jacobo dice:
Hola,
Lo mejor que puedes hacer es pasar de las display lists. Si bien pueden dar un rendimiento superior a los VBO, tienen dos inconvenientes muy grandes: a) van a ser eliminadas en OpenGL 3.0 (y en OpenGL|ES no existen desde el principio) y b) son demasiado estáticas. Es una pena, ya que el uso de las display lists permite al driver hacer muchísimas optimizaciones (incluso cullings por oclusion), pero el no poder cambiar nada en ellas es un engorro. En cuanto a los VBO, hay dos opciones: o utilizar vertex array normales, con el consabido consumo de ancho de banda en el AGP, o usar los VBO (ya sean dinamicos o estáticos). Aqui la cuestion es el típico tradeoff entre almacenar las cosas en memoria de video o mandarselas a la tarjeta cada vez.
Mi consejo es que para las cosas que vayan a ‘dibujarse’ casi siempre, uses VBO, pero para las cosas puntuales, uses vertex arrays, pero como siempre, todo depende de donde esté el cuello de botella en tu aplicación, si en el AGP o en la VRAM (en este caso). En cuanto a la duda que mostrabas en tu entrada del blog, los objetos de OpenGL (shaders, texturas, vertex buffers) se almacenan siempre en vram (si hay espacio) y si no lo hay, en memoria del driver. Es el propio driver de OpenGL el que se encarga de hacer swapping cuando es necesario.
Por cierto, en cuanto a las texturas, puedes prioritizarlas, para asegurarte de que las que más te interesen tengan el mayor numero de probabilidades de estar cargadas en vram. Con OpenGL hay que tener una cosa en cuenta: todo lo que usa en un momento dado, tiene que estar en VRAM (se encarga el driver) en ese momento. OpenGL no hace a la tarjeta acceder a la memoria principal para acceder directamente a una textura. Lo que hace es subir la textura a VRAM y luego usarla, pero nunca usarla desde memoria principal.
Un saludo y ya nos veremos en el curso de HLSL que empieza el sábado
Jacobo.
Miguel Herrero dice:
Ya he terminado la implementación básica de VBO aunque tengo que refactorizar bastante. Estuve un buen rato viendo una pantalla vacía hasta que me dí cuenta que tenía que mover el objeto en el eje z para verlo (borré ese código por error).
La mayoría de mi geometría será estática, salvo quizás las partículas pero tendré que mirar a ver si me vale la pena usar point sprites.
Gracias por la explicación, poco a poco voy entendiendo OpenGL (y de momento me gusta).
Por cierto, estoy hechando una ojeada a tu web
que parece que tiene cosas interesantes…Jacobo dice:
He cerrado la web, pero dado que el material que tengo ahi es parte del SDK oficial de OpenGL lo he preferido dejar accesible, aunque de una manera un tanto básica.
Bueno, a ver si te unes al club de OpenGL
, si tienes alguna duda, ya sabes donde pillarme.

