!!! Primeros Demos !!!!!

Hola a todos !!!

Me siento contento al anunciar los primero demos aparecidos del programa que ando haciendo.

Pero primero que nada e de pedir una disculpa a aquellos amigos que solo utilizan Linux, me temo que existe una parte del demo que solo funciona en Windows, por desgracia (o por suerte) ya tenia escrito un pequeño código en donde varios threads interaccionan, como en un principio se analizo la posibilidad (todavía no descartada por completo) de hacer la parte grafica en directX, estudie los threads de Windows en donde realice el susodicho código; En fin ahora tenemos la vista en Coin3d una librería grafica GPL en C++ completamente multiplataforma basada en open inventor. Pero con las prisas no e desarrollado la parte de los threads en alguna librería multiplataforma C++ GPL (creo será Boost).

Además pongo unos cortos en donde se ve el contexto de lo que estoy haciendo, para aquellos con no tienen idea y para los que la tenemos o creemos tenerla también, ya que una de las partes mas bellas de la ciencias empíricas son precisamente, los datos de fenómenos impresionantes, aunque una ves mas no se si se puedan ver en Linux.

OK a lo nuestro:

El archivo comprimido con los demos y videos lo pueden bajar de aquí, a la banda del proyecto les recomendaría ir siguiendo el texto antes de ver todos los .exe.
Los ejemplos los hice pensando en que los ven en las maquinas Dell mas nuevas del cubículo, o al menos en compus que tengan algún acelerador de video, si no es así, el demo 8.exe probablemente resulte estupidamente lento, y en general mis comentarios sonaran excepcionalmente optimistas casi rallando en el delirio :-p.

El primer demo (1.exe) mas que mostrar como funciona todo es para mostrar un error, todavía no e terminado bien la parte multithread del programa, así que en este demo se ve aparecer una excepción, esta excepción se da cuando el modelo llama al render de la vista antes de que la vista allá terminado de renderear la anterior iteración (la escena anterior), así que tenemos el fenómeno conocido como race condition, es decir dos threads quieren acceder a un dispositivo al mismo tiempo, en este caso a la función de rendereo.
Esto se da porque la gradilla es muy pequeña y el modelo recorre muy rápido todas las celdas y las modifica antes que la vista termine lo suyo, si no aparece la susodicha excepción en sus compus es por que tienen unas compus súper lentas jajaja, en fin.

El siguiente demo (2.exe) solo muestra la gradilla en la condición inicial, para que vean todas las opciones con que cuenta coind3d, esta es un vista genérica para trabajar demos, ya que muestra muchas mas cualidades de las que se muestran y necesitan en una simulación normal.
Por cierto, en la pantalla de programa, se ven unas letras que aparecen cada 3 segundos creo, simplemente son otros threads, del demo, para que sea mas evidente que se tienen otros hilos de ejecución además de la vista y el modelo, en estos casos, y aunque ahora no hagan nada son el controlador y el event manager

El siguiente demo (3.exe) muestra una gradilla de células de 250*250, de un automaton sincrónico  con bordes, con  la regla de cambio de estado cíclica de Cage, a de mencionarse que no se ha hecho ningún intento por optimizar el código, y sin embargo por el puro hecho de pasar de python  a C++ al menos en mi computadora se nota mucho la diferencia entre el demo de python de 30*70 y el 3.exe, todo esto ¡SIN LA TARJETA DE VIDEO!, con la tarjeta de video, la cual cuanta con 500 MB de video, aparece la excepción del demo 1. Además si tratan de mover o ampliar la imagen lo mas probable es que la excepción se deje ver, mas race condition.
Por cierto, cuando aparece la vista desplegada, todo el tiempo que se tarda en comenzar la “animación” se debe a que se esta calculando la estructura de la grafica (muy evidente en el demo 8.exe), en base a la topología y el tipo de vecindarios, me párese que esto será una de las partes que se tendrán que atacar de manera fuerte a la hora de llevar a cabo la optimización del código, aunque una vez creada la grafica, esta ya no cuanta con dimensiones, así que para cada iteración del autómatas simplemente se recorren cada uno de los elementos de la grafica y se pasa a la función de siguiente estado, así que optimizar esa parte se ve mas difícil, ya que solo se itera sobre un array.

El siguiente demo (4.exe) muestra las mismas condiciones que los anteriores solo que la gradilla es de 500*500, si cuentan con una tarjeta de video, es decir alguna que no sean los 4 MB o algo así que tienen las integradas a la tarjeta madre, pues verán por fin el modelo como debería verse siempre (si no lo mas probable es que fuera con el anterior).

