Quel type de matériel serait nécessaire pour rendre un minecraft de la taille de la Terre comme une carte?

J'ai pensé à ce problème. Est-il possible avec la technologie actuelle de créer une réplique 1: 1 de la Terre dans un jeu à base de voxel? Quelle est la meilleure structure de données pour stocker cette carte géante? Quel algorithme doit être utilisé pour rendre cette structure de données en temps réel?

Ces questions font ces hypothèses:

• Chaque voxel a une résolution de 1 mètre cube.

• Par souci de simplicité, chaque voxel ne nécessite que 1 octet d'informations de métadonnées. Ces informations seront utilisées pour stocker l'identification du «type» du voxel (terre, eau, roche, etc.).

• Le volume de la terre est de 1 * 10ˆ21 mètres cubes.

• Par «technologie actuelle», j'inclus tout ce qui est disponible dans le commerce, mais pas les super-ordinateurs.

• Seules la topographie de la Terre et la bathymétrie seront utilisées pour générer la carte. Les bâtiments humains, les plantes ou les grottes sont exclus. Les blocs souterrains seront choisis sur la base d'études géologiques, par exemple: si la profondeur est supérieure à 3000 km, rendre un voxel «magma».

• Tout comme dans Minecraft, la carte n'est pas statique, elle peut être modifiée en jeu.

• Une distance de tirage `` infinie '' est un gros plus, quel est l'intérêt d'avoir la terre entière sur une carte si vous ne pouvez pas voler et regarder la planète entière?

La première conclusion que j'ai tirée lorsque j'ai réfléchi à ce problème est que le stockage des données de la Terre de manière linéaire est irréalisable, en supposant que chaque voxel occupe seulement 1 octet de mémoire, cela nécessiterait encore 1 zettaoctet pour stocker la carte. Une sorte de compression est donc requise.

Je pense qu'un octree de voxel pourrait compresser la carte, mais je ne suis pas sûr de combien. L'entropie de cette carte de voxels est probablement très faible, donc je suppose qu'un niveau de compression très élevé peut être atteint.

Avertissement

Ceci est une question théorique, je n'ai aucune intention d'écrire un voxel terre

ÉDITER

L'ESA GOCE a déjà cartographié le géoïde terrestre avec une précision de 1 à 2 cm. Je crois que ces informations pourraient être utilisées pour générer une carte très précise de la hauteur de la Terre. Cela exclurait la nécessité d'utiliser un algorithme pour combler les lacunes de la topographie de la Terre.

Cela dépend de la méthode de subdivision spatiale que vous utilisez, bien que toutes les méthodes de subdivision (comme toute méthode de compression) finissent par disparaître où aucune compression supplémentaire ne peut avoir lieu, en raison des frais généraux de structure de données et d'autres facteurs logiques / mathématiques. Un exemple peut être trouvé en octets. Pour chaque nœud de l'octree, un pointeur doit être conservé vers son parent et / ou ses enfants (selon la façon dont vous gérez votre architecture de structure de données), pour permettre une traversée significative. Toute structure arborescente peut contenir n enfants. Plus le rapport 1: n est faible, plus vous gagnez d'espace et, par conséquent, plus les frais généraux dans l'arborescence sont importants, car vous devez avoir plus de nœuds ancêtres pour contenir le même nombre de voxels foliaires (dans votre cas, environ 510 trillions représentant la surface).

Étant donné que dans votre cas, les principaux problèmes sont les coûts de stockage et le rendu de la planète entière (ou de ses parties) à une distance raisonnable, il n'y a pas de structure de données que je recommanderais sur un octree. Le mipmapping est une nécessité: 12,8 millions de mètres de diamètre à la puissance supérieure la plus proche de 2 est 2 ^ 24 = 16,8 millions. 24 niveaux d'octree à parcourir équivaudraient à une quantité gargantuesque de branchements - très coûteux pour les GPU et les CPU. Mais à condition de bien faire les choses, vous n'aurez besoin de parcourir que quelques niveaux à la fois. Compte tenu de la quantité d'espace requise, cependant, les alternatives sont rares (voir ci-dessous).

