Motores graficos no basados en arboles?

[kokorico]

Hola, acabo de leer en algunos mensajes sobre motores basados en arboles.  En general, que yo sepa, es la tecnica habitual, es decir, es scene tree. Pero me preguntaba si hay alguna otra tecnica habitual para representar escenas ademas de ponerlas de manera jerarquica. Alguien conoce algun motor que use otras tecnicas?

[kraj0t]

Nada más con buscar en google game development scene management ya tienes este pdf.

Bsp, k-d tree, octree, quadtree, y otras cuantas técnicas.

En cuanto a motores que los usen, pues de bsp hay bastantes. De lo demás, no sé. Pero bueno, con esto que te he dicho ya puedes buscar, creo.

[kokorico]

No, si eso ya lo sabia. Solo que kd-tree, bsp, octree... son arboles. No se... pensaba que habia otros tipos de algoritmos no jerarquicos o bien con una gestion diferente. Solo era curiosidad.

[kraj0t]

Pos ni papa 

Lo que sí que te digo es que me flipa tu avatar 

[kokorico]

A todo el mundo le pasa cuando ve por primera vez un ciber-pollo 

[Hans]

Imagino que en Ogre puedes deshabilitar la gestión de nodos y hacerte tú una particular a tu gusto. De todas formas no le veo utilidad, es mucho más cómodo así

[kokorico]

Como ya dije, no es mas que curiosidad. Lo único que he encontrado hasta ahora son diferentes maneras de tratar arboles con el fin de que el recorrido proporcione diferentes ventajas, como mejoras en la ocultacion, la gestion, etc.

Pero me preguntaba si había otras maneras que os sonaran mas experimentales, sobretodo basados en los nuevos tipos de procesadores multithreading para consolas y para ordenadores.

[Ruben]

Hi,
este motor http://visualizationlibrary.com/documentation/pagkeyfeatures.html no usa un super arbol de escena sino en cada caso la estructura de datos que mas convenga (segun ellos, que no lo he usado nunca ).

Un saludo,
Ruben

[tamat]

robot chicken al poder

yo siempre he sido defensor de los arboles de escena, principalmente porque el artista trabaja en max usando arboles, y porque conceptualmente es mas sencillo.

sin embargo tengo unos amigos fanaticos de la optimizacion de codigo que insisten en que lo mejor es tener arrays separados para cada cosa, es decir, un array de camaras, uno de meshes, uno de luces, etc.

Y para resolver las transformaciones jerarquicas dicen que pones un modificador encima de los elementos que lo requieran, pero que conceptualmente es como si no existiera.

dicen que así consiguen mucha más potencia a la hora de iterar y renderizar

[kokorico]

Pero, como distinguen que tienen que dibujar? Es decir, tienes un array de camaras pero tienes que saber que dibujar.

[tamat]

no entiendo la pregunta, si te refieres a qué cámara usar pues la marcan aparte con un puntero supongo, si te refieres a qué objetos de la escena pintar pues todos los que esten en el array de meshes (aunque mas que meshes son nodos mesh de la escena)

[kokorico]

Pero ahi esta el punto. Tu sabes en un árbol que una vez seleccionado el nodo, lo pintas todo hacia abajo. Es la ventaja de la ordenacion jerarquica. Pero en cambio, si usamos arrays es para recorrer y pintarlo todo. Entonces mirando esto:

sin embargo tengo unos amigos fanaticos de la optimizacion de codigo que insisten en que lo mejor es tener arrays separados para cada cosa, es decir, un array de camaras, uno de meshes, uno de luces, etc.

Pero si tenemos por ejemplo un array de camaras, como lo gestionamos? Y uno de meshes? Como hacemos culling?

[tamat]

bueno, en realidad hay quadtrees para gestionar diferentes areas del mundo, pero insistía en que no anidan, tienen todas las meshes de un area en un array y a la hora de pintar vuelcan a otro array todas aquellas meshes que tienen que pintarse (por culling u otros temas).

el tema es que a la hora de pintar, todo esté lo más secuencialmente posible, para poder agrupar por materiales, instancing, etc.

por otra parte el tema de anidar tiene valor si tienes arboles muy profundos, pero en la practica acabas teniendo principalmente todo a maximo dos niveles, y para gestionar la fisica tener arboles lo complica mucho.

pero aquí ya hablo sin saber

[senior wapo]

Puedes tener una simple rejilla (array bidimensional o tridimensional) y dibujar lo que haya en las celdas que intersectan la cámara. El caso más conocido es el del Ray-Casting del Wolfenstein 3D pero básicamente cualquier escenario por pantallas/habitaciones.

Los motores isométricos de toda la vida entrarían ahí.

Otro ejemplo, son los motores de Voxels como los del antiguo Comanche o los motores experimentales del autor del Duke Nukem 3D. En su página tiene ejemplos de motores voxel muy chulos,

En visualización de volumenes para química y medicina también se usan estos arrays 3D. En la página de Iñigo Quilez tienes algun tutorial si recuerdo bien.

Los juegos tipo rail, como los viejos de carreras o incluso un pseudo 3D de acción lateral también se prestan bien a la estructura array, en la que cada celda del array tiene el tamaño de una pantalla/media y contiene una colección de mallas a pintar.