Rêver en cubes | Vers la science des données

cela m’est cher (et à beaucoup d’autres) parce qu’il m’a, d’une certaine manière, vu grandir d’un élève du primaire jusqu’à un (bientôt !) diplômé d’université. Une partie indéniable du charme du jeu réside dans sa rejouabilité infinie dérivée de sa génération mondiale. Dans les éditions actuelles du jeu, Minecraft utilise diverses fonctions de bruit en conjonction avec générer de manière procédurale [1] ses mondes sous forme de morceaux, c’est-à-dire $16 fois 16 fois 384$ blocs, d’une manière qui tend à former (plus ou moins) un terrain d’apparence « naturelle », fournissant une grande partie de l’immersion du jeu.

Mon objectif avec ce projet était de voir si je pouvais aller au-delà du bruit codé en dur et plutôt apprendre à un modèle à « rêver » dans les voxels. En tirant parti des développements récents des auto-encodeurs variationnels quantifiés vectoriels (VQ-VAE) et des transformateurs, j’ai construit un pipeline pour générer des tranches du monde 3D qui capturent l’essence structurelle des paysages du jeu. Comme résultat concret, je voulais avoir la capacité de générer $4$ morceaux (disposés dans un $2 \fois 2$ grille) qui ressemblait au terrain de Minecraft.

En passant, ce n’est pas une idée entièrement nouvelle, à savoir : MorceauGAN [2] propose une approche alternative pour atteindre le même objectif.

Le défi de la modélisation générative 3D

Dans un vidéo [3] à partir de janvier 2026, Computerphile a présenté Lewis Stuart qui a mis en évidence les principaux problèmes liés à la génération 3D et j’encourage les lecteurs à y jeter un œil. Cependant, pour résumer les points clés, la génération 3D est difficile car de bons ensembles de données 3D sont difficiles à trouver ou n’existent tout simplement pas et l’ajout d’une dimension de liberté rend les choses beaucoup plus difficiles (pensez au classique Problème à trois corps [4]). Il convient de noter que la vidéo aborde explicitement les modèles de diffusion (qui nécessitent des données étiquetées), même si de nombreuses préoccupations peuvent être transférées à l’idée générale de génération 3D. Un autre problème est simplement celui de l’échelle ; un $512 \fois 512$ image ($2^{18}$ pixels) serait presque certainement considéré comme une basse résolution par rapport aux normes modernes, mais un modèle 3D avec la même fidélité nécessiterait $2^{27}$ voxels. Plus de points implique immédiatement des exigences de calcul plus élevées et peut rapidement rendre de telles tâches irréalisables.

Pour pallier la rareté des données 3D évoquée par Stuart, je me suis tourné vers Minecraft qui, à mon avis, est la meilleure source de données voxel disponible pour la génération de terrain. En utilisant un script pour me téléporter à travers un monde pré-généré, j’ai forcé le moteur de jeu à charger et à restituer des milliers de morceaux uniques. À l’aide d’un script d’extraction distinct, j’ai extrait ces morceaux directement des fichiers de région du jeu. Cela m’a donné un ensemble de données avec une grande cohérence sémantique ; contrairement à une collection d’objets 3D aléatoires, ces morceaux représentent un paysage continu et fluide où la « logique » du terrain (la façon dont le lit d’une rivière plonge ou la façon dont les sommets d’une montagne) est préservée au-delà des limites des morceaux.

Pour combler le fossé entre la complexité des voxels 3D et les limites du matériel moderne, je ne pouvais pas simplement introduire des morceaux bruts dans un modèle et espérer le meilleur. J’avais besoin d’un moyen de condenser le « bruit » de millions de blocs dans un langage compressé et significatif. Cela m’a conduit au cœur du projet : un pipeline génératif en deux étapes qui apprend d’abord à « tokeniser » l’espace 3D, puis à le « parler ».

Prétraitement des données

Une observation clé mais non évidente est qu’une partie importante des morceaux de Minecraft sont remplis de blocs « aériens ». C’est une observation non triviale principalement parce que l’air n’est pas techniquement un bloc, vous ne pouvez pas le placer ou le supprimer comme vous pouvez le faire avec tous les autres blocs du jeu, mais plutôt la non-existence d’un bloc à ce stade. Dans Minecraft moderne, la majeure partie de la portée verticale est constituée d’air et, en tant que telle, au lieu de considérer la totalité de la portée verticale $384$ niveaux de hauteur, je l’ai limité à $y \dans [0, 128]$. Ceux qui connaissent mieux la génération mondiale de Minecraft sauront que les blocs ont des effets négatifs. $oui$-des valeurs, jusqu’à $-64$ et à ce stade, je dois m’excuser car lorsque j’ai implémenté cette architecture, cela m’avait complètement échappé. Le modèle que je présente dans cet article fonctionnerait tout aussi bien si vous considériez une portée verticale plus grande, mais en raison de mon malheureux oubli, les résultats que je présente proviendront d’une étendue de blocs restreinte.

