Combinar Espacialidad Con Jerarquía

[Zaelsius]

 El problema es que considerar "hacer un motor" como una meta, sin tener en cuenta que es sólamente una pieza más de una aplicación, suele ser un error. Precisamente porque quizá no te has planteado para qué vas usar el motor, no sabes por donde empezar. Si tu meta fuese hacer una versión simplificada del Quake, sabráis por donde tirar. Si quisieses hacer un RTS, tambien tendrias una idea de lo que hace falta. Ahora.. "hacer un motor".. es algo difuso, ya que puede ser tan simple, complicado, específico o general como uno quiera.

Mi consejo es que te marques un objetivo más concreto.

[eduwushu]

 entonces lo que me quieres decir es que si tuviera en mente un tipo de juego o aplicación que darle al motor tendría más clara la formaen que quiero hacer las cosas?realmente yo cuando pienso en cómo debería hacerlo estoy pensando en juegos comerciales como ya he dicho y pienso en si la forma en que estoy concibiendo el disñeo permitiría hcer untipo de juego similar pr siempe me surge algo que no termina de encajar y que me impide diseñar el sistema de manejao de escema de una vez.
De todas formas si concreto cual sería el consejo que me darías para comenzar el desarrollo? desde el punto de vista de tu experiencia por donde deberia comenzar? (por lo menos para tenerme a algo a lo que agarrarme)
Se que muchos del foro estais haciendo tambíén proyectos similares asi que si teneis algun consjillo siempre sera bienvenido o contame vuestra experiencia personal. Gracias y enhorabuena por el foro este que hay gente mu maja

[zupervaca]

 Lo que quiere decir ZaelSiuS es que no existen motores que vayan bien con todos los juegos, cada juego tiene unas necesidades, sabiendo que juego o aplicacion quieres hacer sabras que necesidades debe cubrir tu motor.

[eduwushu]

 por lo tanto lo que tengo q tomar es una decision acerca de cómo debería hacer las cosas y manejar la geometría en mimotor sabiendo esto no? hombre más o menos de lo que he intentado informarme es de como lo ha hecho las distintas personas que se han embarcado en algo de esto como yo para ver posibilidades y aprender de errores de otros pero comohabeis visto pues no he conseguido llegar a mmuchas conclusiones. Si sabeis donde podria ver con claridad como lo han hecho ciertas personas su manejo propio pues guay sino intentaré tomar una decisión por mí mismo y de esta forma ve´re hasta donde puedo llegar.
Por lo tanto hasta ahora tengo dos podsibilidades segun lo que he entendido:

          +Bien podria elegir manejar como entidades la geometria estática (con todo lo que ello supondria y su dificultad)
          +Bien podria considerar es ageometría como una ristra de polígonos que manejo con un octree

Luego deberia de ver como hacer la oclusion y deteccion de colision en cada caso etc etc o qué características debería incluir según lo que quiera para el tipo de escenas que tenga que manejar con el motor ¿cierto?

[BeRSeRKeR]

 

por lo tanto lo que tengo q tomar es una decision acerca de cómo debería hacer las cosas y manejar la geometría en mimotor sabiendo esto no?

A no ser que te pase como a mí que prefiero programar motores antes que juegos, porque realmente lo que me gusta más es desarrollar efectos y demás "pijaditas". En ese caso no te hace falta ningún sistema de visibilidad salvo, tal vez,  algo tan simple como el frustum culling. Aunque crear sistemas de determinación de visibilidad también tiene su gracia. :D

Saludos.

[eduwushu]

 Bien he estado pensando en el tipo de escenas que me gustaría estar manejando y con ello intentar pensar qué es lo que más me convendría hacer y aquí dejo unas reflexiones para que opineis:

