Quelle est la meilleure méthode LOD pour le rendu des planètes?

Je travaille actuellement sur ma thèse, c'est un moteur de rendu de terrains de taille planétaire.

Je termine mes recherches et j'ai rencontré beaucoup de choses sur ce sujet, le problème est que je ne peux pas décider quelle méthode de niveau de détail (LOD) je dois utiliser.

Je connais le géomipmapping, les clipmaps de géométrie (GPU) et le LOD fragmenté par Ulrich qui fonctionnent bien sur de grands terrains et peuvent être utilisés pour rendre 6 faces d'un cube puis "sphérifier" le cube par cette méthode et je comprends comment implémenter tous ces méthodes sur GPU en utilisant C ++ / OpenGL / GLSL (utiliser des méthodes comme ROAM ou toute autre méthode qui n'utilise pas de cube est hors de ma portée car la texturation est une douleur). J'ai aussi récemment commencé un didacticiel de rendu de terrains à l'aide de shaders de pavage ici

Donc, je n'ai pas le temps de mettre en œuvre TOUTES les méthodes et de voir laquelle est la meilleure et la plus appropriée pour une échelle planétaire et je demande ici pour voir si quelqu'un a fait ce genre de comparaison et m'aider à décider quelle méthode dois-je implémenter et utiliser (mon tuteur est un peu fou et veut que je fasse quelque chose avec un icosaèdre, mais je ne peux pas comprendre cette méthode à moins d'utiliser ROAM)

Quoi qu'il en soit, si vous pouvez m'aider à décider ou si j'ai d'autres suggestions ou méthodes, j'apprécierai vraiment. Une condition est que la méthode soit capable d'implémenter le côté GPU (au moins la plupart) pour éviter un goulot d'étranglement CPU.

Une autre demande est que je sais qu'il y a des problèmes numériques sur la précision des flotteurs lorsque l'on obtient beaucoup de détails sur le terrain, je ne sais pas comment le résoudre, j'ai lu une solution dans un forum mais je n'arrive pas à comprendre comment mettre en œuvre, j'ai perdu la trace de ce fil et je voudrais savoir comment résoudre ce problème de précision.

Je lis actuellement quelques transformations matricielles pour résoudre la précision du flotteur, les problèmes de lutte contre le z, l'abattage du tronc avec des valeurs z dynamiques et la représentation des données pour les morceaux (en utilisant l'espace de patch avec des flotteurs et sa position dans les coordonnées mondiales comme double), donc Je pense que je peux résoudre le problème de précision facilement. J'ai encore besoin d'une comparaison entre les méthodes LOD avec vos opinions et suggestions pour décider quelle est la meilleure pour ce projet. Prenez en compte la difficulté de mise en œuvre vs la qualité visuelle vs les performances, je veux le meilleur.

Quelque chose que j'ai oublié de mentionner est que la génération est hybride, je veux dire, je devrais être capable de rendre la planète entièrement en utilisant le GPU (hauteurs calculées à la volée) et / ou en utilisant une image de carte de hauteur de base et ajouter des détails avec le GPU (vertex shader). La texturation sera une partie latérale que je vais déranger, en ce moment, je suis heureux d'utiliser uniquement des couleurs en fonction de la hauteur, ou peut-être d'utiliser une sorte de texture de bruit générée sur le fragment shader.

Enfin, après de nombreuses recherches, je peux conclure que, comme quelqu'un l'a déjà dit, il n'y a pas universellement de "meilleure" méthode. Mais mes recherches m'ont conduit à la connaissance des choses suivantes:

Selon le maillage que vous utiliserez enfin:

• Cube sphérique: toute méthode LOD avec implémentation quadtree fonctionnera très bien, il vous suffit de faire attention aux cas spéciaux comme les frontières entre les faces, dans ce cas, votre quadtree doit avoir un pointeur vers le voisin dans la face adjacente à chaque niveau.
• Tout autre: je pense que ROAM (version plus récente 2.0 ou toute autre extension comme BDAM, CABTT ou RUSTIC) fonctionnera bien, cependant, ces algorithmes sont difficiles à travailler, nécessitent plus de mémoire et sont un peu plus lents que d'autres approches avec des cubes.

Il existe de nombreuses méthodes LOD qui peuvent bien s'adapter, mais mon top 5 personnel est le suivant:

1. LOD continu en fonction de la distance (CDLOD)
2. Clipmaps Geomety basés sur GPU (GPUGCM)
3. LOD en morceaux
4. Rendu de terrains avec OpenGL GPU Tessellation (Livre: OpenGL Insight, Chapitre 10)
5. MipMapping géométrique

Chacun offre une façon unique de rendre les terrains, par exemple, CDLOD a une implémentation très simple en utilisant des shaders (GLSL ou HLSL) mais est également capable d'être implémenté sur CPU (pour le matériel hérité) mais l'objectif de Planet Rendering est d'exploser le meilleur sur les GPU modernes, donc GPUGCM est le meilleur lorsque vous voulez presser votre GPU. Ils fonctionnent tous les deux très bien avec le rendu basé sur des données, procédural ou mixte (terrain basé sur des données fixes ou des cartes de hauteur et des détails ajoutés avec le travail procédural) de grands terrains.

