Bueno, al final me decanté por hacer una adaptación del algoritmo de 3D game engine architecture a XNA. Dicho algoritmo usa una división del terreno en patches de tamaño 2^n+1. Por tanto un terreno podrá tener dimensiones vertical y horizontal diferentes que sean múltiplo del tamaño de patch elegido. cad patch se gestiona como un quadtree donde cada nodo del quadtree puede tener hasta 9 vértices activos (Lo mínimo es tener 4 vértices y dos triángulos activos). Cada rama del quadtree se va refinando en un modo dependiente de la vista hasta un nivel de detalle diferente. Luego se ven las dependencias entre vértices y se determina si alguna rama requiere de un refinamiento extra para evitar roturas en el terreno.
En el algoritmo propuesto en el libro cada patch tenía su propia lista de vértices e índices que se gestionaba de forma independiente y que cambiaba en cada simplificación del terreno.
El algoritmo me pareció ineficiente por dos motivos:
1.- Utiliza una lista dinámica de vértices e índices que cambia con cada simplificación. Esto supone que o bien tengo vertex e indexbuffer dinámicos o bien utilizo llamadas a drawUserIndexedPrimitive, lo que significa tener que mandar en cada simplificación las nuevas listas por cada patch a GPU, lo que bajaba el framerate una burrada.
2.- Para dibujar el terreno tengo que hacer tantas llamadas a DrawUserIndexedPrimitive como patches visibles tenga el terreno en cada momento.
Para solucionar estos problemas hice ua modificación al algoritmo: guardo todos los vértices del terreno (de máxima resolución) en un VB estático (con lo que sus posiciones, normales y color quedan fijos). Luego lo único que hago dinámico es un indexbuffer global dodne los diferentes patches van añadiendo los índices que necesitan para dibujarse. Este indexbuffer es lo que se modifica en cada simplificación del terreno y es lo único que tengo que mandar a la gráfica cada vez que cambia la simplificación.
De esta forma además sólo necesito hacer una única llamada a DrawIndexedPrimitive para dibujar todo el terreno. Además no necesito reenviar la información de vértices cada vez que el terreno cambia.
Hasta ahora me va fenomenal con un fps constante de 62. Sin embargo ahora me encuentro un problema cuando quiero texturizar el terreno. Mi idea era usar algun tipo de texture splatting, sin embargo ahora mi problema reside en qué valor poner a las coordenadas de textura de mis vértices.
Para seguir funcionando con mi esquema necesito que las coordenadas de textura para los vértices sean fijas (he intentado utilizar coordenadas variables que meto en un vertexstream diferente dinámico y la actualización se hace totalmente ineficiente). Sin embargo no se me ocurre ninguna forma de salir de este inconveniente, porque los vértices que coponen el terreno en cada simplificación son diferentes y cubren zonas distintas.

¿Teneis alguna idea?

Gracias

Primero, saludos a todos:
Ando embarcado en el desarrollo de un juego de estrategia bastante sencillito y estoy divagando acerca de qué técnica de LOD sería la mejor para aplicar al terreno. Hasta ahora hago una carga simple de terreno a partir de un heightmap. En esa carga especifico la dimensión que quiero que tenga el terreno y la resolución vertical y horizontal del mismo en vértices/metro. Esto me deja al final con una malla 3D regular donde los vértices se distribuyen de manera uniforme.
Teniendo en cuenta que en un RTS normalmente la vista del terreno es una vista superior donde estaremos viendo gran parte del mismo en todo momento he considerado utilizar alguna técnica de LOD, para que en esos momentos en que tenemos una visión más amplia del terreno se simplifique la malla reduciendo el númer de polys. Si no utilizara esto me vería en el compromiso de elegir entre una malla de baja resolución (un número de polys aceptable para todo el terreno) que me permitiera manejar el escenario con comodidad cuando tengo una visión amplia pero que mostraría un nivel de detalle pobre si el usuario quiere acercarse a al acción; o bien una malla de alta resolución que me da detalle para distancias cortas pero que se hace inmanejable cuando el usuario se aleja para dar órdenes a las tropas.
He visto varios ejemplos del uso de ROAM, pero todos tienen un efecto bastante desagradable de 'popping' que hace que el suelo parezca panceta en una sartén. También he visto un ejemplo de Chunked LOD, pero que a su vez tiene otro efecto bastante desagradable en las juntas entre parches que hace que se vean esas costuras (en las juntas se arregla el 'cracking' del terreno con un corte vertical).

