Qual é o melhor método LOD para renderização de planetas?

Atualmente, estou trabalhando na minha tese, é um mecanismo para renderizar terrenos de tamanho planetário.

Ainda estou terminando minha pesquisa e encontrei muitas coisas sobre esse assunto, o problema é que não consigo decidir qual método de Nível de detalhe (LOD) devo usar.

Conheço geomipmapping, geometry clipmaps (GPU) e LOD fragmentado da Ulrich que funcionam bem em terrenos grandes e podem ser usados ​​para renderizar 6 faces de um cubo e depois "esferificar" o cubo por esse método e eu entendo como implementar todos os esses métodos na GPU usando C ++ / OpenGL / GLSL (usar métodos como ROAM ou qualquer outro método que não use um cubo está fora do meu alcance devido à texturização ser uma dor). Também recentemente entrei em um tutorial de renderização de terrenos usando shaders de mosaico aqui

Portanto, não tenho tempo para implementar TODOS os métodos e ver qual é o melhor e mais adequado para uma escala planetária e estou pedindo aqui para ver se alguém fez esse tipo de comparação e me ajudar a decidir qual método devo implementar e usar (meu tutor é meio louco e quer que eu faça algo com um icosaedro, mas não consigo entender esse método a menos que esteja usando ROAM)

De qualquer forma, se você puder me ajudar a decidir ou tiver alguma outra sugestão ou método, eu realmente aprecio. Uma condição é que o método possa implementar o lado da GPU (pelo menos a maioria) para evitar gargalos na CPU.

Outra solicitação é que eu saiba que existem problemas numéricos sobre precisão com flutuadores ao obter muitos detalhes no terreno, não sei como resolvê-lo, leio uma solução em um fórum, mas não consigo entender como implementar, perdi o controle desse segmento e gostaria de saber como resolver esse problema de precisão.

Atualmente, estou lendo sobre algumas transformações de matriz para resolver a precisão de flutuação, problemas de combate a z, seleção de frustum com valores z dinâmicos e representação de dados para pedaços (usando espaço de correção com flutuadores e sua posição no mundo como coordenadas duplas), portanto Eu acho que posso resolver o problema de precisão facilmente. Eu ainda preciso de uma comparação entre os métodos LOD com suas opiniões e sugestões para decidir qual é o melhor para este projeto. Ter em conta a dificuldade de implementação vs qualidade visual vs desempenho, eu quero o melhor.

Algo que esqueci de mencionar é que a geração é híbrida, ou seja, eu deveria ser capaz de renderizar o planeta inteiramente usando GPU (alturas calculadas em tempo real) e / ou usando uma imagem de mapa de altura base e adicionar detalhes com GPU (vértice shader). A texturização será uma parte lateral. Eu vou incomodar mais tarde, agora estou feliz em usar apenas cores, dependendo da altura, ou talvez usar algum tipo de textura de ruído gerada no shader de fragmento.

Finalmente, depois de muita pesquisa, posso concluir que, como alguém disse antes, não existe um método "melhor" universalmente. Mas minha pesquisa me levou ao conhecimento das seguintes coisas:

Dependendo da malha, você finalmente usará:

• Cubo Esferificado: qualquer método LOD com implementação de quadtree funcionará bem, você só precisa cuidar de casos especiais, como bordas entre faces, nesse caso, seu quadtree precisa ter um ponteiro para o vizinho na face adacente em cada nível.
• Qualquer outro: acho que o ROAM (versão mais recente 2.0 ou qualquer outra extensão como BDAM, CABTT ou RUSTIC) funcionará bem, no entanto, esses algoritmos são difíceis de trabalhar, exigem mais memória e são um pouco mais lentos que outros métodos com cubos.

Existem muitos métodos LOD que podem se encaixar bem, mas meus 5 principais pessoais são:

1. LOD dependente da distância contínua (CDLOD)
2. Clipes de geomety baseada em GPU (GPUGCM)
3. LOD em pedaços
4. Renderização de terrenos com mosaico de GPU OpenGL (Livro: OpenGL Insight, Capítulo 10)
5. MipMapping geométrico

Cada um oferece uma maneira única de renderizar terrenos, por exemplo, o CDLOD possui uma implementação muito fácil usando shaders (GLSL ou HLSL), mas também pode ser implementado na CPU (para hardware herdado), mas o objetivo na Planet Rendering é explodir o melhor em GPUs modernas, então o GPUGCM é o melhor quando você deseja comprimir sua GPU. Ambos funcionam muito bem com a renderização baseada em dados, procedural ou mista (terreno com base em dados fixos ou mapas de altura e detalhes adicionados ao trabalho procedimental) de terrenos grandes.