Bueno supongamos entonces que vamos a hacer un manejo de la geometría estática base como si se tratara de un conjunto de polígonos que podemos dividir según el uso de texturas que hace cada uno de ellos en subconjuntos y que podemos además distribuirlos en los nodos de un octree que utilizamos para el manejo de la escena.
Sin embargo un escenario no solo se va a componer de geometría inmóvil totalmente. Supongamos así por ejemplo una rueda de noria, puertas,ascensores,pasarelas que se mueven... etc
La probabilidad de encontrar un gran numero de items de este tipo en una escena es elevada correcto? Como deberiamos llevar a cabo el control de este tipo de elemntos?? No son los elementos dinámicos más problemáticos como por ejemplo un personaje o un enemigo dentro del escenario que tienen "libertad total de movimiento" por el espacio del escenario.Están localizados en zonas concretas del mundo con movimientos más o menos limitados. Sin embargo estos ya no podemos considerarlos dentro de una sopa d epolígonos puesto que será necesario su manejo individual y su movimiento.
Sin embargo si pensamos en incluirlos en el grafo de escena que por ejemplo podriamos estar usando para los personajes dinámicos la mayoría de ellos como cada una de la spuertas no estarán ligadas a nada, y colgarán directamente del nodo raíz del grafo provocando así que tengamos un grafo extremadamente plano que casi estaríamos utilizando a modo de lista. De tal forma que para comprobar por ejemplo colisiones de nuestro personaje rincipal con el entorno comprobaríamos la colisión con lo spolígonos del nodo del octree en el que nos encontramos y además tendríamos que comprobar la colisión con cada uno de este tipo de objetos puesto que no los tenemos localizados espacialmente. Sin embargo si supieramos que ciertas puertas estan localizadas dentro de un edificio concreto en una habitación concreta sólo las tendríamos en cuenta cuando el personaje estuviera proximo a dicha habitacion no se si me entendeis y por lo tanto conseguimos eliminar gran cantidad de comprobaciones con otro elementos dinámicos que puede que se encuentren muy alejados de donde se encuentra realmente nuestro personaje y que por lo tanto serían inutiles. En parte esta ahi donde veo la necesidad de tratar de alguna manera la geometría estatica no como un todo compacto sino como algo jerárquico que pueda llegar a aorganizarse espacialmente: sabemos que tenemos en la geometría estatica un espacio abierto que pueden ser unos jardines donde tenemos varias torres. En dichas torres hay unas pasarelas que tienen posiblidad d emoverse si se acciona un mecanismo o palanca del escenario. El espacio del jardín y las torrees son geometría estática pura que según me habéis dicho podríamos manejar con una ristra de polígonos perfectamente... que alegría que alboroto (ole) .Bien,tenemos también ahoralas pasarelas que están en extremos opuestos del jardín y por tanto separadas espacialmente y que son entidades que podríamos llamar pseudodinámicas (tienen posibilidad de moverse pero en un espectro reducido) de tal manera dispuestas que si estamos colisionando con una es imposible colisionar con la otra por ejemplo. Sin embargo si las ponemos en el grafo como son independientes tendríamos que hacer la comprobación contra las dos aun sabiendo que no podenos colisionar con las dos a la vez, este problema se deriva de no tener ninguna forma de localizarlas espacialmente.

¿Existiría la posibilidad de además asociar esas entidades semidinamicas a los nodos del octree junto con los poligonos de la geometría estatica para localizarlos espacialmente y evitar hacer comprobaciones así con todos ellos?¿Qué opinais o qué tipo de soluciones se os ocurren?

PD : espero no estar dando mucho la tabarra  auque no se vosotros pero yo asi toy aprendiendo mucho jejeje (ole) , muchas asias

[eduwushu]

 Otro ejemplo que se me acaba de ocurrir: ¿Qué pasa si quieres aplicar LOD a un elemento de la geometría estática como por ejemplo podría ser una estatua? Ahí ya no puedes si se cargó en la escena como un conjunto d polígonos sin más puesto que tendrías que buscar aquellos polígonos que pertenecían a esa estatua y sustituirlos por otros polígonos que siguen representándola pero que son menos cantidad.
¿Ves? es que segun voy pensando voy encontrando cosas que me rompen el esquema anterior que tenía planificado.

