Hey, yo tambien me apunto al planet :P Pandora's Box

Trato de hacer un portafolio sobre el proceso de creacion de un engine para juegos de accion/plataformas 3D y mis pensamientos respecto el desarrollo de juegos. Lo unico que lo hago en ingles para practicar un poco, espero que no os importe :rolleyes:
Ultimamente lo tengo parado por examenes, aunque ahora que han terminado (y he terminado mi periodo de fiesta B) ) voy a seguir con el diseño.

 Creo que no es necesario usar BB para cada hueso (vertices asociados a el). Colisionar mallas dinamicas ya es de por si chungo como para encima hacerlo con objetos animados.
Yo optaria por usar BV primitivos (capsulas, elipsoides o cilindros) para colisiones entre objetos dinamicos, y contra triangulo o convex hull para los estaticos.
El tema de los tiros se puede solucionar con una jerarquia de BVs para saber en que parte ha tocado la bala.
Ahi quizas si seria bueno usar un BB por hueso (u otra primitiva) para hacer intersecciones con un rayo.

 Yo como mucho me compraria el orange book. Antes que comprarme un libro de opengl prefiero comprarme otros mucho mas utiles, como el archiconocido Real-time Rendering, el 3D Game Engine Architecture, el Mathematics for 3D Game Programming & Computer Graphics o alguno de diseño o ingenieria de software.
Hay tanta informacion sobre opengl en internet o implicita en alguno de esos libros que no creo que necesites comprar libros especificos de opengl, a no ser que te sobre el dinero.

[del juego]

 Me gustaria saber como meteis la parte de IA en vuestro engine. Aunque creo que la pregunta deberia ser mas general. ¿Que entendeis por IA orientada a juegos? Me refiero a nivel de que tareas desarrolla la IA.
Yo habia imaginado que el marco de trabajo son controladores para objetos de la escena, que puedan modificar la transformacion (posicion,rotacion,escala) o efectuar alguna otra operacion sobre el objeto, como añadir,modificar o quitar mas objetos de su jerarquia (sacar un arma) o cambiar de animacion (correr->saltar).

¿Que opinais? ¿Hay algo que me deje por el camino? Pensad que esto es solo el marco de trabajo, ya que cuando programe la IA del juego estara scriptada usando este framework. La accion de disparar seria ir metiendo diferentes tipos de controladores al objeto que maneja la IA.

 En la seccion SceneGraph tienes el codigo fuente de las clases Spatial (nodo abstracto), Node (nodo composite) y Geometry (nodo hoja) que son las que necesitas mirar. El punto de entrada es Spatial::UpdateGS(), y llama a funciones polimorficas de Spatial, Node y Geometry.
Tambien puedes mirar este trozo del libro 3D Game Architecture en donde explica como va el arbol (actualizacion de transformaciones/BBoxes) por si no te aclaras con el codigo, aunque es bastante intuitivo.

 Yo uso el metodo de actualizacion de WildMagic (de David Eberly, en geometrictools.com) para el arbol de BBoxes.
Cuando queremos actualizar las transformaciones de objeto, comenzamos por un nodo y calculamos la worldTransform basandonos en la del padre. Luego seguimos la recursion hacia las hojas. En el pase hacia arriba de la recursion, vamos actualizando el worldBound en base a los worldBound de los hijos. Cuando llegamos al nodo que ha iniciado el cambio, se propaga su worldbound hacia arriba.
De esta manera evitamos recalcular los bounds para los subarboles que no han sido afectados.
Yo solo guardo 1 vector para los extents desde el centro en las AABB, y 4 vectores en las OBB, 3 para las axis y 1 para los extents desde el centro. A parte tambien tengo el centro de la caja (pivote).
Tengo un metodo que calcula los 8 puntos y los deja en un array, prefiero no almacenarlo en el BBox para ahorrar espacio y llamarlo solo cuando lo necesite.

 Tu ejecutas la fisica en timesteps fijos, ¿no? Si por lo que sea el frame time es mayor que tu timestep, tendras que ejecutar mas veces la simulacion de la fisica, partiendo tu frame time en fracciones menores que el timestep. Se entiende, ¿no?
Si el frame time son 15 ms tendras que hacer 2 simulaciones de 7ms y 8ms cada una o hacer una de 10ms y en el siguente frame añadir 5ms al frame time (mejor la segunda opcion).  

 Ufff, vaya thread mas largo, no se porque aun no lo habia leido :P

