OpenGL en el renderizado en tiempo real de una simulación lattice. Resultados y reflexiones sobre la experiencia.

En el post de los métodos Lattice dije que iba a tratar de escribir un programa para visualizar mediante OpenGL los resultados de la simulación para ver como evolucionaban “en tiempo real”.

Captura de pantalla 2013-05-26 a la(s) 13.19.02

Una vez he terminado un primer intento debo pararme a sacar algunas conclusiones. La primera es que tengo que dedicar algo más de tiempo antes de lanzarme a escribir código porque luego tengo que andar tomando rodeos para hacer algo que de otra manera hubiera sigo simple por culpa de un planteamiento de las clases, métodos, ect.

La segunda conclusión que puedo sacar es que es mala idea mezclar dos conceptos distintos como son el solver y el render, ambos procesos deben ser tan independientes como sea posible, al menos en mi corta experiencia con OpenGL. Y me explico. La API de OpenGL (GLUT) que normalmente se emplea utiliza una función llamada glutDisplayFunc para llamar a la función que “dibuja” la escena, es decir:

</h4>
glutDisplayFunc( draw_scene );

Lo problemático de esto es que glutDisplayFunc obliga a que su argumento sea una función estática y que a la postre no puede tomar argumentos. Muchos comprenderán la gravedad de la implicación, al resto les muestro algo de código sobre cómo sería la función draw_scene:

void draw_scene(){
... //funciones que limpian la escena, que apuntan a un punto del espacio, etc.
glBegin( );
...// Identidades que componen la escena
glEnd();
solver_step(); //llamamos al solver para que realice n-iteraciones
glutPostRedisplay(); // actualizamos la escena.
}

Ahora lo vemos más claro, si draw_scene() ha de ser estática solver_step también ha de serlo,  y por ende todas las funciones que cuelgan de ella. Esto implica inicializar estáticamente variables fuera del main, clases, etc… todo muy feo, vamos.

Si queréis algo más de información podéis ver la pregunta y la discusión posterior en stackoverflow aquí.

Además de esto, es solver está limitado a hacer pocas iteraciones porque glutPostRedisplay() no obliga a actualizar la escena, sino que setea un flag para que cuando el sistema tenga un hueco -idle en la jerga- actualice la escena. Esto significa supeditar al solver al control del render; mala idea, pero la mala planificación nos ha obligado a ello.

La solución más correcta que veo a este problema es aproximar el problema desde la perspectiva multo-hilo. Tomando un hilo para el solver y otro para el render y compartiendo una variable global con los resultados de la simulación entre ellos.

Esta entrada fue publicada en Aerodinamica, C/C++, cfd, Lattice. Guarda el enlace permanente.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s