El contenido de este sitio se ha traducido mediante inteligencia artificial (IA) o tecnología de traducción automática, y puede contener errores.

Skip to content

CubePart: un generador 3D de vocabulario abierto y controlable por partes

Creación de recursos funcionales listos para el juego

SEO image for CubePart: An Open-Vocabulary Part-Controllable 3D Generator

Los modelos generativos 3D modernos pueden generar objetos 3D hermosos y complejos a partir de indicaciones de texto, pero para un desarrollador de videojuegos, un modelo 3D monolítico no resulta útil. Un coche, por ejemplo, tiene que poder conducirse. Las ruedas deben girar por separado, las puertas deben abrirse y los faros deben encenderse. 

Actualmente, los artistas 3D tienen que dividir manualmente los modelos generados y nombrar las partes, un proceso que no se adapta bien a la escala. Nuestro gran avance es CubePart: el primer marco de IA generativa que permite la generación de mallas 3D con vocabulario abierto y control de partes. CubePart genera un conjunto ensamblado de mallas distintas, funcionales y etiquetadas con precisión que se ajustan a las necesidades de programación del desarrollador desde el primer momento.

CubePart amplía el concepto de esquemas fijos que introdujimos con 4D Generation para permitir al creador definir la lista de partes en las que debe dividirse un objeto. El conjunto de mallas generadas por CubePart se integra directamente en el motor del juego y puede controlarse mediante scripts de animación, física y jugabilidad sin necesidad de limpieza manual. Hemos publicado nuestra investigación sobre CubePart en arXiv y hemos actualizado nuestro repositorio de código abierto Cube para que admita la generación con control por partes. A finales de este año, presentaremos nuestros hallazgos en SIGGRAPH

Esquema: el contrato de API para activos 3D interactivos

En Roblox, el comportamiento interactivo se implementa en scripts que operan sobre partes: elementos secundarios específicos y con nombre de un activo. Incluso activos similares pueden requerir partes completamente diferentes dependiendo del juego o la situación. Una taxonomía fija limitaría la creatividad y la funcionalidad, por lo que CubePart ofrece dos entradas: 

  1. Un mensaje de texto global que describe el aspecto del objeto: p. ej., «un coche de carreras con temática de medusa».
  2. Una lista específica y abierta de partes necesarias denominada esquema: p. ej., «rueda delantera izquierda», «rueda delantera derecha», «rueda trasera izquierda», «rueda trasera derecha», «pistola», «faros», «tubo de escape», «carrocería». 

El esquema es el contrato de la API entre el activo y el código del juego, y CubePart permite al creador generar activos que se ajusten al contrato. Este control de vocabulario abierto permite a CubePart capturar la diversidad de activos y experiencias de Roblox.

Generación en dos etapas 

CubePart es una arquitectura de difusión en dos etapas basada en una representación de formas latentes VecSet

En las ilustraciones siguientes, el usuario introduce dos indicaciones. 

  1. La indicación de texto global: «Una grúa caracterizada por rasgos caricaturescos». 
  2. El esquema: «cabina», «chasis», «ruedas», «luz de techo», «conjunto de remolque».

La etapa 1 se encarga de definir la forma básica del objeto (una grúa caracterizada por rasgos caricaturescos). Esta etapa genera una única latente para todo el objeto utilizando una arquitectura MMDiT con el codificador de texto Qwen-VL, entrenado con aproximadamente 4,7 millones de pares de malla-texto. Esta es la etapa que más datos consume: mapear el lenguaje de vocabulario abierto a la geometría 3D es la parte difícil del 3D generativo, y requiere un corpus grande y diverso para funcionar bien. Además, ajustamos la etapa 1 para que tenga en cuenta el esquema. 

La etapa 2 toma el latente de la etapa 1 y genera un latente de parte para cada entrada del esquema con el fin de reconstruir el objeto con sus partes. Para nuestro ejemplo de la grúa de dibujos animados, la etapa 2 genera un latente de parte independiente para la cabina, el chasis, las ruedas, la luz de techo y el conjunto de remolque, con el fin de reconstruir la grúa final con partes diferenciadas y funcionales. Los datos 3D etiquetados por partes son mucho más escasos que los datos de malla y texto. Dado que la Etapa 1 absorbe la compleja correspondencia entre texto y forma a partir de un corpus más amplio, la Etapa 2 solo tiene que aprender dónde se sitúan los límites de las partes en un objeto que el modelo ya comprende. Consideramos que la ablación descrita en el artículo es una prueba directa de ello: eliminar el preentrenamiento de la Etapa 1 degrada de forma apreciable la generalización de vocabulario abierto de la Etapa 2. En resumen, la Etapa 1 es lo que permite a la Etapa 2 generalizar. 
Otra innovación fundamental en nuestra arquitectura es la forma en que se comunican las partes. Nuestra solución consiste en insertar bloques de atención entre partes específicos en lugar de modificar los existentes, con proyecciones de salida inicializadas a cero para que empiecen como operaciones nulas y aprendan la comunicación entre partes sin alterar la ruta preentrenada. El principio resultará familiar a los lectores de ControlNet, aplicado aquí a la descomposición de partes en 3D. En nuestro ejemplo de la grúa, los bloques de atención entre partes garantizan que la cabina y el conjunto de remolque se integren a la perfección y se coloquen correctamente en relación con el chasis y las ruedas.

Nuestro conjunto de datos y el proceso de VLM 

Para entrenar CubePart, creamos un conjunto de datos con más de 460 000 activos —más de 11 veces mayor que los conjuntos de datos públicos anteriores¹— y 2,02 millones de piezas. En lugar del etiquetado manual, construimos un proceso automatizado utilizando modelos de visión-lenguaje (VLM).

El proceso genera miles de modelos 3D desde múltiples ángulos utilizando un enfoque de pares: una imagen con textura (para el contexto semántico) y una imagen con las partes coloreadas (para el seguimiento preciso de los límites). Ambas están marcadas con marcadores numerados idénticos, lo que proporciona al VLM un identificador accesible mediante texto para razonar en el espacio 3D y agrupar y nombrar cada parte.

A diferencia de los conjuntos de datos publicados anteriormente, en los que cada rueda de un vehículo se etiqueta simplemente como «rueda», nuestro conjunto de datos enseña a la IA la diferenciación espacial (por ejemplo, distinguir una «rueda delantera izquierda» de una «rueda trasera derecha»). Esta precisión en la correspondencia es exactamente lo que buscan los motores de videojuegos.

Lo que CubePart permite y lo que viene a continuación

CubePart permite a los creadores generar activos que se ajustan a su código de juego y que son directamente compatibles con los flujos de trabajo existentes de animación, física y scripting. CubePart también puede descomponer las mallas de artistas existentes en un nuevo esquema, lo cual resulta útil para actualizar activos heredados, no solo para generar otros nuevos.

Aún queda mucho por hacer. CubePart gestiona la descomposición de cuerpos rígidos, pero también estamos trabajando en los pesos de vértices con piel para la deformación orgánica de los personajes. La atención entre partes reduce drásticamente la superposición, pero no la elimina. El razonamiento espacial —«delantero izquierdo» frente a «trasero derecho»— todavía tiene un margen de mejora significativo.

Consideramos que la generación basada en esquemas es el paso que hace que el 3D generativo sea útil en una plataforma donde todos los activos participan en una simulación. Pronto, esta tecnología estará disponible para los creadores de Roblox directamente dentro de Roblox Studio.

1En comparación con PartVerseXL