Los siguientes demos (5.exe, 6.exe, 7.exe) muestra las mismas condiciones que el anterior
Solo que en el primero los bordes del tablero se han eliminado es decir tenemos un toro, aunque e de decir que el patrón se conserva.
A de decirse que con un simple cambio en el código se logra esto, vivan los objetos!!!!

topology->setDimensionNormalized(0);

topology->setDimensionNormalized(1);

Y el siguiente demo muestra todo igual excepto que el vecindario es un poco mas largo.

neighborhood = new TowerNeighborhood(2);

Y por ultimo el ultimo ejemplo de este párrafo es todo igual al del anterior párrafo solo que el automaton no es sincrónico, en donde tampoco se conserva el patrón.

Ya en el súper clabon el siguiente demo (8.exe) muestra las mismas condiciones que los anteriores solo que la gradilla es de 1000*1000, si cuentan con una tarjeta de video buena pues notarán, que con suerte al optimizar el código, la velocidad de este automaton no esta nada mal, con lo que el sueño de un 1000*1000 de manera fácil no párese tan lejano.     

Para estos demos puse las películas 1,2, y 3 esperando que vean cierta similitud entre lo muestreado y lo que queremos evidenciar con toda esta verborrea de modelaje computacional, en las películas se ven patrones de difusión de CAM entre células amebiodes de dictyostelium, estos hongos son unicelulares excepto cuando se reproducen, y para ello forman un pseudos tejido llamado plasmodio, y para organizarse sin un director, se ponen de acuerdo gracias a la emergencia de orden debido a la autoorganización característica de los sistemas fuera del equilibrio termodinámico ….. puf, mejor chequen en google al respecto que es muy largo el rollo o mándenme un mail y yo les mando bibliografía especializada.
Aunque si solo quieren saber más de dictyostelium acá esta la liga a la página de donde saque los videos.

El siguiente demo (9.exe) muestra un ejemplo que yo no programe y solo lo pongo acá para mostrar las bellezas de la librería y se puede ver que un agente que se encuentre cambiando de forma como se avía postulado va a quedar espectacular!! A ver cuantos aguanta al mismo tiempo.

El siguiente demo (10.exe) muestra lo mismo que lo anterior solo que le puse textura asociada, la texturas permitirán imprimir mucho mas realismo a las escenas las cuales se utilizan mucho en los videojuegos.

Asociadas a estos dos demos puse la película 4, que muestra a dictyostelium en otro estado de desarrollo.

--------------------------------------------------------------------------------------------------------------

Por hacer:

Como se ve apenas comenzamos pero algo es algo, dentro del contexto de los autómatas celulares falta vario por hacer, independientemente del contexto del software, tres variantes que me parecen interesantes ya que se soportan por algunas otras librerías de CA’s son:
Ver la posibilidad de ampliar la topología para que se puedan cubrir gradillas hexagonales y triangulares, supongo que en si esto ya se puede, es decir al fin y al cavo lo que tenemos al final es una grafica, pero se tiene que pensar mas a ver que honda.
Comenzar a desarrollar todo el viaje de combinatoria para la creación de los vecindarios.
Y la otra parte mucho mas “realista” se refiere a implementar la estructura de las celdas en bloque ya no solo enfocada a una celda, aunque suene redundante, ya que para implementar la dinámica de fluidos y gases en los CA’s y mantener la ley de conservación de la energía se utilizan los llamados CA’s en bloque los cuales agrupan varias casillas que son las que cambian de estado, y de esta manera se puede mantener la susodicha ley,  sin importar si el CA es en paralelo, es decir sincrónico o no.
En ambos casos también se podría modificar la vista para desplegar  hexágonos y triángulos. Lo cual no es muy difícil, y aplicar imágenes que se usan bastante en el caso de los autómatas de fluidos, como son flechas en ves de colores.

Con respecto al software falta establecer la estructura de excepciones y terminar de ajustar por completo la dinámica de los constructores y get y set métodos.
Empezar a buscar una herramienta para el profiling.
Empezar a documentar (aunque de manera interna el código esta bien documentado).
También me gustaría crear la grafica con la librería Boost ya que en estos momentos la grafica que se crea es simplemente un contenedor de structs los cuales tienen un pointer a la célula central, y el índice del comienzo y el final, estos índices son el comienzo y el final de los pointer colocados en un contenedor que tiene todas las referencias a partes de la gradilla y representan los vecinos de dicha célula.
Implementar las opciones de una y tres dimensiones en la vista y sin duda alguna muchas, muchas, muchas otras cosas mas.

Espero no se les sequen los ojos después de tanto choro, la neta un mensaje de vos ya me empieza a parecer tentador.

Suerte a  todos, y hasta la próxima.

<  Respuesta de reporte | REUNION URGENTE MIERCOLES 5 DE JULIO A LAS 18:00 HORAS  >