[AK47]

 Yo dividiria entre geometria estatica de la fase (paredes, suelo, escaleras, etc) y entidades estaticas del mismo. Lo de trabajar a nivel de poligonos se haria en la fase, todo lo demas serian entidades. Es decir, en este nodo del octree (o quadtree) tengo estos poligonos y tambien estas entidades. Como no todas las entidades van a estar en un unico nodo, puedes usar los "trucos" que se han comentado anteriormente, como asignarle el numero de frame o un booleano de "procesado", para ver si ya esta en la lista de dibujado o no. Para las entidades dinamicas puedes usar otra estructura, por comentar otra idea.

Tambien quiero comentar que, aparte de pensar para que tipo de juego sera el motor, hay que pensar en como se creara el contenido: puedes hacer el motor del Quake, pero si hacer fases para el (poner entidades, identificar portales, etc etc) es mucho trabajo, pues el motor, por muy bueno que sea, ya no vale tanto (siempre desde la perspectiva de un pequeño grupo de desarrollo, si eres Square y tienes 250 empleados/esclavos es otra historia :D)

[eduwushu]

 de todas maneras estoy pensando que también será necesario identificar donde se encuentran espacialmente las entidades dinámicas porque a pesar de ser dinámicas tenemos que saber en qué región espacial se encuentran para eliminarlas cuando sea necesario.
He entrado en una página muy curiosa que es la página de desarrolladores de valve y he estado viendo como se estructuran las esceas en el source engine. Por lo que me he podido enterrar no tratan la geometría de la escea como un buffer de polígonos extragrande que luego dsitribuyen sino que dividen la geometría en distintos tipos: por unlado tenemos objetos inmoviles de la escena, geometría estática pura de la escena que además creo que se subdivide en trozos más pequeños cada uno como si fuera una entidad (como si el escenario se contruyera a partir d piezas como unpuzzle), objetos dinamicos, objetos ragdoll para personajes....etc
Cad vez que veo algo nuevo me lio más jajajaja en fin estoy unpoco perdido

[marcode]

 
Yo también creo que es lo mejor eso, lo mismo que tenias pensado, pero a nivel de entidades, no de polígonos. Aquellos objetos que sean demasiado grandes como un edificio, murallas, o un terreno, la divides en partes manejables.

En cuanto a los dinámicos, si consideras que en la jerarquía del escenario tendrás objetos padre que serán comprobados por primera vez, no veo ningún problema en considerar a las objetos animados también como padres, estos a su vez pueden tener asociados otros objetos más pequeños, como armas o herramientas, o incluso otros objetos animados.

Puedes pensar que el coste de comprobar tantos objetos animados puede ser grande, pero yo creo que puede ser igual o menor que el tener que asignar continuamente el objeto a la parte de la escena correspondiente.

No se, es una idea a ver si podemos aclaramos un poco más esto, yo en tu lugar lo simplificaría todo un poco más, creo que estás metiéndote en cosas demasiado avanzadas, y en las que hay que tener todo muy claro, tener una cierta experiencia, para resolver la cantidad de problemas que pueden surgir.

Aún así están bien estos hilos, como dices se aprenden cosas.

[_XUTI_H_]

 A ver, yo de esto la verdad es que no tengo mucha idea ...
Los nodos de particion espacial podrian ser:

+ (en caso de exteriores)Entidad escenario: un octree (o quadtree p.e. para terrenos) para tu geometria estatica. La información de los nodos hojas serian los poligonos o primitivas de polys que forman la geometria. Debes saber que esto te puede servir para varias cosas: si calculas el/los nodo/s (del octree/quadtree) donde estaria un objeto mobil puedes reducir todas las colisiones a comprobaciones con los poligonos(o trozos de ellos) que contienen el/los nodo/s. Si recorres ordenadamente (no digo que sea facil) los nodos respecto al punto de observación puedes elegir "ocluders" y dibujar en un orden correcto, evitando, al menos, la comprobación de z-buffer(aunque puede que si que te interese guardar el valor z-buff del pixel dibujado) y permitiendo pequeñas aprox. a los LOD. Un culling rápido y efectivo es casi trivial con este sistema.

