eso es querido para mí (y para muchos otros) porque, en cierto modo, me ha visto crecer desde un estudiante de escuela primaria hasta un (¡próximamente!) graduado universitario. Una parte innegable del encanto del juego es su rejugabilidad infinita derivada de su generación mundial. En las ediciones actuales del juego, Minecraft utiliza una variedad de funciones de ruido en conjunto para generar procedimientos [1] sus mundos en forma de trozos, es decir, 16×16×38416 \times 16 \times 384 bloques, de una manera que tiende (más o menos) a formar un terreno de aspecto “natural”, proporcionando gran parte de la inmersión del juego.
Mi objetivo con este proyecto era ver si podía ir más allá del ruido codificado y, en cambio, enseñarle a un modelo a “soñar” en vóxeles. Aprovechando los desarrollos recientes en codificadores automáticos variacionales cuantificados vectoriales (VQ-VAE) y transformadores, construí un canal para generar cortes del mundo en 3D que capturan la esencia estructural de los paisajes del juego. Como resultado concreto, quería tener la capacidad de generar 44 fragmentos (dispuestos en una cuadrícula de 2×22 × 2) que se pareciera al terreno de Minecraft.
Como nota al margen, esta no es una idea completamente nueva, concretamente, ChunkGAN [2] proporciona un enfoque alternativo para abordar el mismo objetivo.
El desafío del modelado generativo 3D
en un vídeo [3] desde enero de 2026, Computerphile presentó a Lewis Stuart que destacó los principales problemas con la generación 3D y animaría a los lectores a que lo vean; sin embargo, para resumir los puntos clave, la generación 3D es difícil porque es difícil encontrar buenos conjuntos de datos 3D o simplemente no existen y agregar una dimensión de libertad hace las cosas mucho más difíciles (considere el clásico problema de los tres cuerpos [4]). Cabe señalar que el video aborda explícitamente los modelos de difusión (que requieren datos etiquetados), aunque muchas de las preocupaciones pueden trasladarse a la idea general de generación 3D. Otra cuestión es simplemente la escala; una imagen de 512×512512 \times 512 (2182^{18} píxeles) casi con certeza se consideraría de baja resolución según los estándares modernos, pero un modelo 3D con la misma fidelidad requeriría 2272^{27} vóxeles. Más puntos implican inmediatamente mayores requisitos informáticos y rápidamente pueden hacer que dichas tareas sean inviables.
Para superar la escasez de datos 3D mencionada por Stuart, recurrí a Minecraft, que, en mi opinión, es la mejor fuente de datos de vóxeles disponible para la generación de terreno. Al usar un script para teletransportarme a través de un mundo pregenerado, obligué al motor del juego a cargar y renderizar miles de fragmentos únicos. Utilizando un script de extracción independiente, extraje estos fragmentos directamente de los archivos regionales del juego. Esto me dio un conjunto de datos con alta coherencia semántica; A diferencia de una colección de objetos 3D aleatorios, estos fragmentos representan un paisaje continuo y fluido donde la “lógica” del terreno (cómo desciende el lecho de un río o cómo se eleva una montaña) se conserva sobre los límites de los fragmentos.
Para cerrar la brecha entre la complejidad de los vóxeles 3D y las limitaciones del hardware moderno, no podía simplemente introducir trozos sin procesar en un modelo y esperar lo mejor. Necesitaba una forma de condensar el “ruido” de millones de bloques en un lenguaje comprimido y significativo. Esto me llevó al corazón del proyecto: un proceso generativo de dos etapas que primero aprende a “tokenizar” el espacio 3D y luego aprende a “hablarlo”.
Preprocesamiento de datos
Una observación clave, aunque no obvia, es que una parte importante de los fragmentos de Minecraft están llenos de bloques de “aire”. Es una observación no trivial principalmente porque el aire no es técnicamente un bloque, no puedes colocarlo ni quitarlo como puedes hacerlo con cualquier otro bloque en el juego, sino que es la inexistencia de un bloque en ese punto. En Minecraft moderno, la mayor parte del tramo vertical es aire y, como tal, en lugar de considerar 384384 niveles de altura completos, lo restringí a y∈[0,128]y \en [0, 128]. Aquellos más familiarizados con la generación mundial de Minecraft sabrían que los bloques tienen valores yy negativos, hasta −64-64 y en este punto, debo disculparme porque cuando implementé esta arquitectura, esto se me había olvidado por completo. El modelo que presento en este artículo funcionaría igual de bien si considerara un tramo vertical más grande, pero debido a mi desafortunado descuido, los resultados que presento serán de un tramo restringido de bloques.
En cuanto a los bloques restringidos, los fragmentos tienen muchos bloques que no aparecen muy a menudo y no contribuyen a la forma general del terreno, pero son necesarios para mantener la inmersión del jugador. Al menos para este proyecto, elijo restringir los bloques a los 30 bloques principales que formaron fragmentos por frecuencia.
Podar el vocabulario, por así decirlo, es útil, pero sólo es la mitad de la batalla. Como se indicó anteriormente, debido a que los mundos de Minecraft se componen principalmente de “aire” y “piedra”, el conjunto de datos sufre un desequilibrio de clases bastante extremo. Para evitar que el modelo tome el “camino de menor resistencia”, es decir, simplemente prediciendo el espacio vacío para lograr una pérdida baja, implementé una pérdida de entropía cruzada ponderada. Al escalar la pérdida en función de la frecuencia logarítmica inversa de cada bloque, obligué al VQ-VAE a priorizar las “minorías” estructurales como la hierba, el agua y la nieve.
peso[block]=1log(1.1+probabilidad[block])\text{peso[block]} = \frac{1}{\log(1.1 + \text{probabilidad[block]})}
En términos sencillos: cuanto más raro sea un tipo de bloque en el conjunto de datos, más penalizado será el modelo por no predecirlo, lo que obligará a la red a tratar un trozo de nieve o el lecho de un río tan importante como las vastas extensiones de piedra y aire que dominan la mayoría de los trozos.
Descripción general de la arquitectura
Esta secuencia de sirenaDiagrama [6] ofrece una vista panorámica de la arquitectura.
Problema de vóxel crudo y tokenización del espacio 3D
Un enfoque ingenuo para construir una arquitectura de este tipo implicaría aprender y construir fragmentos bloque por bloque. Hay innumerables razones por las que esto no sería ideal, pero el problema más importante es que puede volverse computacionalmente inviable muy rápidamente sin proporcionar realmente una estructura semántica. Imagínese ensamblar un juego de LEGO con miles de ladrillos de 1×11 \times 1. Si bien es posible, sería demasiado lento y realmente no tendría ninguna integridad estructural: las piezas adyacentes horizontalmente no estarían conectadas y esencialmente estarías construyendo un conjunto de torres separadas. La forma en que LEGO aborda esto es con bloques más grandes, como el icónico ladrillo de 2×42 \times 4, que ocupan un espacio que normalmente requeriría múltiples piezas de 1×11 \times 1. Como tal, se llena el espacio más rápido y hay más integridad estructural.
Para el sistema, las palabras clave son los ladrillos LEGO de 2×42 \times 4. Usando un VQ-VAE (Codificador automático variacional cuantificado vectorial), el objetivo es construir un libro de códigos, es decir, un conjunto de firmas estructurales que pueda usar para reconstruir fragmentos completos. Piense en estructuras como una sección plana de césped o una masa de diorita. En mi implementación, permití un libro de códigos con 512512 códigos únicos.
Para implementar esto, utilicé convoluciones 3D. Si bien las convoluciones 2D son el pan y la mantequilla del procesamiento de imágenes, las convoluciones 3D permiten que el modelo aprenda núcleos que se deslizan por los ejes X, Y y Z simultáneamente. Esto es vital para Minecraft, donde la relación entre un bloque y el que está debajo (gravedad/soporte) es tan importante como su relación con el que está al lado.
Más detalles
El componente más crítico de esta etapa es el “VectorQuantizer”. Esta capa se encuentra en el “cuello de botella” de la red, lo que obliga a las señales neuronales continuas a ajustarse a un “vocabulario” fijo de 512 formas 3D aprendidas.
Uno de mis mayores obstáculos en el entrenamiento VQ-VAE son las incrustaciones “muertas”, es decir, palabras en código que el codificador nunca elige, que efectivamente desperdician la capacidad del modelo. Para resolver esto, agregué una forma de “restablecer” palabras clave muertas. Si el uso de una palabra en clave cae demasiado, el modelo la reinicializa a la fuerza “robando” un vector del lote de entrada actual:
Ladrillo a ladrillo
Una variedad diversa de bloques es genial, pero no significan mucho a menos que estén bien armados. Por lo tanto, para darle un buen uso a estas palabras en clave, utilicé un GPT. Para que esto funcione, tomé la cuadrícula latente producida por el VQ-VAE en un conjunto de tokens; esencialmente, el mundo 3D se aplana en un lenguaje 1D. Luego, el GPT ve 8 fragmentos de tokens para aprender la gramática espacial, por así decirlo, de Minecraft para lograr la coherencia semántica antes mencionada.
Para lograr esto, utilicé la Autoatención informal:
Finalmente, durante la inferencia, el modelo utiliza muestreo top-k, junto con algo de temperatura para controlar la creatividad generacional errática en el siguiente ciclo de generación:
Al final de esta secuencia, el GPT ha “escrito” un plano estructural de 256 tokens de longitud. El siguiente paso es pasarlos a través del decodificador VQ-VAE para manifestar una cuadrícula de 2×22 \×2 de terreno reconocible de Minecraft.
Resultados
en este render [6]el modelo agrupa con éxito bloques de hojas, imitando las estructuras de árbol del juego.
en este [6]el modelo utiliza bloques de nieve para cubrir la piedra y la hierba, reflejando las zonas de gran altitud o tundra que se encuentran en los datos de entrenamiento. Además, este render muestra que el modelo aprendió a generar cuevas.
en esta imagen [6]el modelo coloca agua en una depresión y la bordea con arena, lo que demuestra que ha interiorizado la lógica espacial de una costa, en lugar de esparcir bloques de agua arbitrariamente por la superficie.
Quizás el resultado más impresionante sea la estructura interna de los trozos. Debido a que la implementación utilizó convoluciones 3D y una función de pérdida ponderada, el modelo en realidad genera características subterráneas como cuevas, voladizos y acantilados contiguos.
Si bien los resultados son reconocibles, no son clones perfectos de Minecraft. La compresión del VQ-VAE tiene “pérdidas”, lo que a veces da como resultado una ligera “difuminación” de los límites del bloque o el bloque flotante ocasional. Sin embargo, para un modelo que opera en un espacio latente altamente comprimido, creo que la capacidad de mantener la integridad estructural en una cuadrícula de 2×22 \times 2 es un éxito significativo.
Reflexiones y trabajo futuro
Si bien el modelo “sueña” con éxito en vóxeles, hay un importante margen de expansión. Las iteraciones futuras podrían revisar el tramo vertical completo de y∈[−64,320]y \en [−64,320] para dar cabida a los enormes picos irregulares y las profundas cuevas de “queso” características de las versiones modernas de Minecraft. Además, ampliar el libro de códigos más allá de 512 entradas permitiría al sistema tokenizar estructuras de nicho más complejas, como aldeas o templos en el desierto. Quizás lo más interesante sea el potencial de generación condicional, o “biomerización” del GPT, lo que permitiría a los usuarios guiar el proceso arquitectónico con indicaciones específicas como “Montaña” u “Océano”, convirtiendo un sueño aleatorio en una herramienta creativa dirigida.
¡Gracias por leer! Si está interesado en la implementación completa o desea experimentar con los pesos usted mismo, no dude en consultar el repositorio. [5].
Citas y enlaces
[1] Editores de Minecraft Wiki, Generación mundial (2026), https://minecraft.wiki/w/World_generación
[2] x3voo, ChunkGAN (2024), https://github.com/x3voo/ChunkGAN
[3] Lewis Stuart para Computerphile, Generación de modelos 3D con difusión – Computerphile (2026), https://www.youtube.com/watch?v=C1E500opYHA
[4] Editores de Wikipedia, Problema de los tres cuerpos (2026), https://en.wikipedia.org/wiki/Three-body_problem
[5] pan espacial, robot-brillante (2026), https://github.com/spaceybread/glowing-robot/tree/master
[6] Imagen del autor.
Una nota sobre el conjunto de datos
Todos los datos de entrenamiento fueron generados por el autor utilizando una instancia ejecutada localmente de Minecraft Java Edition. Se extrajeron fragmentos de archivos mundiales generados por procedimientos utilizando un script de extracción personalizado. No se utilizaron conjuntos de datos de terceros. Dado que los datos fueron generados y extraídos por el autor de su propia instancia de juego, no se aplican restricciones de licencia externa a su uso en este contexto de investigación.