Tuesday, April 17, 2012

Mi caso contra OpenGL


OpenGL sirve para hacer gráficas. De acuerdo a la Wikipedia: OpenGL (Open Graphics Library) es una especificación estándar que define una API multilenguaje y multiplataforma para escribir aplicaciones que produzcan gráficos 2D y 3D. La interfaz consiste en más de 250 funciones diferentes que pueden usarse para dibujar escenas tridimensionales complejas a partir de primitivas geométricas simples, tales como puntos, líneas y triángulos. Fue desarrollada originalmente por Silicon Graphics Inc. (SGI) en 1992 y se usa ampliamente en CAD, realidad virtual, representación científica, visualización de información y simulación de vuelo. También se usa en desarrollo de videojuegos, donde compite con Direct3D en plataformas Microsoft Windows.

Y este tema me interesó hace tiempo, pero hasta ahora que estoy dando un curso de graficación en la Facultad de Ciencias de la UNAM, decidí aplicarme y ver qué tanto se podía hacer en OpenGL. Hallé de entrada que hay muchísima documentación y por ende, es fácil encontrar ejemplos, tutoriales, etc. En Google se pueden ver montones de imágenes muy bien logradas con esta biblioteca gráfica. Sin embargo, después de un par de meses de estar lidiando con este asunto encontré que hay cosas que no me convencen. He aquí algunas de ellas:

OpenGL tiene sus virtudes, pues se puede instalar prácticamente en cualquier herramienta de programación. Sin embargo, para cada una hay que seguir pasos diferentes. No tiene un procedimiento estándar para esto y cambia de acuerdo al marco de trabajo que quiera usarse.

  1. Para poder usar OpenGL y sacar provecho del mismo hay que pensar en modelos matemáticos. Uno lo que hace, al programar en OpenGL es crear un medio ambiente tridimensional, el cual es muy flexible en muchos sentidos. El problema es que esto hay que tenerlo presente al programar. Por ejemplo, si queremos crear una esfera, tenemos que escribir el código que haga esto. Si queremos que tenga textura tenemos que escribir las instrucciones que nos permiten "texturizar" el objeto, etc. No obstante, nada de esto podemos verlo "en vivo", es decir, necesitamos correr el programa y ver si nuestro modelo tridimensional matemático es lo que estábamos esperando (cosa que pocas veces sucede).
  2. Las instrucciones de OpenGL vienen en diferentes "formatos". Se puede usar por ejemplo, una instrucción que contenga parámetros enteros, dobles, de punto flotante, y tendremos que hay tres instrucciones diferentes, una para cada formato, en donde se agrega a la instrucción lo siguiente: GLColor* (1.0, 1.0, 1.0);en donde el * representa 3f (3 coordenadas de punto flotante); 3d (tres coordenadas de resolución doble); 3i (tres coordenadas enteras). Esto en mi opinión puede ser muy versátil, pero es confuso.
  3. La curva de aprendizaje es realmente lenta, porque insisto y hago énfasis: OpenGL no tiene un sistema para ir visualizando cómo se van haciendo las cosas de acuerdo a las instrucciones escritas. Hasta que se compila puede verse el resultado final, que de verdad, pocas veces coincide con lo que estábamos pensando.

Para mi gusto, sería mucho más amable tener una herramienta al mejor estilo 3dStudio, el cual permite en muchos casos hacer las imágenes interactivas, poner texturas, luces, trayectorias de la cámara para ver cómo se va a mover, etc. Así como está OpenGL, deja mucho que desear.

Quizás para alguna aplicación específica sea la herramienta adecuada pero hasta el momento usar OpenGL como la biblioteca gráfica de programación, parece ser demasiado complicado y poco amable con el programador.

2 comments:

Marco A. Dorantes said...

Manuel, hace tiempo también intenté acercarme más a OpenGL. Mis hallazgos no han sido muy distintos a los que comentas con respecto al diseño del API, y también observo la pertinencia de un ambiente de visualización interactiva pero, a diferencia del gusto que expresas, a mí no me gustaría que tal ambiente fuese parte intrínseca de OpenGL. Principalmente debido a que tal ambiente y el API [1] pertenecen a niveles distintos de abstracción y mezclarlos sería un grave error de diseño. A decir de sus metas de diseño (ver a partir de la lámina 16 de [2]) OpenGL representa una, digamos, “plataforma” para procesamiento de gráficas, sobre la cual pueden crearse una variedad de posibles ambientes de visualización interactiva. Por lo tanto, para encontrar el ambiente de marras es necesario buscarlo en otra parte, como en aplicaciones de dominio específico, y no en OpenGL.

Ejemplos de tales aplicaciones de dominio específico se encuentran, digamos, aplicaciones de diseño de productos en la industria de la manufactura [3], las cuales utilizan una plataforma para gráficos encima de la cual crean otras varias capas de funcionalidad para lograr distintos niveles de interacción y dinamismo.

[1] OpenGL specifications – http://www.opengl.org/registry/
[2] The Design of OpenGL – http://www.graphics.stanford.edu/courses/cs448a-01-fall/lectures/lecture15/
[3] An interactiveenvironment for virtual manufacturing: the virtual workbench – http://www.sciencedirect.com/science/article/pii/S0166361598001043

Morsa said...

Marco,

entiendo todo lo que me dices. Simplemente creo que OpenGL no tiene tantos adeptos precisamente por las dificultades que presenta, entre ellas las que he mencionado.

Quizás no es la filosofía con la cual fue creado, pero la realidad es que el desarrollo en OpenGL te hace caminar de manera dificultosa a cada paso que das.

saludos
Manuel