Primero de todo felicitar a Novarama por el juego (que aun no he probado, pero he visto las fotos, videos y este bendito thread), y a ti personalmente Dani (ole) Me parece una actitud genial la tuya de compartir todo lo que sabes con la comunidad. Estas son las cosas que SI crean comunidad, lo demas son tonterias, y estoy seguro de que tarde o temprano revertira hacia vosotros.

Llevo todo el thread esperando postear para preguntarte lo que nadie ha preguntado aun. ¿Como organizais las escenas? Me refiero a la jerarquia utilizada, particionamiento espacial, scenegraphs, si usais diferentes vistas para cada tarea (ocultaciones, colisiones, fisica, IA, estados de render). Es un tema que me viene interesando mucho ultimamente (pasate por el foro de General Programadores) en el diseño del motor que tengo en mente.
Despues de resolver esta duda, ¿podrias decir, aunque sea a grandes rasgos, que tipo de colisiones utilizais? Si usais diferentes bounding volumes para cada tipo de objeto (esferas, AABB, OBB, elipsoides, cilindros, convex hulls, collision meshes), como por ejemplo elipsoides para objetos dinamicos (lease personajes), triangulos para el terreno (o versiones low poly), cajas o conex hulls para objetos estaticos (casas, arboles, piedras).
Sobre el sistema de render, veo que habeis optado por poner shaders como requisito minimo (Geforce4 para arriba), aunque supongo que usais la pipeline fija para algunas cosas (GF4 no tiene pixel shaders). ¿Como habeis diseñado el sistema de shaders? ¿Os habeis molestado mucho en ordenar los estados para acelerar el render? ¿Que tipo de estructuras usais?
En cuanto a la visibilidad, ¿tirais solo de frustum culling o usais algun sistema de oclusion hw/sw?

Eso por parte del engine. Ahora vamos con el juego. ¿Habeis optado por hacerlo todo data-driven? Es decir, intentar hacer lo minimo necesario hard-coded y luego tirar de XML y scripting con toda la informacion (ya has respondido en cierto modo a esto, pero me gustaria que ampliases un poco mas si cabe).
Me gustaria saber como organizais el guion del juego, es decir, la sucesion de eventos propios de la historia, sistema de objetivos y demas. ¿Como se integra todo eso con la IA?

Se que son un monton de preguntas, tomate tu tiempo y responde a lo que puedas o quieras.


Muchas gracias por compartir tu experiencia y sabiduria con nosotros. Una vez mas, espero que todos aprendamos algo bueno de esto. Mis mas sinceras felicitaciones.

 El mas generico suele ser el octree, o loose octree para objetos dinamicos. Os recomiendo la lectura de este thread en GameDev.

Luego esta el ABT, Adaptive Binary Tree, creo que Yann L habla un poco de él en ese thread. Es un arbol binario que elige el plano de particionamiento en funcion de unas heuristicas (funciones a minimizar) y permite guardar objetos dinamicos.
Aqui hay unos threads sobre ABTs para el que le interese:
ABT questions: construction and use
ABTrees questions
ABTs, relaxing them and other questions

Por cierto, de cada dia estoy mas seguro de que lo mejor es tener varias representaciones de los objetos de la escena, una para cada tarea: culling, colisiones y estados de render (aun se pueden añadir mas). Para el que le interese, esta pagina sobre scenegraphs esta muy bien.

Ahora mismo lo que tenemos es una jerarquía de bboxes que utilizamos para hacer el frustum culling y descartar geometría más rápidamente pero de todas formas eso dependerá de la profundidad de la jerarquía y por ahora la profundidad sólo suele ser de uno (utilizamos escenas muy simples donde no existen, por lo general, asociación padre/hijo) por lo que no hay demasiado beneficio en eso.

Hummm, no confundas jerarquia semantica o logica con particionamiento espacial. Un quadtree te divide el espacio, no tiene que ser una BVH del scenegraph logico de la escena. Pero bueno, vosotros sabeis mejor que yo como son vuestras escenas :P

er_willy, no se por quien iba la pregunta, pero te respondo por si acaso. Es un motor para un juego de accion/plataformas (no demasiadas plataformas) simple en 3d, con escenas de exteriores. Mas que nada es para aprender y tener una base solida para futuros proyectos. Seguramente lo mismo que Haddd y berserker, aunque no pretendo hacer tantas cosas, querria terminarlo en menos de 6 meses :D

 Si, hasta donde yo se, los HOM son una solucion software. Solo se deberia usar si no se dispone de occlusion queries por hardware. Aunque tampoco habria que abusar de ellas para no sobrecargar la GPU.