Les capacités de mipmapping des octrees sont ce qui en fait un outil incroyablement puissant pour les gros volumes tels que ceux que vous décrivez. Contrairement à toutes les autres méthodes de subdivision connues (à l'exception des arbres KD), l'octree maintient la subdivision par niveau au minimum, ce qui signifie que les différences visuelles et physiques entre les niveaux de mipmap sont également minimes, ce qui signifie des deltas beaucoup plus fins dans la granularité lorsque vous montez et en bas de l'arbre.

Si, d'autre part, vous voulez générer un monde où la traversée de la grille hiérarchique est réduite au minimum, alors vous devrez échanger de l'espace pour augmenter la vitesse.

En parlant du rapport idéal 1: n, il n'y a pas de structure plus fine que l'arbre kd à cet égard. Lorsque l'octree se divise en 2 pour chaque axe, ce qui donne 2 ^ 3 = 8 cellules enfants individuelles, l'arbre kd se divise exactement une fois par niveau de subdivision. Le problème avec cela est que vous devez choisir un hyperplan pour vous séparer, et cet hyperplan pourrait être choisi autour de l'un des 3 axes. Bien qu'il soit optimal en termes d'espace, il rend les traversées 3D (comme pendant les raymarches, une opération fondamentale lors de l'utilisation d'octrees pour la physique ou le rendu) beaucoup plus difficiles que dans un octree, car une structure de type portail dynamique doit être conservée pour enregistrer interfaces entre les différents nœuds d'arbre kd.

RLE est une autre approche de la compression, mais est à bien des égards plus difficile à appliquer à un problème comme celui-ci (où la base des opérations est sphérique), car la compression RLE est unidimensionnelle et vous devez choisir l'axe dans lequel elle opère. planète, on pourrait choisir l'axe polaire, mais tout choix mono-axe introduirait certains problèmes de traversées pour le rendu et la physique lorsqu'ils agissent sous certains angles non optimaux. Bien sûr, vous pouvez également exécuter RLE sur 3 axes simultanément, triplant le coût de stockage, ou sur 6 axes (-x, + x, -y, + y, -z, + z) comme optimisation supplémentaire.

Alors pour répondre à votre question (ou pas!)

Je ne vais pas entrer directement dans la réponse à quel type de matériel, mais je pense que le regarder dans une perspective octree commence à vous donner une idée de ce qui est en fait possible sur quel type de matériel. Je vous encourage à emprunter cette voie, si vous voulez vraiment savoir, il serait peut-être plus facile de mettre en œuvre un simple octree clairsemé(voir l'article de Laine dans les références) et placez-y une coquille sphérique de voxels de surface, et voyez à quoi ressemble l'utilisation de l'espace qui en résulte. Intensifie à partir de là. Voyez jusqu'où vous pouvez aller avant que la mémoire de votre système ne commence à disparaître. Cela ne vous oblige pas à écrire un rendu à moins que vous ne souhaitiez la visualisation. Gardez également à l'esprit que cela est mieux fait sur le processeur - les GPU n'ont généralement pas la capacité de mémoire pour faire face à des problèmes de cette ampleur. C'est l'une des raisons pour lesquelles Intel envisage de s'orienter vers des processeurs massivement parallèles: les avantages du GPGPU, qui est meilleur dans ce genre de choses, peuvent être appliqués à un espace mémoire beaucoup plus vaste sans goulots d'étranglement du bus système. Il y en a probablement d'autres ici, ou sur mathématique.stackexchange.com,

En termes d'exigence de distance de vue infinie, bien sûr, mais la question se résume toujours à "combien de détails à quelle distance". Le rendu de détails infinis nécessiterait des ressources infinies. C'est là que le mipmapping variable par scène entre en jeu. Gardez également à l'esprit que toutes les structures de données incarnent un compromis entre la vitesse et l'espace ou vice versa. Cela signifie un rendu moins / plus lent, si vous voulez un monde plus grand pour le même effort d'ingénierie.

La première conclusion que j'ai tirée lorsque j'ai réfléchi à ce problème est que le stockage des données de la Terre de manière linéaire est irréalisable, en supposant que chaque voxel occupe seulement 1 octet de mémoire, cela nécessiterait encore 1 zettaoctet pour stocker la carte. Une sorte de compression est donc requise.

Étant donné que vous ne découvrirez probablement jamais les propriétés de chaque mètre cube du monde réel, vous aurez besoin d'un moyen de générer ces données qui sont incertaines sur la base d'hypothèses. Donc, si vous avez compris cela, il n'est pas nécessaire de calculer et de stocker toutes ces données, mais vous pouvez plutôt les générer à la volée.

Tout d'abord, vous pouvez jeter tous les voxels dans la terre, car ceux-ci ne devront être calculés que si quelqu'un creuse un trou, par exemple. les voxels deviennent visibles.

Pour la surface de la terre, je prendrais probablement une image comme point de départ pour mes calculs. Peut-être qu'une sorte de carte de température et d'humidité vous permettra de calculer le type de blocs à appliquer. Par exemple. L'eau, le sable (désert), l'herbe, la neige, etc. Étant donné que l'image n'aura probablement pas un pixel d'information pour chaque mètre carré de surface terrestre, vous devrez mélanger cela avec du bruit pour générer un peu de variation sur la surface. Si vous utilisez toujours les mêmes graines aléatoires, votre résultat devrait néanmoins être déterministe.

De plus, une carte d'élévation serait utile, afin que vous puissiez déterminer la hauteur des éléments de surface. De cette façon, vous pouvez ajouter des montagnes, etc.

Cela se résume donc à un volume de données de quelques images 2D qui contiennent des informations sur la surface de la terre. Pour tout à l'intérieur, vous reviendriez à une approche procédurale pure, où vous restituer différents types de blocs, en fonction de la distance du centre de la terre. Mais comme indiqué ci-dessus, ceux-ci doivent être calculés uniquement lorsque quelqu'un creuse un trou.

Pour que les changements persistent, je n'enregistrerais que les modifications apportées au monde. Donc, si quelqu'un creuse un trou, je stockerais des informations sur les voxels qui ont été supprimés, car je devrais pouvoir rendre les voxels environnants de manière procédurale.

En ce qui concerne le rendu: vous aurez besoin de certains algorithmes sophistiqués de niveau de détail et d'élimination pour que cela fonctionne. Il est stupide de rendre tous les voxels de surface, lorsque la caméra est à un niveau de zoom qui montre le monde entier. À ce niveau, les voxels devraient être beaucoup plus gros, peut-être même une simple sphère texturée suffirait.

Je suppose que la chose la plus délicate serait d'avoir un générateur solide qui vous permet de calculer les propriétés des voxels, même pour différentes "résolutions", afin que vous puissiez l'utiliser pour générer différents niveaux de détail.

Vous pouvez essentiellement faire la même chose que Minecraft. Plutôt que de créer une telle quantité de données, vous pouvez définir un monde comme une formule mathématique, chaque fois qu'un élément de données est requis pour l'affichage, vous le générez à l'aide de la formule.

Une telle formule est généralement construite en utilisant le concept de bruit Perlin , cela permet des détails à tous les niveaux, vous pouvez avoir des chaînes de montagnes aussi grandes que celles du monde réel, mais choisissez de n'en générer qu'une petite partie. Vous pouvez générer la quantité de détails que vous aimez, il est donc possible de faire des détails très fins pour des choses proches, tout en générant également des décors éloignés avec le niveau de détail requis.

Minecraft enregistre tous les blocs que vous avez visités, avec toutes les modifications apportées, on pourrait simplement enregistrer uniquement la différence entre le monde généré et le monde mis à jour, mais je suppose que la sauvegarde de gros blocs était plus facile, et ils se compressent relativement bien.

Je ne pense pas qu'il existe un jeu qui pousse vraiment cela à la limite, mais il est très courant d'utiliser la génération de formule de tous les détails "sans importance" des grands mondes du jeu. Je ne sais pas à quel point l'approche de génération en cas de besoin est courante, par opposition à simplement générer le lot et le mettre sur le disque.

Vous pouvez rechercher des données vectorielles des masses terrestres de la Terre, car les données vectorielles ont l'avantage d'être mises à l'échelle à n'importe quelle échelle. Combinez-le avec une carte de la hauteur de la Terre pour générer la hauteur du terrain. La dernière étape est une imagerie satellite détaillée, d'où vous pouvez choisir le type du bloc supérieur en fonction de l'image, de sorte que vous obtenez de la roche là où il y a de la roche, du sable là où il y a du sable, etc. L'intérieur réel de la planète devrait probablement être généré comme Minecraft le fait, sauf si vous pouvez trouver des données géographiques détaillées à partir desquelles travailler. Fondamentalement, ce que vous voulez faire, c'est trouver des données géographiques et les extrapoler à partir de l'entrée de coordonnées XYZ uniquement. Cela signifie que vous disposez de données limitées et que vous extrapolez le reste aussi précisément que possible.