¿Cuál es el mejor método LOD para la representación del planeta?

Actualmente estoy trabajando en mi tesis, es un motor para renderizar terrenos de tamaño planetario.

Todavía estoy terminando mi investigación y he encontrado muchas cosas sobre este tema, el problema es que no puedo decidir qué método de Nivel de detalle (LOD) debo usar.

Sé sobre geomipmapping, mapas de clip de geometría (GPU) y LOD fragmentado por Ulrich que funcionan bien en terrenos grandes y se pueden usar para renderizar 6 caras de un cubo y luego "esferizar" el cubo por este método y entiendo cómo implementar todo estos métodos en GPU usando C ++ / OpenGL / GLSL (usar métodos como ROAM o cualquier otro método que no use un cubo está fuera de mi alcance debido a que la textura es un dolor). También recientemente me metí en un tutorial de renderización de terrenos usando sombreadores de teselación aquí

Por lo tanto, no tengo tiempo para implementar TODOS los métodos y ver cuál es el mejor y más adecuado para una escala planetaria y estoy preguntando aquí para ver si alguien ha hecho este tipo de comparación y ayudarme a decidir qué método debo implementar y usar (mi tutor es un poco loco y quiere que haga algo con un icosaedro, pero no puedo entender ese método a menos que use ROAM)

De todos modos, si puede ayudarme a decidir o si tiene alguna otra sugerencia o método, realmente lo agradeceré. Una condición es que el método debería poder implementar el lado de la GPU (al menos la mayor parte) para evitar el cuello de botella de la CPU.

Otra solicitud es que sé que hay problemas numéricos sobre la precisión con los flotadores cuando se obtienen muchos detalles en el terreno, no sé cómo resolverlo, leo una solución en un foro pero no puedo entender cómo implementar, perdí el rastro de ese hilo y me gustaría saber cómo resolver este problema de precisión.

Actualmente estoy leyendo sobre algunas transformaciones matriciales para resolver la precisión del flotador, los problemas de lucha z, el sacrificio inicial con valores z dinámicos y la representación de datos para fragmentos (usando el espacio de parche con flotadores y su posición en las coordenadas del mundo como dobles) Creo que puedo resolver el problema de precisión fácilmente. Todavía necesito una comparación entre los métodos LOD con sus opiniones y sugerencias para decidir cuál es mejor para este proyecto. Tenga en cuenta la dificultad de implementación frente a la calidad visual frente al rendimiento, quiero lo mejor.

Algo que olvidé mencionar es que la generación es híbrida, es decir, debería poder renderizar el planeta por completo usando GPU (alturas calculadas sobre la marcha) y / o usando una imagen de mapa de altura base y agregar detalles con GPU (vértice sombreador). La textura será una parte lateral que voy a molestar más tarde, ahora estoy feliz usando solo colores dependiendo de la altura, o tal vez usando algún tipo de textura de ruido generada en el sombreador de fragmentos.

Finalmente, después de mucho investigar, puedo concluir que, como alguien dijo antes, no existe un método universalmente "mejor". Pero mi investigación me llevó al conocimiento de las siguientes cosas:

Dependiendo de la malla que finalmente usará:

• Cubo Esferificado: cualquier método LOD con implementación de quadtree funcionará bien, solo debe tener cuidado con casos especiales como bordes entre caras, en cuyo caso, su quadtree debe tener un puntero al vecino en la cara adyacente en cada nivel.
• Cualquier otro: creo que ROAM (versión más nueva 2.0 o cualquier otra extensión como BDAM, CABTT o RUSTIC) funcionará bien, sin embargo, estos algoritmos son difíciles de trabajar, requieren más memoria y son un poco más lentos que otros enfoques con cubos.

Hay muchos métodos LOD que pueden encajar bien, pero mis 5 mejores personales son:

1. LOD dependiente de la distancia continua (CDLOD)
2. Geomety Clipmaps basado en GPU (GPUGCM)
3. LOD fragmentado
4. Representación de terrenos con teselación de GPU OpenGL (Libro: OpenGL Insight, Capítulo 10)
5. Mapeo Geométrico

Cada uno ofrece una forma única de renderizar terrenos, por ejemplo, CDLOD tiene una implementación muy fácil usando sombreadores (GLSL o HLSL) pero también puede implementarse en la CPU (para hardware heredado), sin embargo, el objetivo en Planet Rendering es explotar el mejor en las GPU modernas, por lo que GPUGCM es la mejor cuando desea exprimir su GPU. Ambos funcionan muy bien con renderizado basado en datos, procesal o mixto (terreno basado en datos fijos o mapas de altura y detalles agregados con el trabajo procesal) de grandes terrenos.