Como supongo que nos ocurre a todos, me gsutaría dar con una solución óptima, que me permitiera hacer un LOD sencillo (si es combinado con culling mejor que mejor) y que evitara esos efectos que al final hacen que el juego parezca 'cutre'.

Agradeceré cualqueir sugerencia.

¡Un saludo a todos!!

 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

 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.

 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

 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?

 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

 por cierto... alguna idea que alguien me pueda dar acerca de como empezar??? :P
quizas ara empezar no deba meterme en tantos detalle sy luego pueda ir refinandolo quien sabe auque me gustaria aclarar antes todo esto

 Pues veras jejeje mi istoria es unpoco desgraciada. Quiero hacer como proyecto de fin de carrera un pequeño motor gráfico que pueda presentar y lo cierto es que llevo desde el año pasao y me he leido ya bastantes libros acerca del tema , artículos, tesis acerca de programación gráfica, foros... un largo etcetera.
El caso es que con todo lo que he leido ninguno de los profesores del departamento d einformática tiene ni puñetera idea acerca del tema de gráficos y menos de engines y su funcionamiento por lo tanto nadie puede aconsejarme y me he quedado atascao ...¡¡antes de empezar!!! lo cierto es que cuando quiero comenzar a elaborara el proyecto y ponerme manos a la obra no arranco porque no se que punto de partida tomar. Que´ria empezar con el sistema de manejo de escena (así que recopilé toda la información qu tengo acerca de grafos de escena ,estructuras espaciales ,arquitectura de escenas...etc) para bueno desde ahí ir ampliando el motor con otras cosas como deteccion de colision, multitexturizado... etc
Pero como vesme encuentro upoco atascado porque no soy capaz d ejuntarlo todo para empezar. Quizás necesite unpequeño empujon o arranque para encarrilar el asunto pero no me llega jajaja y si no lo empiezo ya me voy a quedar sin tiempo
Te gusto mi triste historia? La verdad es q me hubiera gustado ver esto con más calma y tranquilidad y sin tanta presión pero así son las cosas lo que no quiere decir que me haga ilusión conseguir el reto jeje

 podrias aclarame un poco marcode como harias eso a lo que te refieres?

Y lo de tratar todo como una sopa de polígonos no creo que sea buena idea, yo usaría diferentes métodos según se trate de terreno, construcciones, habitaciones, objetos estáticos, dinámicos, etc.

¿Cómo propondrías hacerlo tu? cualquier opinion sera bienvenida de verdad ( siempre y cuando tengas ganas de onerla jejejeje) (ole)  

 mmmmm jajajaja si quizás unpoquito más. El tema es que quizás no tengo yo demasiado claro como se hace en la actualidad esto de la geometría estática. Intento pensar en cómo en uno d elos juegos comerciales que conozco pueden estar usandose las técnicas que voy viendo(soy un tio práctico jjaa) y quizás me lío más. El caso es que me encuentro con ciertas contradicciones.
