Bueno, la verdad es que soy un programador java nato, es mas, hace 4 años programaba en c++ "medio qué", ahi es donde empecé a programar orientado a objetos, antes habia hecho cosas sobre 3d (phong, gouraud) em soft, cuando empecé con c++ pase a decimadores de superficies (generadores de LOD dinamicos, a partir de norecuerdoquedocumento de IEEE Computer Graphics), y luego empecé con java, y acabé metido en el mundo de programar juegos.
Entonces empiezas a ver los juegos anteriores y los juegos que se crean ahora, estudias las diferencias y decides sobre la "adictividad" (que es lo unico que cuenta) de los mismos.

Yo he llegado a la siguiente reflexion:
Los juegos que se basan fuertemente en "velocidad" (quake, unreal) son juegos muy buenos en competiciones (cosa a la que nos dedicamos en L51) y ademas tienen una psicologia de juego claramente sencilla: "mata lo que se mueva, lo que no se mueva es un camper", pero son muy muy malos en juegos de "continuidad", es decir, por cada hora que alguien se ha llevado jugando a quake yo me he llevado 10 en un mud de texto, que es a lo que quiero llegar.

No se si alguien conoce la psicologia de un mud, estan programados en lpc, un frankenstein de c, que permite herencia y carga dinamica de clases y llamadas a metodos por nombre, ahi sta la potenxia :riendo:

El lenguaje lpc siempre ha tenido el problema que es semiinterpretado y que ni cristo lo llegó a dominar en la vida, dado que la especificación del lenguaje cambiaba del dia a la noche. En los muds, la gente programa las areas como entidades propias (con su codigo fuente propio), eso lo que permite que la gente extienda los areas del mud haciendo lo que le da la gana, sin verse atrapados por scripts.

Java ha venido al mundo de los juegos a sustituir a lpc en el mundo de los juegos no "freneticos" (evidentemente porque java no va a dar la velocidad necesaria para esos juegos), es decir, creo que Java tiene mucho futuro actualmente como lenguaje aplicado a juegos de estrategia por turnos y juegos rpg.

alguien me cuenta algo?, creo que es un tema importante.


                               

                                Bueno, esta claro que lo de construir engines de 0 no es solo una locura nuestra (mia y de la gente que se encarga de mi proyecto)


Respecto a tu problema:
El problema de colisiones y el mantener la lista de vertices transformados es un problema (como siempre) de numeros: "cuantos vertices tiene tu modelo?" y "como de finas son tus colisiones?" y "cuando vas a calcular las colisiones?"

Cuantos vertices tiene tu modelo?
Bueno, yo he trabajado en un engine3D en java (puro) y tenia que mantener la lista de vertices transformados (de local a mundo) para determinar la luz , visibilidad y cosas asi, bueno, el hecho de guardar la malla de puntos no era relativamente grave , y estamos hablando de lenguaje interpretado, asi que en principio no te asustes por eso...
recuerda que de todos modos, el tener las transformaciones de los modelos te puede ayudar en algunas optimizaciones (al menos, a mi me ayuda mucho en openGL).

Como de finas son tus colisiones? y cuando vas a calcular las colisiones?
Bueno, yo tengo toda la escena en un arbol de Bounding Spheres para los modelos móviles, entonces yo lo que intento es primero resolver las colisiones (fisicas, elasticas, predecibles) a priori, determinando por cada pareja de colisionadores que queremos tener en cuenta en que momento del frame se chocarán, donde estarán en el choque y cuanto tiempo les quedará en ese frame para moverse, asi soluciono las colisiones a priori ( no me hace mucha gracia los calculos del tipo: ya nos hemos chocado, tenemos un objeto dentro de otro y tenemos que ver hacia donde han salido los objetos) , bueno el proceso es "algo" mas complejo, pero basicamente muy por encima es asi. Finalmente, sabiendo donde estan las esferas al final del frame, ya tenemos la transformación concreta de ese colisionador.
Ya se que parece un poco raro, pero he trabajado principalmente en engines3d en soft puro sin uso de librerias opengl o directx y me molesta un poco el hecho de que el uso de esas librerias corte la iniciativa del tipo "yo quiero eliminar mis caras ocultas y hacer mi culling yo solito", y luego verte atrapado en un punto en el que es necesario pensar como si no tuvieras aceleradora.

perdon por lo largo ,pero estoy un poco empanado (y espesito) hoy :sonriendo:


                               

                                Bueno,un bounding Cylinder es un buen objeto mientras no lo rotes, y la verdad es que tiene utilidad solo para englobar a un modelo completo (p.e. MDK2 lo usa para todo el modelo , no para cada una de sus partes).

Luego la colision dinamica (cuando digo colision dinamica me refiero a saber donde colisionaran y cuales seran los puntos de colision) entre dos cilindros que se mueven cuando su orientacion no es 0,1,0 me da hasta escalofrios :sonriendo:

Una cosa que hay que tener en cuenta es las finalidades que tiene el contruir un Bounding loquesea para un modelo, que son:
Resolución rapida de colisiones.
Resolución rapida de visibilidad (contra frustrum o lo que sea).

En ambos casos el usar un bounding (a partir de ahora B) no sirve para asegurarte que un objeto lo ves o colisiona , sino para todo lo contrario, es decir, para eliminar de tu lista de objetos los que no ves o no colisionan, es decir, sirve para descartar, no para asegurar.

Ahora me paro, pienso 30 segundos en el ultimo parrafo y yo llego a la conclusion que el hecho de que un arbol de B esferas es una buena aproximacion del problema, me baso en:

1.- No hay que rotarlas, solo mover el centro a medida que el modelo se mueve
2.- Los datos que hay que guardar de ella son el centro y el radio , 4 float (muy poco)
3.- Los algorimos para calcular sumas de esferas y cosas asi son bastante simples y de codigo bastante rapido
4.- Las colisiones dinamicas tambien son facilmente calculables


Que tal la idea:

- Contruir hibridos AABB con B Spheres:
por ejemplo, tener el modelo completo en un AABB y las partes interiores del modelo como B spheres, asi los descartes de colisiones en primer nivel serian mucho mas rapidas (choque rocket vs modelo completo) y las de segundo y n-esimo nivel mas aproximadas (choque rocket vs cabeza, rocket vs pecho)
y en el caso mas extremo, pues a colisionar triangulos contra triangulos.

                               

                                A ver que opinais sobre el coste de implementar estos tipos de estructuras y la calidad del resultados.

Tenemos que un Arbol de Bounding Spheres es muy facil de obtener, (incluso se puede construir en tiempo de ejecución), y es relativamente facil realizar operaciones de colision tanto a posteriori como a priori (antes del momento de colision, obteniendo en que momento se realizara la colision), en contra tiene que una esfera puede no aproximar muy bien un modelo como una espada o como un brazo. (se realizan raices cuadradas en los algoritmos de colisiones)

Los AABB son bastante mas faciles de construir, y el arbol muchismimo mas rapido de reconstruir cuando la jerarquia de objetos cambia, pero aproximan aun peor (si es posible) la geometria de un objeto, y ademas su volumen varia mucho cuando el objeto rota en cualquier eje.El calculo de colisiones es bastante simple tambien. (sin raices cuadradas)

Los OBB son los que mas aproximan la geometria real del objeto y rotan y se mueven junto con ella, sus desventajas son que aunque el calculo de colision a posteriori es relativamente "computable", las colisiones a posteriori son practicamente un infierno, con bastante computacion (sin raices cuadradas).

Alguien opina?