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

23

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.

nosmirck
la source
6
Il n'y a pas de méthode universellement "meilleure". Vous seul connaissez toutes les exigences de votre projet et vous semblez connaître un certain nombre d'options de niveau de détail. Enfin, vous devriez vraiment prendre cette décision par vous-même car cela fait partie de votre thèse. Votre thèse montre votre connaissance du sujet que vous étudiez. Si vous ne savez pas lequel correspond le mieux à vos besoins, vous devriez peut-être étudier un peu plus les options.
MichaelHouse
@ Byte56 vous avez raison, et je faisais beaucoup de recherches sur les méthodes LOD, je voulais juste voir quelques suggestions d'autres personnes qui ont mis en œuvre certaines d'entre elles et parler de la performance et de la qualité visuelle afin que je puisse en choisir une ... de toute façon, merci pour votre commentaire :) et au fait, je comprends actuellement les shaders de tessellation et j'ai trouvé un excellent tutoriel (lien sur la question principale) et je pense que je vais y aller, cela est expliqué pour le rendu du terrain, mais je peux le modifier pour faire 6 faces et sphérifier le cube.
nosmirck
vterrain.org/LOD a beaucoup d'informations sur le sujet du rendu du terrain. La section liée répertorie les articles et autres sources pour les algorithmes de niveau de détail. vterrain.org/LOD/spherical.html traite des grilles sphériques (par exemple les planètes).
Exilyth
@sarahm Je sais, c'est là que j'ai commencé, je les ai toutes rouges ... J'ai juste besoin d'une comparaison entre certaines méthodes LOD pour choisir laquelle implémenter, je peux vraiment toutes les faire mais je n'ai pas le temps ... Quoi qu'il en soit , Je vais avec la méthode utilisant les shaders de pavage, c'est quelque chose de nouveau et il n'y a pas d'implémentation faite sur les surfaces sphériques :)
nosmirck
3
Je sais que vous avez déjà fait beaucoup de recherches, et je ne sais pas si cela est tombé sur votre bureau, mais jetez un œil à "Conception de moteur 3D pour les globes virtuels: Patrick Cozzi et Kevin Ring" - j'en ai trouvé beaucoup de bonnes informations pratiques là-dedans. Elle a été bien documentée et, comme on l'a dit, prise d'un point de vue très pratique. HTH en quelque sorte.
Schoenobates

Réponses:

17

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.

nosmirck
la source
1
J'aimerais en savoir plus sur votre parcours de recherche. Existe-t-il de toute façon que je puisse suivre vos mises à jour? Blog ou quelque chose?
Syaiful Nizam Yahya
@publicENEMY En ce moment, je développe toujours le moteur, je me suis arrêté parce que j'avais un emploi d'un an et mes recherches étaient en attente, dans un mois ou deux je reprendrais les recherches et finirais le moteur. Quand j'y serai, je vous ferai savoir ici quand je posterai toutes les mises à jour sur le voyage. Merci pour l'intérêt.
nosmirck