Me dices que en un octree podemos encontrarns a nivel de poligonos y también podríamos introducir entidades ¿pero podemos estar usando ambas técnicas al vez?
El caso es q yo en motores como por ejemplo ogre3d no he visto nada que me indique que la geometría estática es cargada de golpe como un pegote de poligonos. En ogre el uso es muy directo : tu creas una entidad a la que le das un nombre por ejemplo Edificio y luego a esa entidad le asocias una representación que será la malla del edificio con todas sus propiedades. Luego además tienes distintos tipos de managers de escena : basados en un octree, en un arbol bsp... el caso es que todo en la escena se maneja como una entidad, no existe separación de lo que es dinámico y lo que es estático. Esto es lo que me confunde puesto que lo veo en una gran cantidad de articulos y libros es esto mismo. Existen entidades y ya está luego no se como puñetas se están manejando.
Yo he llegado a la conclusión que me estáis diciendo (creo) que es mejor manejar por un lado geometría estática que no cambia y por otro la geometría dinámica. Otra cosa es luego cómo este organizada esa geometría estática.
Podemos hacer que en un fuchero no svenga como una ristra de polígonos que cargamos y distribuimos en nuestro octree, o supongo que sería posible que viniera esa geometría dividida en entidades.¿ Porqué hacer esto? Pue por ejemplo para beneficiarnos del culling de oclusión (aunque supongo que también podría hacerse si tenemos polígonos sueltos). Ya que si tenemos un cierto numero de objetos dentro del frustum que hemos determinado puede que ciertos objetos esten ocluidos por entidades que hemos elegido como oclusoras por ejemplo.
Si tenemos entidades en geometría estática podemos también beneficiarnos de lo que es también la agrupación: definiremos el castillo como tres entidades tipo torre una entidad muralla una entidad foso y otra entidada fortaleza ( o quizás esto no es necesario si ya lo estamos tratando como polígonos repartidos en nodos del octree y es justo lo que estoy pasando por alto??)
Quizás no es tan necesario que la geometria estática este dividida en entidades y tengamos que saber a que entidad pertenece cada una... quizás eso es cosa del editor de escenas el permitirnos editar una escena a nivel de entidades para luego transformar lo hecho en una ristra de polígonos cierto? a lo mejor es lo que estaba confundiendo
¿qué opinais?
PD:Gracias por vuestras respuestas

 no estoy muy seguro de eso que me dices. Por ejemplo Eberly en su libro (lo nombro porque ya me lo han recomendado miles de veces) trata absolutamente todos los objetos del mundo como entidades separadas que luego pueden tener geometría asociada.
Por ejemplo tendrá un nodo edificio, que es un nodo de agrupacion del que cuelgan la habitacion uno y la habitacion 2 de las que cuelgan nodos que representan los objetos de esas habitaciones.
Eso es geometría estática y sin embargo los ha modelado como entidades separadas.
Además por ejemplo en el Lineage 2 si lo conoces he estado haciendo ciertas pruebas para ver si me aclaraban como el motor que usa este juego lleva a cabo la oclusión y la distribucin espacial ( como ves estoy un poco desesperao) me ponía contra una pared muy pegado y giraba la camara de tal forma que llega un momento que puedes ver lo que hay al otro lado de la pared (quizás un pequeño bug?) y ver también queé es lo que se ha ocultado y lo que permanece. Lo cierto es que por ejemplo una casa que debería estar al otro lado no es dibujada por el motor y es acasa evidentemente forma parte de la geometría estática mientras que otros elementos como la continuación de la pared al otro lado si están dibujados(quizás porque forma parte todo de la misma entidad?) así que esa casa debe estar tratándose como una entidad separada con posibilidad de ocultarse según la situación lo requiera (en este caso por oclusion debido a la pared)
De todas formas si trataras toda la geometría estática  como una sopa d epoligonos...¿si por ejemplo quieres quitar los poligonos correspondientes a una casa como lo harías? como sabes cuales son los poligonos que pertenecian a esa casa que cargaste en el escenario si estan en la sop aque mencionas?