Também existe uma extensão esférica ao método básico de Clipes geométricos geométricos, mas apresenta alguns problemas, pois as amostras planares do mapa de altura precisam ser parametrizadas usando coordenadas esféricas.

O LOD fragmentado, por outro lado, é perfeito para hardware legado, não precisa de nenhum cálculo lateral da GPU para funcionar, é perfeito para grandes conjuntos de dados, mas não pode manipular dados procedimentais em tempo real (talvez com algumas modificações, poderia)

O uso de sombreadores de mosaico de mosaico é outra técnica, muito nova, desde que o OpenGL 4.x foi lançado, na minha opinião, poderia ser o melhor, mas, estamos falando sobre o Planet Rendering, encontramos um problema que outros métodos podem lidar com muita facilidade e é sobre precisão.

A menos que você queira que sua precisão seja de 1 km entre vértices, escolha os shaders de mosaico. O problema com terrenos realmente grandes com esse método é que o jitter é meio difícil de resolver (ou pelo menos para mim, já que sou novo nos shaders de mosaico).

O geomipmapping é uma ótima técnica, tira proveito do quadtree e tem um baixo erro de pixel projetado, mas, para renderização planetária, você precisará definir pelo menos 16 ou mais níveis de detalhes, o que significa que você precisará (para costurar aplicações) de alguns patches extras para conectar níveis diferentes e cuidar do nível do seu vizinho, isso pode ser entediante de resolver, especialmente usando 6 faces do terreno.

Existe outro método, muito particular por si só: "Mapeamento de grade projetiva para terreno planetário" excelente para visualização, mas tem suas desvantagens, se você quiser saber mais, acesse o link.

Problemas:

• Tremulação : A maioria das GPUs atuais suporta apenas valores de ponto flutuante de 32 bits, o que não fornece precisão suficiente para manipular grandes posições em terrenos de escala planetária. A tremulação ocorre quando o visualizador aproxima e gira ou se move, e os polígonos começam a saltar para frente e para trás.

  A melhor solução para isso é usar o método "Renderização em relação aos olhos usando a GPU". Esse método é descrito no livro "Design de mecanismo 3D para globos virtuais" (tenho certeza de que você também pode encontrá-lo na Internet), onde basicamente é necessário definir todas as suas posições com dobras na CPU (patches, clipmaps, objetos, frustrum, camera, etc) e, em seguida, o MV é centrado em torno do visualizador, definindo sua tradução para (0, 0, 0) T e os duplos são codificados em uma representação de ponto fixo usando os bits da fração (mantissa) de dois flutuadores, baixa e alta por algum método (leia sobre a implementação de Ohlarik e a biblioteca DSFUN90 Fortran).

  Embora o sombreador de vértice exija apenas duas subtrações adicionais e uma adição, o GPU RTE duplica a quantidade de memória buffer de vértice necessária para as posições. Isso não necessariamente dobra os requisitos de memória, a menos que apenas posições sejam armazenadas.

• Precisão do buffer de profundidade : Z-fighting. Como estamos processando terrenos muito grandes, neste caso: planetas, o buffer Z precisa ser ENORME, mas não importa quais valores você define para znear e zfar, sempre haverá problemas.

  Como o buffer Z depende de um intervalo de ponto de flutuação, e também é linear (embora a projeção em perspectiva não seja linear) os valores próximos ao olho sofrem com o combate a Z porque a falta de flutuadores de precisão de 32 bits tem.

  A melhor maneira de resolver esse problema é usar um "Logarithmic Depth Buffer" http://outerra.blogspot.com/2012/11/maximizing-depth-buffer-range-and.html

  Um buffer de profundidade logarítmico aprimora a precisão do buffer de profundidade para objetos distantes usando uma distribuição logarítmica para zscreen. Ele negocia precisão para objetos próximos e precisão para objetos distantes. Como estamos processando com um método LOD, os objetos distantes exigem menos precisão porque possuem menos triângulos.

Algo importante a ser mencionado é que todos os métodos listados (exceto a grade projetiva) são muito bons ao fazer física (principalmente colisões) por causa da base Quadtree, algo obrigatório se você planeja fazer um jogo.

Concluindo, basta verificar todas as opções disponíveis e escolher a que você mais se sentir confortável, na minha opinião o CDLOD faz um ótimo trabalho. Não se esqueça de resolver os problemas de instabilidade e buffer Z, e o mais importante: divirta-se fazendo isso!

Para mais informações sobre LOD, consulte este link .

Para uma demonstração completa sobre esferificação de um cubo, verifique este link .

Para uma melhor explicação sobre como resolver as tremulações e as precisões do Z-Buffer, consulte este livro .

Espero que você ache este pequeno comentário útil.