Stratos: Punto de Encuentro de Desarrolladores

¡Bienvenido a Stratos!

Acceder

Foros





Scene Graphs

Iniciado por tiutiu, 03 de Enero de 2006, 07:23:45 PM

« anterior - próximo »

tiutiu

 Bueno, siguiendo con mis threads sobre diseño, aqui va uno sobre grafos de escena (SG).

Primero un poco de introduccion siguiendo el patron MVC. Por un lado tenemos una lista con los objetos de la escena, nuestro modelo. Luego tenemos los SG que son nuestras diferentes vistas.
Nuestra vista base es un SG que guarda relaciones de dependencia entre objetos (referenciados de la lista), nada de transformaciones ni bounding volumes.
Ahora hay que definir las vistas que vamos a usar. En mi opinion antes hay que definir que operaciones vamos a realizar sobre las vistas.
Esto ya depende de cada motor. En mi ultimo proyecto tenia una unica vista que me guardaba la transformacion y el bounding volume en cada nodo. Este SG lo usaba para actualizar la transformacion y la jerarquia de bounding volumes (BVH) cada vez que movia un objeto. Tambien lo usaba para el culling, obteniendo una cola de objetos a dibujar que se pasa al renderer. No habia ni colisiones, ni fisica, ni animacion, asi que no lo tuve en cuenta.

Despues de leer un poco sobre el tema, he visto que se puede hacer mucho mas eficiente.
Actualizacion de la escena. Utilizaria un arbol n-ario normal y corriente, una vista basica que guarde en cada nodo la transformacion. Simplemente cuando se modifica un nodo, su transformacion se pasa hacia las hojas y se va actualizando la transformacion global de cada nodo.
Rendering. Podemos tener un arbol con prioridades en cada nivel para ordenar los objetos que se van a dibujar en funcion del material (algo como lo que se habla en delphi3d sobre ordenacion por estados).
Culling. Habria que ver que estructuras espaciales van mejor en funcion del tipo de escena. He leido que algunas van muy bien para geometria estatica (octree/quadtree/abt), y otras para mantener geometria dinamica.
Colisiones. Seguramente con usar las mismas vistas que para culling seria suficiente, aunque teniendo en cuenta que solo colisionan objetos dinamicos contra dinamicos o estaticos.

Habria que usar el patron Observer para notificar a las vistas de los cambios en la lista de objetos (adicion/eliminacion de objetos) y viceversa, si cambia algo en una de las vistas, hay que hacerselo saber a la lista para que actue convenientemente (notificando a otras vistas implicadas p.e.).


Y bien, ¿que opinais? A parte de que el sistema pueda ser demasiado complejo y todas eso, el caso es que se usa y es muy flexible. Siempre puedes tener una simple vista como hice en mi anterior proyecto, pero si defines un sistema abstracto te da pie a reusar del codigo (lo mas importante) y futuras ampliaciones.

¿Como organizais vosotros las escenas?
b>:: Pandora's Box project ::
Notas e ideas sobre desarrollo de engines para juegos

ethernet







Stratos es un servicio gratuito, cuyos costes se cubren en parte con la publicidad.
Por favor, desactiva el bloqueador de anuncios en esta web para ayudar a que siga adelante.
Muchísimas gracias.