Côté blocs restrictifs, les chunks contiennent de nombreux blocs qui n’apparaissent pas très souvent et ne contribuent pas à la forme générale du terrain mais sont nécessaires au maintien de l’immersion du joueur. Au moins pour ce projet, j’ai choisi de limiter les blocs aux 30 premiers blocs qui constituaient les morceaux par fréquence.

Élaguer le vocabulaire, pour ainsi dire, est utile mais ne représente que la moitié de la bataille. Comme indiqué précédemment, étant donné que les mondes Minecraft sont principalement composés d’« air » et de « pierre », l’ensemble de données souffre d’un déséquilibre de classe assez extrême. Pour empêcher le modèle d’emprunter le « chemin de moindre résistance », c’est-à-dire simplement prédire l’espace vide pour obtenir une faible perte, j’ai mis en œuvre une perte d’entropie croisée pondérée. En ajustant la perte en fonction de la fréquence logarithmique inverse de chaque bloc, j’ai forcé le VQ-VAE à donner la priorité aux « minorités » structurelles comme l’herbe, l’eau et la neige.

$\text{poids[block]} = \frac{1}{\log(1.1 + \text{probabilité[block]})}$

En termes simples : plus un type de bloc est rare dans l’ensemble de données, plus le modèle est lourdement pénalisé pour ne pas l’avoir prédit, ce qui pousse le réseau à traiter une parcelle de neige ou un lit de rivière aussi important que les vastes étendues de pierre et d’air qui dominent la plupart des morceaux.

Présentation de l’architecture

Cette séquence de sirèneDiagramme [6] offre une vue plongeante sur l’architecture.

Problème de voxel brut et tokenisation de l’espace 3D

Une approche naïve de la construction d’une telle architecture impliquerait d’apprendre et de construire des morceaux bloc par bloc. Il existe une myriade de raisons pour lesquelles cela ne serait pas idéal, mais le problème le plus important est que cela peut devenir très rapidement irréalisable sur le plan informatique sans vraiment fournir de structure sémantique. Imaginez assembler un ensemble LEGO avec des milliers de $1 \fois 1$ briques. Bien que cela soit possible, cela serait beaucoup trop lent et n’aurait pas vraiment d’intégrité structurelle : les pièces adjacentes horizontalement ne seraient pas connectées et vous construiriez essentiellement un ensemble de tours disjointes. La façon dont LEGO résout ce problème est d’avoir des blocs plus gros, comme l’emblématique $2 \fois 4$ brique, qui occupent un espace qui nécessiterait normalement plusieurs $1 \fois 1$ pièces. Ainsi, vous remplissez l’espace plus rapidement et l’intégrité structurelle est accrue.

Pour le système, les mots de passe sont les $2 \fois 4$ Briques LEGO. À l’aide d’un VQ-VAE (Vector Quantized Variational AutoEncoder), l’objectif est de créer un livre de codes, c’est-à-dire un ensemble de signatures structurelles qu’il peut utiliser pour reconstruire des morceaux complets. Pensez à des structures comme une section plate d’herbe ou une goutte de diorite. Dans mon implémentation, j’ai autorisé un livre de codes avec $512$ codes uniques.

Pour implémenter cela, j’ai utilisé des convolutions 3D. Alors que les convolutions 2D constituent le pain quotidien du traitement d’image, les convolutions 3D permettent au modèle d’apprendre les noyaux qui glissent simultanément sur les axes X, Y et Z. Ceci est vital pour Minecraft, où la relation entre un bloc et celui en dessous (gravité/support) est tout aussi importante que sa relation avec celui à côté.

Plus de détails

Le composant le plus critique de cette étape est le « VectorQuantizer ». Cette couche se situe au « goulot d’étranglement » du réseau, forçant les signaux neuronaux continus à s’aligner sur un « vocabulaire » fixe de 512 formes 3D apprises.

L’un de mes plus grands obstacles dans la formation VQ-VAE réside dans les intégrations « mortes », c’est-à-dire les mots de code que l’encodeur ne choisit jamais, ce qui gaspille effectivement la capacité du modèle. Pour résoudre ce problème, j’ai ajouté un moyen de « réinitialiser » les mots de passe morts. Si l’utilisation d’un mot de passe devient trop faible, le modèle le réinitialise de force en « volant » un vecteur du lot d’entrée actuel :

Brique par brique

