Esto es interesante:

triangular un poligono es facil, al reves NO. Por facil me refiero computacionalmente.

Para triangular un poligono debes dividirlo recursivamente mediante "diagonales internas". Una diagonal interna es un segmento entre dos vertices no consecutivos que no se cruza con otro segmento. Al dividir un poligono con una diagonal interna te quedan dos poligonos que se van a dividir de nuevo; asi hasta llegar a un triangulo simple.

Crear un poligono CONCAVO a partir de un conjunto de triangulos es trivial y no se me ocurre para que puede servir.

Pero para formar un conjunto de poligonos CONVEXOS a partir de un conjunto de triangulos no se ningun algoritmo eficiente. Se podria construir un modelo de fronteras y formar subconjuntos de triangulos de manera sistematica ( N contra N ) y realizar un test de convexidad para cada uno. Pero te queda el problema de saber si es la solucion mas eficiente, ya que hay multiples soluciones. Se parace al problema de crear strips a partir de un conjunto de triangulos.

:)  

 Aun que  quizas sea matar moscas a  cañonazoa mira esta  web:

www.red3d.com/cwr/boids

Explica dinamica de grupos. Basicamente se trata de asignar furzas de repulsion y atraccion para crear comportamientos de grupos.

Puede que esto te sirva de inspiracion para encontrar la solucion que buscas.

enga  :lol:

                                Creo que el sincronizado vertical (vsync) no es lo mismo. El sincronizado vertical, si no voy equivocado, realiza una espera activa. Es decir detiene el proceso a la espera de que la targeta haya terminado de enviar los datos al monitor.

Pero como no estoy del todo seguro, seria interesante que alguien que conozca el tema nos lo aclare.                                

                                A ver si he entendido lo que cuentas. En mi caso, acostumbro a separar la logica del juego del render puro. Entendiendo como render todo aquello que dependa de GPU.

Entonces, supongamos que la logica tarda 5 mili-seg y el render otros 5 mili-seg

1seg / ( 5 mseg + 5 mseg) = 100 fps

esto significa que haremos 100 pasadas por el bucle de logica y otras 100 pasadas por el bucle de render. Si tenemos un monitor que refresque a 50 HZ (una mierda de monitor, pero los numeros salen mas facil), significa que no apreciaremos los cambios en la mitad de los renders. En definitiva desperdiciando CPU.

Si he entendido bien. La idea seria, por ejemplo, ejecutar el render una vez si otra no. De esta manera dedicariamos mas tiempo al bucle de la logica. Luego los FPS aumentarian, pero hay un poco de fraude pq en realidad se esta dibujando 50 veces por segundo.

en promedio el render pasa a costar 2.5 mseg

luego, queda 1seg / ( 5 mseg + 2.5 mseg) = 134 fps

Lo que no tengo claro es si el resultado queda bien, o si hay que sincronizar de alguna manera. Ya lo probare, y a ver que tal funciona.
:P                                

                                Al trabajar con triggers lo que he hecho yo es dividir el problema en dos partes:

1. La parte de la logica del trigger, el trigger en si. Es codigo puro que implementa la logica del trigger

2. Variables. Tengo tres tipos basicos, estas si se pueden manejar desde MAX pe.

tipos:
 - Regiones
 - Cronometros
 - Numerico
 
El trigger esta implementado mediante un lenguaje script y tiene acceso a las variables.

El esquema es muy simple, no creo que sea necesario usar un patron observador.