CDTExample

Este programa fue un prototipo para desarrollar el algoritmo de Triangulación Restringida de Delaunay. Este algoritmo forma una malla a partir de un conjunto de puntos con la particularidad de que se puede obligar al algoritmo a que ciertos puntos formen un lado de triangulo.
Fue desarrollado en  Visual C++ (MFC).

 

<

 

Los segmentos rojos fueron los lados que obligatoriamente tenían que formar un  lado de triangulo.

 

Resultado final en un programa de diseño lineal de obras públicas.

 

Para descargar el programa aquí.

Fly and SmoothFly

El programa Fly es una mosca que va desde el punto A al punto B por la cota más baja dentro de un Modelo Digital de Terreno, para así exponerse menos a los peligros que le pueden acechar.
Este programa lo desarrolle para implementar el algoritmo A*.  El problema que tuve para visualizar el camino generado por el A* es que iba a saltos, con lo cual, desarrolle otro programita el cual, usa un algoritmo para suavizar un camino A*.


Ambos fueron realizados en Visual C++/CLI.

Para descagar el programa aquí.

 

CityTex (Geo typical texture)

 

Hace un tiempo, en una entrevista me preguntarón por si conocía lo que era el geo type texturing. Basicamente es realizar la textura dependiendo del tipo de objeto que se encuentre en el terreno. Por ejemplo, si queremos realizar la textura de una ciudad, tendremos que saber que tipo de objetos hay en el terreno para aplicar la textura (edificios, parques,..)


Pues bien, al igual que me ocurrio con el simulador de tráfico que en su día me comento mi profesor de programación en cuando hice Equipos Informáticos, y desarrolle uno usando lógica difusa, he creado un pequeño proyecto, citytex, donde el algoritmo realiza lo siguiente:


- Genera un esqueleto de una ciudad en función del número de calles horizontales y verticales.

Aleatoriamente, las calles se inclinan en un sentido o en otro para darle un poco de realismo y no sea una cuadricula perfecta.

Y finalmente se insertan un número de edificios.


- Genera un bitmap con con la información de los objetos que se encuentran. En este paso, solo sabemos las carreteras (en azul) y los edificios(en amarillo).


- Despues, se pinta con el raton las zonas donde queremos que exista una acera, o un parque. Esto se podría sustituir con un algoritmo de rellenado de zonas, pero eso sería otro proyecto.


En el transcurso de su implementación, me he dado cuenta de algunas cosas que ya desarrollare en siguientes post, pero como adelanto, se refiere a la liberación de memoria y al pseudo-código.


La dificultad de este proyecto a radicado a la hora de texturizar las carreteras y generar el grafo interno. Se ha pensado de esta forma, ya que así, representándolo con un grafo, se podría con algoritmos de grafos, determinar que zonas podrían ser rellenadas con unos rascacielos y otras con casas más bajas. Los nodos mejor comunicados estarían rodeados de rascacielos y los de a las afueras, con texturas de viviendas.


Aunque mirando la textura que genera, posiblemente no sea muy realista, pero podría servir de base para futuras versiones. Por ejemplo, que el algoritmo tomase la altura de cada punto y la tomase encuenta para crear la textura.


Uno de los problemas de usar fotos aereas como texturas es su resolución, que debe ser muy alta. Cuando en un simulador de vuelo se está cerca del terreno, la textura, si tiene poca resolución se empieza a pixelar y aparece como no real, quejándose así los pilotos. Una solución para esto, es la creación de texturas proceduralmente, como en este ejemplo, aunque claro, queda mucho, mucho por mejorar, pero ha estado bien e interesante aproximarse un poco a la creación de este tipo de texturas.

Para bajar el cityText aquí.

algunos links sobre este tema.

http://www.helistart.com/addons.aspx http://ict.usc.edu/projects/military_terrain_for_games_pipeline/ PROCEDURAL TEXTURING
Most input datasets generally contain only geometry information, while some may contain rudimentary textures. The MTGP pipeline improves upon the dataset, procedurally applying geo-typical textures (dirt or asphalt, brick or stone sand, grass or concrete) to incoming geometry (roads, buildings and terrain).

 

 

Interprete de Ecuaciones


Desde hacía mucho tiempo, tiempos donde compilaba con el borland c++, me llamaba mucho la atención en poder representar gráficamente una fórmula matemática:

y = x*x+5
y= x*cos(x/2)

Pero tenía un problema, una vez escribía la función:

double eq1(double x)
{
return (x*x+5)
}

Ya no podía cambiar. El usuario, no podía escribir la ecuación que quisiera ver representada en la pantalla.

Hasta que me decidí a investigar este campo un poco y también a arrepentirme un poco más de no haber elegido la asignatura de libre elección "compiladores e interpretes" en segundo de la carrera. A si qué, empeze a mirar libros como "Engineering a Compiler" y "Modern Compiler Implementation in C". Ahí ví las gramáticas por la izquierda, que son las gramáticas más facil de implementar, con lo cual, mejor empezar por algo fácil. Y implemente está gramática:

S => E$
E => TERMINAL Eprima
Eprima => +TERMINAL Eprima
Eprima => -TERMINAL Eprima
Eprima => cos(E)
Eprima =>

TERMINAL => FACTOR Tprima
Tprima =>*FACTOR Tprima
Tprima =>/FACTOR Tprima
Tprima =>

FACTOR => NUM
FACTOR => ( E )
FACTOR => VARIABLE
FACTOR => cos( E )
FACTOR => sin( E )

Como se puede ver en el video, se pueden escribir variables (x, a,...) que a la hora de realizar la gráfica el programa, las va dando valores de un rango de -50 a 50 para realizar la gráfica.
Admite ecuaciones de dos variables, pero esto sería ya para realizar una visualización en tres dimensiones.

 

 

La implementación de este tipo de algoritmos, permite al usuario obrar con más libertad a la hora de interactuar con cualquier aplicación. En este por ejemplo, se permite experimentar con visualizar casi todo tipo de equaciones (que permita este simple gramática), pero en aplicaciones grandes, se podría por medio de comandos variables...es decir,..un mini-lenguaje, hacer más productiva una aplicación.