+ los objetos estaticos? -->Entidad objetos_escenario: otro octree, esta vez con nodos entidades, que referencien a los nodos objetos que contienen su geometria(si tienes 8 mesas iguales, es tonteria tener 8 vece definida la misma geometria, recuerda que son grafos son aciclicos). Sirve para lo mismo pero con objetos entidades.

+ objeto estatico interior: puedes utilizar bsps de distintos tipos, portales, etc. si quieres unos interiores optimizados(PVS, colisiones rapidas, etc...). En teoria podrias colocar un interior como un objeto más de del octree de objetos estaticos, siempre que controles bien como se verá desde "fuera" ese objeto(claramente deberias colocar una puerta para entrar/salir).

+ objetos estaticos "grandes": entidad que se pareceria, y mucho, al octree gastado para la geometria de escenario. Puedes dividir la geometria de tu objeto en otro octree que encierre solo tu objeto.

+ objetos dinamicos: yo utilizaria un kd-tree o adaptative octree. Cuesta aprender e implementar más cosas, pero seguro que se notaria en el rendimiento. Si quieres tener herencia debes contemplar que los objetos hojas deberian ser los nodos padres, no hijos sueltos. SI por ejemplo un personaje está en una subdivision pero su mano, con el arma esta en la contigua, (esta es mi opinión personal) yo colocaria una entidad padre(personaje) en las dos subdivisiones. Al dibujar debes saber que aunque veas las dos subdivisiones, solo debes dibujar una vez la entidad.

****** Ahora yo recorreria el grafo: --> si encontramos:

+ ESCENARIO EXTERIOR --> formado por octree ---> adelante, dibujalo.

+ Nodo CGS (transformaciones afines), nodo control, nodo LOD, --> ejecuta y continua con los hijos (en caso de LOD p.e. selecciona el tipo de entidad, etc.)

+ Nodo geometria ---> dibuja

+ Nodo octree para objetos --> (solo se me ocurre esto!!!!) puede que estos tengan diferentes materiales, etc. Podrias construirte un (mini grafo) asociando conjuntos de objetos que se determinan visibles o potencialmente visibles que compartan materiales y texturas para no tener que ir cambiando el estado constantemente (suponiendo que cada entidad que tenga hijos comparta materiales y texturas con ellos, solo incluye la entidad padre en el grafo) . Luego recorres este grafo y cada entidad se dibujará (si la entidad tiene hijos, estos se recorrerán, aplicando las diferente transf. hasta llegar a los nodos hojas y dibujarlos: como ves, si lo estudias y planificas, podrias tener jerarquias de objetos mobiles que estén referenciados en un arbol de partición).

**** Con las colisiones yo haria 3/4 de lo mismo: mirar que colisiones con geometria puedes tener mediante el octree para reducir calculos con poligonos no alcanzables desde tu subdivisión, y repetirlo en el arbol de objetos dinamicos y estaticos. Deberias integrar tu sitema de detección de colisiones o tener formas de obtener las estructuras de datos de los arboles de subdivision espacial desde tu modulo de fisicas o loqueseaquequierashacer.



BUffff... no se si te he aclarado algo. La verdad es que creo que podria ser bastante general y medianamente rapido, de todas formas hay cosas que me las he imaginado yo, no sé si hay formas mejor de hacerlo  :huh:

Puede que tb haya soltado alguna barbaridad, si es así, y alguien puede corregirme, que por favor lo haga y así a ver si aprendo un poquito yo tb. Lo unico seguro es que esto tiene que implicar un curro de 3 pares de c*j*n*s!!!!

Bueno ... animo, suerte y paciencia.
Salu2

Casi edit: a veces he puesto subdivisión y queria decir partición, que esto no te "ralle" más todavia.