Un assortiment diversifié de blocs est formidable, mais ils ne signifient pas grand-chose s’ils ne sont pas bien assemblés. Par conséquent, pour utiliser ces mots de passe à bon escient, j’ai utilisé un GPT. Pour que cela fonctionne, j’ai transformé la grille latente produite par le VQ-VAE en un ensemble de jetons. Essentiellement, le monde 3D est aplati dans un langage 1D. Ensuite, le GPT voit 8 morceaux de jetons pour apprendre la grammaire spatiale, pour ainsi dire, de Minecraft afin d’atteindre la cohérence sémantique susmentionnée.

Pour y parvenir, j’ai utilisé Casual Self-Attention :

Enfin, lors de l’inférence, le modèle utilise un échantillonnage top-k, ainsi qu’une certaine température pour contrôler génération erratique créativité dans la boucle de génération suivante :

À la fin de cette séquence, le GPT a « écrit » un plan structurel de 256 jetons. L’étape suivante consiste à les transmettre via le décodeur VQ-VAE pour manifester un $2 \fois 2$ grille de terrain Minecraft reconnaissable.

Résultats

Dans ce rendu [6]le modèle regroupe avec succès les blocs de feuilles, imitant les structures arborescentes du jeu.

Dans celui-ci [6]le modèle utilise des blocs de neige pour recouvrir la pierre et l’herbe, reflétant les tranches de haute altitude ou de toundra trouvées dans les données d’entraînement. De plus, ce rendu montre que le modèle a appris à générer des grottes.

Dans cette image [6]le modèle place l’eau dans une dépression et la borde de sable, démontrant qu’il a internalisé la logique spatiale d’un littoral, plutôt que de disperser arbitrairement des blocs d’eau sur la surface.

Le résultat le plus impressionnant est peut-être la structure interne des morceaux. Étant donné que l’implémentation utilise des convolutions 3D et une fonction de perte pondérée, le modèle génère en réalité des caractéristiques souterraines telles que des grottes contiguës, des surplombs et des falaises.

Bien que les résultats soient reconnaissables, ce ne sont pas des clones parfaits de Minecraft. La compression du VQ-VAE est « avec perte », ce qui entraîne parfois un léger « flou » des limites des blocs ou un bloc flottant occasionnel. Cependant, pour un modèle fonctionnant sur un espace latent hautement compressé, la capacité à maintenir l’intégrité structurelle à travers un $2 \fois 2$ la grille de morceaux, je crois, est un succès significatif.

Réflexions et travaux futurs

Même si le modèle « rêve » avec succès dans les voxels, il reste une marge d’expansion importante. Les itérations futures pourraient revisiter toute l’étendue verticale de $y \dans [−64,320]$ pour s’adapter aux énormes pics déchiquetés et aux profondes grottes de « fromage » caractéristiques des versions modernes de Minecraft. De plus, étendre le livre de codes au-delà de 512 entrées permettrait au système de symboliser des structures de niche plus complexes comme des villages ou des temples du désert. Le plus intéressant est peut-être le potentiel de génération conditionnelle, ou de « biomérisation » du GPT, qui permettrait aux utilisateurs de guider le processus architectural avec des invites spécifiques telles que « Montagne » ou « Océan », transformant un rêve aléatoire en un outil de création dirigé.

Merci d’avoir lu! Si vous êtes intéressé par la mise en œuvre complète ou si vous souhaitez expérimenter vous-même les poids, n’hésitez pas à consulter le dépôt [5].

Citations et liens

[1] Éditeurs Wiki Minecraft, Génération mondiale (2026), https://minecraft.wiki/w/World_generation

[2] x3voo, ChunkGAN (2024), https://github.com/x3voo/ChunkGAN

[3] Lewis Stuart pour Computerphile, Génération de modèles 3D avec diffusion – Computerphile (2026), https://www.youtube.com/watch?v=C1E500opYHA

[4] Éditeurs Wikipédia, Problème à trois corps (2026), https://en.wikipedia.org/wiki/Three-body_problem

[5] spaceybread, robot lumineux (2026), https://github.com/spaceybread/glowing-robot/tree/master

[6] Image de l’auteur.

Une note sur l’ensemble de données

Toutes les données de formation ont été générées par l’auteur à l’aide d’une instance exécutée localement de Minecraft Java Edition. Des morceaux ont été extraits de fichiers mondiaux générés de manière procédurale à l’aide d’un script d’extraction personnalisé. Aucun ensemble de données tiers n’a été utilisé. Étant donné que les données ont été générées et extraites par l’auteur à partir de sa propre instance de jeu, aucune restriction de licence externe ne s’applique à son utilisation dans ce contexte de recherche.