Il existe également une extension sphérique à la méthode de base des clips géométriques, mais elle présente certains problèmes car les échantillons plans de la carte de hauteur doivent être paramétrés à l'aide de coordonnées sphériques.

Le LOD fragmenté, d'autre part, est parfait pour le matériel hérité, n'a pas besoin de calculs côté GPU pour fonctionner, il est parfait pour les grands ensembles de données mais ne peut pas gérer les données procédurales en temps réel (peut-être avec quelques modifications, il pourrait)

L'utilisation des shaders Tessellation est une autre technique, très nouvelle, depuis la sortie d'OpenGL 4.x, à mon avis, cela pourrait être le meilleur, mais, nous parlons de Planet Rendering, nous rencontrons un problème que d'autres méthodes peuvent gérer très facilement et c'est sur la précision.

À moins que vous ne souhaitiez que votre précision à 1 km entre les sommets, optez pour les shaders Tessellation. Le problème avec les très gros terrains avec cette méthode est que la gigue est difficile à résoudre (ou du moins pour moi, car je suis nouveau dans les shaders de pavage).

Le géomipmapping est une excellente technique, tire parti du quadtree et a une faible erreur de pixels projetés, mais, pour le rendu planétaire, vous devrez définir au moins 16 niveaux de détails, ce qui signifie que vous aurez besoin (pour l'assemblage pourpose) de correctifs supplémentaires pour connecter différents niveaux et prendre soin du niveau de votre voisin, cela peut être fastidieux à résoudre, en particulier en utilisant 6 faces de terrain.

Il existe une autre méthode, très particulière en elle-même: "Projective Grid Mapping for Planetary Terrain" excellente pour la visualisation, mais qui a ses inconvénients, si vous voulez en savoir plus, allez sur le lien.

Problèmes:

• Gigue : la plupart des GPU d'aujourd'hui ne prennent en charge que les valeurs à virgule flottante 32 bits, ce qui n'offre pas une précision suffisante pour manipuler de grandes positions sur des terrains à l'échelle planétaire. La gigue se produit lorsque le spectateur effectue un zoom avant et pivote ou se déplace, puis les polygones commencent à rebondir d'avant en arrière.

  La meilleure solution consiste à utiliser la méthode "Rendu par rapport aux yeux à l'aide du GPU". Cette méthode est décrite dans le livre "3D Engine Design for Virtual Globes" (je suis sûr que vous pouvez le trouver sur Internet également) dans lequel vous devez essentiellement définir toutes vos positions avec des doubles sur le CPU (correctifs, plans de clip, objets, frustrum, caméra, etc.), puis MV est centré autour du spectateur en définissant sa translation sur (0, 0, 0) T et les doubles sont codés dans une représentation à virgule fixe en utilisant la fraction (mantisse) des bits de deux flotteurs, faible et élevé par une méthode (en savoir plus sur l'utilisation de l'implémentation d'Ohlarik et la bibliothèque Fortran DSFUN90).

  Bien que le vertex shader ne nécessite que deux soustractions et un ajout supplémentaires, GPU RTE double la quantité de mémoire tampon de vertex requise pour les positions. Cela ne double pas nécessairement les besoins en mémoire, sauf si seules les positions sont stockées.

• Précision du tampon de profondeur : combat Z. Comme nous rendons de très grands terrains, dans ce cas: les planètes, le Z-buffer doit être ÉNORME, mais peu importe les valeurs que vous définissez pour znear et zfar, il y aura toujours des problèmes.

  Comme le tampon Z dépend d'un intervalle de point flottant, et il est également linéaire (bien que la projection en perspective soit non linéaire) les valeurs proches de l'œil souffrent du combat Z parce que le manque de précision des flotteurs 32 bits a.

  La meilleure façon de résoudre ce problème consiste à utiliser un "tampon de profondeur logarithmique" http://outerra.blogspot.com/2012/11/maximizing-depth-buffer-range-and.html

  Un tampon de profondeur logarithmique améliore la précision du tampon de profondeur pour les objets distants en utilisant une distribution logarithmique pour zscreen. Il échange la précision pour les objets proches contre la précision pour les objets distants. Puisque nous effectuons un rendu avec une méthode LOD, les objets éloignés nécessitent moins de précision car ils ont moins de triangles.

Il est important de mentionner que toutes les méthodes répertoriées (à l'exception de la grille projective) sont très bonnes lors de la physique (principalement les collisions) en raison de la base Quadtree, c'est quelque chose d'obligatoire si vous prévoyez de faire un jeu.

En conclusion, il suffit de cocher toutes les options disponibles et de choisir celle qui vous convient le mieux, à mon avis CDLOD fait un excellent travail. N'oubliez pas de résoudre les problèmes de gigue et de Z-buffer, et le plus important: amusez-vous à le faire!

Pour plus d'informations sur LOD, consultez ce lien .

Pour une démonstration complète de la sphérification d'un cube, consultez ce lien .

Pour une meilleure explication sur la résolution de la gigue et des précisions Z-Buffer, consultez ce livre .

J'espère que vous trouverez cette petite critique utile.