¿No usais culling para obtener un set de objetos potencialmente visibles? Si es asi (deberia), ¿que estructura espacial usais para obtenerlo?

Nosotros desarrollamos un sistema de portales y un sistema de Octrees. Pero lo hemos desechado todo, nos proponemos utilizar sistemas de oclusión. Pero no hay nada todavía :(

¿Y no podeis usar ambos sistemas y que se complementen? No creo que este reñido hacer una pasada por software para obtener una lista de objetos potencialmente visibles y luego otra de occlusion queries por hardware (o por software usando HOMs o alguna otra solucion).

Por cierto, estoy hablando principalmente de escenas de exteriores, nada de interiores. Aunque por otro lado, en interiores se estan desechando los BSPs (estilo quake y similares) a no ser en hardware 'antiguo', en favor de los octrees, ABTs o kD-trees.

[Culling]

 Culling.
Supongo que usare un quadtree para objetos estaticos, ya me dio buenos resultados con un renderer de terrenos que hice hace tiempo, aunque tampoco probe otras estructuras para poder comparar :rolleyes:
Para objetos dinamicos creo que optare por un loose quadtree, aunque tengo que investigar mas sobre como funciona exactamente la (re)insercion o relocalizacion de los objetos al moverse. ¿Alguien lo sabe?
Basicamente el culling no necesita tanta optimizacion, puesto que solo se trata de comparar con el frustum y obtener un set de objetos visibles para animarlos/dibujarlos.

Colisiones.
Aqui ya hay que tener un poco mas de cuidado, puesto que el numero de tests es mucho mayor que para el culling. Tengo entendido que un kD-tree resulta realmente efectivo cuando hay muchos objetos (mas de mil) entre los que buscar. Para testear objetos dinamicos vs. estaticos puede ser una buena opcion. Sino se puede usar igualmente un quadtree.
Por otro lado, he estado mirando el metodo Sweep-and-Prune (SAP) usando un radix sort mejorado y me ha parecido genial. Este nos puede servir para buscar posibles colisiones entre objetos dinamicos.

Mirando en los foros de Gamedev he visto que hay quien separa los objetos dinamicos en 2 categorias mas aprovechando la coherencia espacial: dinamicos estacionarios y completamente dinamicos. Una puerta seria un ejemplo del primer tipo, ya que tiene el movimiento restringido. Un personaje seria del segundo tipo, ya que su movimiento no tiene limites (hasta cierto punto, claro). No se hata que punto resulta beneficioso hacer esta separacion :huh:  

 Bueno, ya que el otro thread sobre scenegraphs no ha tenido exito, voy a ver si en este me llegan mas opiniones para decidir.
Al final he optado por tener una lista de objetos (prototipos) cargados en memoria, como un manager de recursos. Esto me permite tener instancias de los mismos para crear las vistas de la escena.
Una de esas vistas es la espacial, en la que tengo la organizacion jerarquica de las instancias en la escena.

Ahora tengo que decidir que estructuras usar para particionar el espacio y organizar la geometria.
Voy a separar la geometria en dos tipos: estatica, para geometria que no se mueve (no tiene nada que ver con animacion) y dinamica, para geometria que se mueve por la escena. Creo que tienen que estar separadas en diferentes estructuras, ya que tenerlo todo junto tiene bastantes inconvenientes.
Mi pregunta es, ¿que tipo de estructuras usais/usariais para cada tipo? La geometria estatica no necesita una ED optima en cuanto añadir/quitar nodos, simplemente ofrecer buen rendimiento al visitarla para culling o colisiones. La geometria dinamica necesita un poco mas de trabajo, puesto que cuando se mueve un objeto hay que recalcular la jerarquia de volumenes o incluso volver a añadir el objeto en el arbol para resituarlo en un espacio en el que quepa mejor. ¿Sugerencias?

 Sip, despues de leer un monton de cosas he llegado a esa conclusion. Los Shadow Volumes estan bien para escenas de interior en las que no se ven demasiados modelos que proyecten sombras. Da sombras bastante detalladas aunque hacerlas suaves es dificil (no se hasta que punto estan desarrolladas las soft shadows con shadow volumes). Para todo lo demas, Shadow Maps son la solucion (TSM o LiSPSM con filtrado).

Definitivamente implementare shadow maps en mi proyecto, puesto que los escenarios son de exteriores y puede haber muchos modelos lanzando sombras.