Representación de Terrenos Digitales. LOD.

[JL10]

(Con objeto de organizarnos mejor, pues creo que el tema de Terrain Rendering da para mucho, he pensado que podemos crear hilos especializados para no dispersarnos en los distintos aspectos a tener encuenta. ¡No os parece!)

Es cierto que el concepto LOD (Level of Detail, para los que somos novatos :shock: ), es fundamental para representar extensiones grandes de terrenos. Cada año hay nuevos algoritmos que superan a los anteriores. (No hay más que echar un vistado, para los que aún no lo conozcan, a la selecta relación cronológica que ha hecho Ben Discoe en http://www.vterrain.org/LOD/Papers/index.html ). Pero después de entretenerme en leer los distintos papers, sin mucho detalle, hay que decir la verdad..., no sabría por cual decidirme. Posiblemente escogería alguno de los más modernos, pero quizá no sea necesario. No sé cual es el más apropiado, creo que debería ser según la necesidad. Y esa es mi primera duda con respecto a los algoritmos LOD.

¿Que criterio,o criterios,hay que plantearse antes para decidirse por un algoritmo u otro?. ¿Hay que implementar varios y experimentar?. ¿Se deben tener en cuenta aspectos como:

- dimensiones del escenario y resolución del MDT,
- Tipo de orografía del terreno,
- consumo de memoria,
- bytes por heixel,
- frames por segundo,
- velocidad de movimiento de la cámara y tipo de vuelo,
- vuelo a alta/baja altura y tipo de vuelo (acrobático o tranquilo)
- número de operaciones internas del algoritmo
- tipo de uso de la aplicación (simuladores, juegos, GIS, turismo virtual,...)
- etc, etc.?

¿O es indiferente, y es cuestión de escoger uno u otro algortimo según la dificultad personal para entenderlo/codificarlo?

(Espero que neophox nos siga ilustrando...) :wink:

[zupervaca]

Si quieres solo implementar uno deberias de decidirte por el mas flexible, no obstante yo implementaria varios, busca la manera de hacerte una clase base abstracta que permita controlarlos de una forma generica, luego deriva y comienza a implementarlos, incluso yo te aconsejaria hacer una clase base para esta clase base que podria ser por ejemplo terreno, etc.

[neophox]

Como te dice zupervaca, una buena opcion es implementar varios. Puedes empezar con el que mas sencillo de implementar te resulte, aislandote del resto de cosas, ni paginacion ni texturas ni nada, te diria que ni cargar terreno, createlo procedural. Libnoise es una libreria que puedes utilizar para generarlo sobre la marcha.
En cuanto a criterios para decidirte por uno u otro, yo no sabria decirte, leete los pros y contras de cada metodo (tampoco hace falta que te los leas todos y cada uno, muchos son copias de otro con pequeñas variaciones) y con ello decide. Entre las implementaciones que he visto yo me iria mas por aquellos con mallas regulares y buscaria minimizar el efecto popping al cambiar de nivel de detalle.
A mi el que mas me gusta es geometry clipmaps, por velocidad, detalle, simplicidad, capacidad de ser acelerado en gpu,...

[marcode]

En respuesta a tu mensaje, no creo que pueda ayudarte mucho porque como dije ando liado también con ello desde hace tiempo, y todavía tengo pendiente por resolver muchas cosas (poco a poco avanzo), también imagino que dependiendo de la metodología que se aplique se podrá hacer de mil formas diferentes, aunque te contaré mis experiencias y como lo estoy haciendo por si te sirve algo.

Creo que lo que más cuesta es empezar, yo creo que deberías hacerlo de momento al máximo de detalle, una zona no muy grande, aunque haciendo la división que creas necesaria para poder manejar posteriormente zonas pequeñas, yo uso una Mapa de 160x160 Km dividido en sectores de 10x10Km al que llamo terrenos y que está dividido en otras regiones más pequeñas de 1Km al que llamo parcelas, tres tipos de divisiones que trato de manera independiente, no se si será mejor hacer una estructura de árbol con muchos niveles, pero a mi me va bien así (de momento). Las estructuras que uso son básicamente:

Código [Seleccionar] Expand


CParcela
{
    // coordenadas, altimetria, texturas de 1Km², etc
};

CTerreno
{
  CParcela parcela[10][10];
  // coordenadas, textura 100Km², etc.
};

CMapa
{
  CTerreno *pTerreno[16][16];
  // coordenadas, etc.
};

El mapa es la zona visible 160x160 Km, tiré a lo bestia en mi última revisión porque imagino que como os pasará todos, odio la niebla que disimula un corte brusco del escenario, y quiero ver hasta la montañita más lejana en el horizonte.

Como ves, para la estructura mapa uso punteros porque necesitaría muchos miles de terrenos y hacer más divisiones para abarcar toda España, al desplazarme destruyo los que dejan de verse, desplazo los apuntadores de cada celda, y cargo y creo los nuevos en los "huecos libres". de esta forma en memoria solo hay lo que se ve (que no es poco).

Los terrenos que como ya dije son de un tamaño de 10x10 Km, tiene sus 100 parcelas y su textura propia, que con un tamaño de 2048x2048 ya se ve bastante aceptable desde el aire.

Como tengo dividido el mapa visible en 16x16 celdas de terrenos y yo siempre estoy en el centro, al menos será necesario ese detalle (2048) de textura para los que se encuentre en un radio de 15 Km del centro, unos 9 o así, despues texturas de 1024 para los que estén a 30 Km y así sucesivamente, (estás cifras no son fijas por razones prácticas).  A partir de 50 kilómetros por lo general apenas se aprecia ningún detalle, solo el perfil de las montañas y el horizonte, con lo que con el color gris azulado de la niebla es suficiente.

El LOD de vértices lo hago a nivel de parcela aunque antes hago una clasificación de aquellos terrenos que se encuentre a lo lejos para que todas sus parcelas tengan el más bajo detalle (La mayoría de ellos).

Para aquellos terrenos más próximos compruebo que LOD deberán llevar cada una de sus parcelas dependiendo de su distancia.  Además de hacer la comprobación de cuales serán visibles o no, dependiendo de si están dentro del FOV de la cámara. si por ejemplo me quedo con los 15 terrenos más cercanos para aumentar el detalle, como cada uno tiene 100 parcelas, haré 1500 comprobaciones de distancia en total, lo que no me produce un gasto excesivo de proceso, esto ya depende de cada cual como se lo monte con las divisiones del terreno para hacer más o menos comprobaciones.

Para crear el terreno como tal he tirado por el camino más fácil, es una malla regular de 32x32 vértice conectados por tiras de triángulos, por lo que al ser de 1Km cuadrado, cada vértice está a una distancia del otro de 1000/32 = 31,25 metros, suficiente detalle, y además de que los datos de altimetría que uso proporcionados por la Nasa tiene una resolución de 90 m. aprox.
ftp://e0srp01u.ecs.nasa.gov/srtm/version2/SRTM3/Eurasia

Esto me da la ventaja de que el número de divisiones es potencia de 2, por lo que puedo dividirlo facilmente en 5 niveles de detalle más, de 16x16, 8x8, 4x4, 2x2 y 1x1. esto al renderizar facilita mucho las cosas porque solo tengo que usar 6 tipos diferentes de "index buffer" los cuales puedo tener desde el principio cargados en la memoria de vídeo sin problemas (aunque todavía me queda por hacer el crear nuevos triángulos que conecten las parcelas de diferente LOD). Si te fijas uso listas de vértices que van desde los (32+1)*(32+1)=1089 para el máximo detalle y de (1+1)*(1+1)=4 vértices para el mínimo, lo que quiere decir que los terrenos que se verán a lo lejos (la mayoría) tendrán 400 vértices cada uno, cifra bastante asequible.

Lógicamente para hacerlo así he tenido que convertir antes los archivos de coordenadas geodésicas proporcionados a otros en coordenadas UTM, e interpolar las alturas a esa distancia y dejar preparados los archivos para una carga rápida.

Si la información de la altimetría que tienes no la puedes preparar a tu gusto previamente, tendrás que buscarte la vida para crear los vértices y los triángulos con el método más apropiado, y por supuesto la forma de disminuir su detalle en tiempo real debe ir asociada.

Pero siguiendo con lo mío, cuando ya tengo hecha la clasificación de los terrenos y las parcelas, primero hago una carga relativamente rápida de todas las parcelas de todos los terrenos al mínimo nivel de detalle por lo que el actual LOD de todos será en principio MAX_LOD-1, teniendo en cuenta que 0 es el máximo, después según su distancia irá aumentando el nivel de detalle para cada parcela (hago esto para no tener que esperar hasta ver algo).

Para renderizar, recorro todos los terrenos apuntados por el mapa, cargo la textura y a continuación dibujo las 100 parcelas que lo compone, usando un "index buffer" diferente de los 6 que uso dependiendo de su LOD, los "vertex buffer" también son los mismos para todos, ya que solo difiere la altura, pero antes de dibuajr modifico las Y con los datos del buffer de la altimetría que tiene cada parcela, las coordenadas relativas X y Z, y de textura son las mismas para todos,  ya que uso la matriz de textura para desplazarlas y la matriz del Modelo para situarla en su posición correspondiente (no uso normales de momento).

Bueno, ya me he enrollado mucho, me dejo muchas cosas pero era solo para explicarte un poco una de las miles de formas que habrá de hacerlo, no creo que sea la mejor, pero es la mía y soy feliz de momento con ella.

Yo creo que lo mejor es que empieces a darle caña sin más preocupación, probando las formas que encuentres para solucionar los problemas, o las que se te den mejor de momento, y vayas reuniendo los conocimientos, creando funciones, algoritmos etc. para poco a poco reconstruirlo todo desde el principio, las veces que haga falta para perfeccionarlo, antes de que puedas conseguir el proyecto definitivo. Yo lo he repetido ya varias veces, mejorándolo cada vez, y todavía creo que estoy empezando.

Empieza creando y dibujando un terreno tal cual, hazlo cada vez más grande y ve probando formas de solucionar los problemas que planteas y los que te van a ir surgiendo, sobre todo tendrás que buscarte la vida para agrupar, organizar, clasificar, etc. los millones de póligonos que puede ocupar un terreno.

Y no te olvides de contar tus experiencias y dudas por aquí.

[neophox]

Muy interesante el metodo que usas, me ha recordado parcialmente los geometry clipmaps (le has echado un ojo?).
Una pregunta, mencionas que utilizas texturas de 2048, son texturas geoespecificas o geotipicas?, es decir, imagen real o algo generico?
Si son reales y paginas no solo altimetria sino tambien texturas de ese tamaño, te va suficientemente rapido? JPG? DDS?
Otra pregunta, el LOD lo calculas en funcion de la distancia en tiempo real o preprocesas la altimetria para tener listos varios LOD?

Un saludo.

[marcode]

Muy interesante el metodo que usas, me ha recordado parcialmente los geometry clipmaps (le has echado un ojo?).

Pues es bastante parecido, solo que el cambio de LOD que hago yo es diametral ¿se dice así?, osea por su distancia real a la cámara.

Las texturas de 2048 que he usado son jpg, y tardan bastante en crearse la primera vez. Realmente el tiempo de carga y descompresión no es mucho, uso freeimage (supongo que habrá librerías más rápidas), pero yo creo que con un thread a parte no provocaría ningún tipo de parón en la carga y descompresión.

El problema mayor lo veo al crear la textura como tal, concretamente con glTexImage2D me tarda al menos un segundo (sin mipmaps) la primera vez, aunque esto he podido subsanarlo utilizando el espacio reservado por las texturas que "quedan atrás", con glTexsubImage va mucho más rápido, pero sigue notándose la pausa.

No sé si es un poco excesivo 2048 y tenga que rebajar al final a 1024, que en teoría se crearían 4 veces más rápido. De todos modos creo que la bajada de frames es casi irremediable al cargar tanta textura sea del tamaño que sea.

La altimetría para mi sorpresa me carga muy rápido teniendo en cuenta que la cargo al máximo detalle (el LOD solo lo aplico al renderizar) y que además no uso threads. Sin texturas me desplazo por el escenario a toda leche y solo percibo una ligera bajada de frames. Comparado con lo que tardan las texturas en crearse casi ni me preocupa dejarlo así de momento, aunque tendré que solucionarlo porque consume demasiada memoria.

Otra pregunta, el LOD lo calculas en funcion de la distancia en tiempo real o preprocesas la altimetria para tener listos varios LOD?

El LOD lo calculo en tiempo real mediante una operación básica Lod=DistanciaParcela/DistanciaDetalleMaximo, solo de aquellas parcelas que sean visibles mediante una selección previa, de manera que para una distancia menor a la mínima distancia de detalle máximo me daría Lod=0, para las distancias mayores un valor mayor, siempre comprobando que no supere el máximo permitido.

Después al dibujar, uso el IndexBuffer[Lod] correspondiente, sobre un VertexBuffer[Lof] cuyos componentes x,z, tu, tv son siempre los mismos, pero las "y" son modificadas con las alturas cargadas en cada parcela, que por cierto, igual que las alturas son de tamaño WORD, los vértices también están en ese formato para acelerar la copia, ya que uso coordenadas relativas de como máximo 1000.0f que es la longitud de cada parcela, y tengo precisión suficiente.

¿Como ves tú lo de las texturas grandes?, ¿o que experiencias tienes?

[neophox]

¿Como ves tú lo de las texturas grandes?, ¿o que experiencias tienes?

Hombre, yo creo que podrian funcionar bien, si tienes un radio de paginacion suficiente para poder ir cargandolas poco a poco no deberia provocarte tirones en el render.
Tambien dependera del area que te cubra cada una de esas texturas y cuantas tienes que cargar. Si vuelas a mucha altura y mucha velocidad es posible que llegues a tener problemas pq te estaran entrando nuevas zonas a cargar con mas frecuencia.