También existe la extensión esférica al método básico de mapas geométricos de clip, pero tiene algunos problemas porque las muestras planas del mapa de altura deben parametrizarse mediante coordenadas esféricas.

El LOD fragmentado, por otro lado, es perfecto para hardware heredado, no necesita ningún cálculo secundario de GPU para funcionar, es perfecto para grandes conjuntos de datos pero no puede manejar datos de procedimiento en tiempo real (tal vez con algunas modificaciones, podría)

Usar sombreadores de teselación es otra técnica, muy nueva, ya que OpenGL 4.x salió, en mi opinión, podría ser el mejor, pero, estamos hablando de Planet Rendering, nos encontramos con un problema que otros métodos pueden manejar muy fácilmente y es sobre precisión

A menos que solo desee que su precisión sea de 1 km entre vértices, busque sombreadores de teselación. El problema con los terrenos realmente grandes con este método es que la fluctuación es un poco difícil de resolver (o al menos para mí, ya que soy nuevo en los sombreadores de teselación).

Geomipmapping es una gran técnica, aprovecha el quadtree y tiene un error de píxel proyectado bajo, pero, para el renderizado planetario, deberá establecer al menos más de 16 niveles de detalles, eso significa que necesitará (para unir propósitos) algunos parches adicionales para conectar diferentes niveles y cuidar el nivel de tu vecino, esto puede ser tedioso de resolver, especialmente usando 6 caras del terreno.

Hay otro método, muy particular en sí mismo: "Mapeo de cuadrícula proyectiva para terreno planetario" excelente para la visualización, pero tiene sus desventajas, si desea saber más, vaya al enlace.

Problemas:

• Jitter : la mayoría de las GPU actuales solo admiten valores de punto flotante de 32 bits, lo que no proporciona suficiente precisión para manipular grandes posiciones en terrenos de escala planetaria. La fluctuación se produce cuando el espectador se acerca y gira o se mueve, luego los polígonos comienzan a rebotar hacia adelante y hacia atrás.

  La mejor solución para esto es usar el método "Representación relativa al ojo usando la GPU". Este método se describe en el libro "Diseño de motores 3D para globos virtuales" (estoy seguro de que también puede encontrarlo en Internet) en el que básicamente debe establecer todas sus posiciones con dobles en la CPU (parches, mapas de clip, objetos, frustrum, cámara, etc.) y luego MV se centra alrededor del espectador configurando su traducción a (0, 0, 0) T y los dobles se codifican en una representación de punto fijo usando los bits de fracción (mantisa) de dos flotadores, bajo y alto por algún método (lea sobre el uso de la implementación de Ohlarik y la biblioteca DSFUN90 Fortran).

  Aunque el sombreador de vértices requiere solo dos sustracciones adicionales y una adición, GPU RTE duplica la cantidad de memoria de búfer de vértices requerida para las posiciones. Esto no duplica necesariamente los requisitos de memoria a menos que solo se almacenen las posiciones.

• Profundidad Buffer Precisión : Z-fighting. Como estamos renderizando terrenos muy grandes, en este caso: planetas, el búfer Z debe ser ENORME, pero no importa qué valores establezca para znear y zfar, siempre habrá problemas.

  Como el Z-buffer depende de un intervalo de coma flotante, y también es lineal (aunque la proyección en perspectiva no es lineal) los valores cercanos al ojo sufren de Z-fighting debido a la falta de precisión de los flotadores de 32 bits.

  La mejor manera de resolver este problema es utilizar un "Buffer de profundidad logarítmica" http://outerra.blogspot.com/2012/11/maximizing-depth-buffer-range-and.html

  Un búfer de profundidad logarítmico mejora la precisión del búfer de profundidad para objetos distantes mediante el uso de una distribución logarítmica para zscreen. Cambia la precisión por objetos cercanos por la precisión por objetos distantes. Dado que estamos renderizando con un método LOD, los objetos lejanos requieren menos precisión porque tienen menos triángulos.

Algo importante que mencionar es que todos los métodos enumerados (excepto la cuadrícula proyectiva) son muy buenos al hacer física (colisiones en su mayoría) debido a la base Quadtree, eso es algo obligatorio si planea hacer un juego.

En conclusión, simplemente verifique todas las opciones disponibles y elija la que le resulte más cómoda, en mi opinión, CDLOD hace un gran trabajo. No olvides resolver los problemas de jitter y Z-buffer, y lo más importante: ¡diviértete haciéndolo!

Para obtener más información sobre LOD, consulte este enlace .

Para obtener una demostración completa sobre la esferificación de un cubo, consulte este enlace .

Para obtener una mejor explicación sobre la resolución de la fluctuación de fase y las precisiones de Z-Buffer, consulte este libro .

Espero que encuentre útil esta pequeña reseña.