1: Je ne peux pas comprendre à quel moment dans le pipeline Chunked LOD le maillage est divisé en morceaux. Est-ce lors de la génération initiale du maillage, ou existe-t-il un algorithme distinct qui le fait?
Ce n'est pas important. Par exemple, vous pouvez intégrer la segmentation dans votre algorithme de génération de maillage. Vous pouvez même le faire dynamiquement, de sorte que des niveaux inférieurs soient ajoutés dynamiquement (par exemple lorsque le joueur se rapproche) en utilisant un algorithme de raffinement de type plasma. Vous pouvez également générer un maillage haute résolution à partir des données d'entrée de l'artiste ou des données de mesure d'altitude et les agréger dans tous les blocs LOD au moment de la finalisation de l'actif. Ou vous pouvez mélanger et assortir. Cela dépend vraiment de votre application.
2: Je comprends qu'une structure de données Quadtree est utilisée pour stocker les données LOD Chunked, je pense que je manque un peu le point, mais le quadtree stocke-t-il des données de vertex et de triangles pour chaque niveau de subdivision?
Pas nécessairement. L'arbre stocke juste des informations sur la géométrie et comment la rendre. Cela pourrait signifier avoir une liste de sommets / faces à chaque nœud d'arbre. Plus réaliste de nos jours, vous stockeriez les poignées des maillages / instances dans la mémoire du GPU.
3a: Comment est généralement calculée la distance de la caméra. En lisant sur les quadtree, les boîtes englobantes alignées sur les axes sont souvent mentionnées. Dans ce cas, chaque bloc aurait-il une zone de délimitation de collision pour détecter si la caméra ou le lecteur est à proximité? ou existe-t-il une meilleure façon de procéder? (raycast peut-être?)
Une option très bon marché et facile consiste à utiliser la distance jusqu'au point central du morceau, puis à la corriger. Vous savez que cette distance est toujours une sous-estimation: si le point central est à distance Z, cela signifie que la moitié du morceau est plus proche que cela. Ce que nous ne savons cependant pas, c'est l'orientation. Si nous regardons un morceau de largeur sur le wbord, le bit le plus proche du morceau sera à distance Z-w. Cependant, si nous regardons le morceau en premier, le bit le plus proche sera à distance Z-sqrt(2)*w. Si vous pouvez vivre avec cette incertitude (vous le pouvez presque toujours), vous avez terminé. Notez que vous pouvez également corriger l'angle de vue en utilisant la trigonométrie de base.
Je préfère calculer la distance minimale absolue de la caméra au bloc pour minimiser les artefacts. En pratique, cela signifie faire un test de distance point-carré . C'est un peu plus de travail que de calculer les distances aux points centraux, mais ce n'est pas comme si vous en fassiez un zillion à chaque image.
Si vous pouvez tirer parti de votre moteur physique pour ce faire, faites-le, mais vous voulez vraiment y penser davantage en termes de «requête de distance» que de «collision».
3b: Les morceaux calculent-ils eux-mêmes la distance de la caméra?
Cela dépend vraiment de la conception de votre moteur. Je recommanderais cependant de garder les feuilles relativement légères. En fonction de votre plate-forme, le simple fait d'avoir quelques milliers de morceaux de terrain pour effectuer leur propre mise à jour chaque trame peut sérieusement affecter les performances.
4: Chaque bloc a-t-il la même "résolution"? par exemple, au niveau supérieur, le maillage sera 32x32, chaque nœud subdivisé sera également 32x32.
Ils n'ont pas à le faire, mais c'est pratique si tous les morceaux occupent la même quantité d'espace. Ensuite, vous pouvez faire votre gestion de mémoire (GPU) en unités de "morceaux". Il est également plus facile de supprimer / masquer les joints entre deux morceaux de tailles différentes si une résolution est multiple de l'autre car ils partagent plus de sommets. (par exemple: 32x32 et 64x64 est plus facile à gérer que 32x32 et 57x57) (merci Guiber!). Si vous avez une bonne raison de varier la taille de la géométrie du morceau, allez-y certainement.
