Optimisation d'un maillage pour les paysages de cube voxel

En jouant avec la création de paysages du monde minecraftish / lego dans Unity 3D (paysages voxels générés de manière procédurale avec des cubes), je trouve que les maillages créés pour ces paysages prennent beaucoup de mémoire. Le maillage n'est actuellement composé que de sommets pour les côtés visibles d'un cube. L'utilisation de la mémoire pour un terrain complexe peut prendre 6 à 7 cents mégaoctets.

Ces maillages pourraient être optimisés, mais j'ai du mal à trouver un algorithme décent pour le faire.

L'algorithme doit tenir compte du fait que vous ne voulez pas «fusionner» des blocs de différents types de terrain. Je suppose qu'un début très simple pourrait être de simplement traiter tous les blocs le long d'un axe et d'effectuer des balayages supplémentaires pour les deux autres axes.

J'ai besoin de garder la forme du maillage, c'est-à-dire pas de fusion de sommets au point que l'espace vide ou solide est modifié. La raison en est qu'il peut y avoir des créatures / etc qui doivent encore naviguer dans le maillage. Donc, je ne peux pas simplement créer un détail très bas, un maillage déformé.

Des réflexions / suggestions / conseils à ce sujet?

3d-meshes optimization voxels

— James Livingston
source

Pourquoi stockez-vous des sommets pour un cube de taille connue? Faites-le algorithmiquement; ou utilisez un tampon de vertex partagé.

— deceleratedcaviar

Pourquoi maillage polygonal? Le voxel peut être rendu assez efficacement tel qu'il est . Pour un cube voxel, vous avez besoin de 3 flotteurs (x, y, z), pour 1 boîte, vous avez besoin d'environ 8 * 3 flotteurs (8 sommets), et cela au cas où vous auriez des arêtes et des polygones implicites. Peut-être que Unity n'est pas l'outil pour ce problème de voxel.

— user712092

Réponses:

Ma question est:

Pourquoi auriez-vous besoin du maillage lui-même pour effectuer un mouvement de créature?

Vous ne pouvez pas faire le calcul de cheminement sur une matrice 3D d'identifiants?

Je pense que Minecraft utilise une matrice 3D avec un bloc pr 4 bits. Il simule également uniquement les créatures d'un certain rayon autour du joueur.

Vous pouvez stocker vos morceaux dans une structure d'arborescence oc, où chaque morceau est compressé.

Si vous conservez les données compressées dans la RAM, vous pouvez décompresser les données assez rapidement en cas de besoin.

texte alternatif

— Cloueur
source

Je comptais sur le maillage pour la détection de collision intégrée avec Unity, mais rien ne m'empêche de simplement tester la collision / le cheminement par rapport à une structure de données personnalisée. Cependant, j'ai encore besoin de créer un maillage visible pour afficher le terrain, et c'est ce que j'ai besoin d'optimiser.

— James Livingston

Un autre point ... comme vous pouvez le voir sur la capture d'écran ... il n'y a pas beaucoup de terrain plat. Les mailles sont généralement des surfaces rugueuses de cubes, mais je pense qu'il y a de la place pour optimiser les faces / sommets du maillage. Il semble qu'un octree serait préférable pour les données qui ont beaucoup de blocs de données similaires, au lieu de données "irrégulières". Ou n'est-ce pas correct?

— James Livingston

@Gatorfrog: N'oubliez pas que l'espace vide est également une donnée. si c'est irrégulier alors bien sûr, il y aura beaucoup de bits signalant son vide. L'octree est juste là pour que vous puissiez déterminer quels morceaux vous devez décompresser avant de les rendre. L'espace vide ne sera qu'un tas de zéros. Ma tâche consiste à travailler avec une bibliothèque de rendu de voxels très sophistiquée. Mon prochain article décrira ce qu'ils font.

— Nailer

La bibliothèque avec laquelle je travaille fait ce qui suit: crée des blocs de données et les stocke dans une base de données de fichiers plats. Chaque morceau a un identifiant. Chaque cube se compose de plusieurs morceaux. Pour chaque morceau, un certain nombre de niveaux de détails sont créés. Lorsque le niveau de détail le plus élevé a 100% des voxels, le deuxième plus élevé a 25% de tous les voxels, puis divise par 4 tous pour chaque niveau suivant. Les morceaux qui sont proches de vous peuvent être visualisés en utilisant le plus haut niveau de détail.

— Nailer

toutes les données sont expédiées sous forme compressée de la RAM vers la VRAM où elles sont gonflées par des algorithmes de compression GPGPU fonctionnant dans CUDA. Cela économise beaucoup de bande passante mémoire. Donc: vérifiez où se trouve le joueur et obtenez des blocs de détails de haut niveau, les choses les plus éloignées peuvent facilement être visualisées en utilisant l'un des niveaux de détail inférieurs.

— Nailer

Que diriez-vous d'utiliser un octree pour stocker le terrain?

Par exemple, air = pas de nœud, tous les autres types de terrain auraient un nœud avec le type de terrain.

Lors de l'insertion / suppression de nœuds, vous pouvez vérifier si les huit enfants de chaque nœud sur le chemin d'arborescence modifié ont le même type terain et les fusionner si nécessaire. De cette façon, de gros blocs du même matériau ne prendraient qu'un seul nœud.

— Exilyth
source

Créez-vous uniquement des cubes pour des parties de la géométrie visibles par le joueur? Ce serait ma première étape. Selon la taille de votre terrain, vous n'avez pas besoin d'avoir l'intégralité du monde chargé / dessin / visible / quoi que ce soit.

— Tetrad
source

Je crée uniquement le maillage pour les côtés des cubes qui ont de l'air vide à côté d'eux. En ce qui concerne le fait de ne pas dessiner de mailles que le joueur ne peut pas voir ... J'ai pensé à exclure tous les morceaux qui n'avaient aucun bloc visible, comme les grottes souterraines ou les trous qui menaient dans le sol à un angle. Je ne serais certainement pas en mesure de compter sur mes mailles pour la collision / le cheminement à ce stade, cependant.

— James Livingston