creo que estoy dejando escapar algo por alto que no me doy cuenta

 a ver hay una cosa q no entiendo q tu me has dicho. Suponte que cada objeto cargado en la escena es una entidad q entre sus propiedades tiene la malla que estamos utilizando para ese objeto. Bien para empezar cual es el criterio que sigues para construir el octree?? Cada nodo tiene que tener ocho nodos hijos pero cuando dejas de descomponer en nodos hijos? muchos autores te dicen que pares de dividir un nodo en hijos cuando el numero d epoligonos dentro de ese nodo sea menor que un cierto número que se considera aceptable. Pero ahi ya estamos trabajando a nivel de poligonos.
O suponte esto otro. Suponte que tenemos un objeto en la escena que es un castillo. Ese castillo es geometría estática y es un único modelo mu grande de muchos polígonos y abarca pues un buen cacho de la escena y por lo tanto una gran cantidad de nodos del octree. Estará referenciado en todos ellos por tanto. De todas formas el castillo es una entidad demasiado grande como para ser renderizada de golpe siempre.
Intuyo que a lo mejor ahí es responsabilidad del modelador de la escena el no hacer ese tipo de objetos gigantescos para que el rendimiento no haga chof, estoy en lo correcto? es q es unpoco lioso todo esto.
Aun asi nos queda el problema de cuantos niveles hacer del octree y qué criterio seguir puesto que entonces tendrias que meterte en la malla de cada objeto eintersectarla con los planos del cubo que representa el nodo y ver cuantos poligonos caen en cad cubo del octree.... si metes mas objetos ademas habría que reconstruir el octree otra vez... lo que me parece muy costoso.

 Hola buenos dias tengo q escribir porque estoy hecho un lio acerca del uso de estructuras espaciales como los octrees o quadtrees en una escena y su integración en el grafo de manejo de la misma.
El grafo representa una jerarquía de nodos que se usa segun tengo entendido para relacionar jerárquicamente una serie de entidades que cargamos en la escena para que por ejemplo si movemos un nodo bicicleta por la escena se muevan los nodos hijos ruedas con ella sin indicarlo explícimtamente lo que veo una ventaja provechosa. También serviría esto para ,por ejemplo, hacer el culling de objetos de forma más eficiente y ta,bién la detección de colisión u sando bounding volumes en cada uno de los nodos.
Ahora bien, he oído también las ventajas que supone el uso de una estructura de organización espacial en la escena. Dividimos la escena en regiones espaciales de tal forma que si por ejemplo el frustum de visión no "toca" determinadas regiones, éstas y todos los polígonos que se encuentran dentro de ellas se pueden descartar para el dibujado. De esta manera eliminamos de entrada grandes porciones de escena para el dibujado y mejoramos el rendimiento. Ahora bien, ¿cómo combinar el establecimiento de una jerarquía entre los objetos con su organización espacial en la ecena? ambas cosas son totalmente independientes.
Me surgen muchas dudas con el uso de estructuras espaciales. Si metemos en nuestra escena un octree para manejarla sería necesario tratar a nivel de polígonos cada uno d elos objetos cargados en la escena para repartir esos polígonos entre las distintas celdas en q se ha dividido la escena. Sin embargo a nosotros lo que nos interesa es manejar la escena a nivel de entidades: no queremos saber que medio personaje esta en una celda espacial y la otra media en otra solo debemos de preocuparnos acerca del personaje no es asi?
¿Cómo integrara entonces en el grafo de escena todo esto?
Y ya no dig nada si encima me pongo  pensar en si sería posible manejar ciertas entidades de gran tamaño de una escena con sus propios octrees. Por ejemplo tener en la escena un terreno manejado por un quadtree y un  castillo manejado por un octree y luego unpoblado manejado por otro octree.... etc
Alguien puede aconsejarme? Por cierto , me he leido ya los libros de H.Eberley de Game Engine Architecture y también de Game Engine Design y no se si es que me he saltado algo pero no me han aclarado mucho en este aspecto
¿Alguna idea por favor? (nooo)