Gemini 4 Carbon escribió por sí solo un path tracer en CUDA y renderizó un minuto de animación

Lo habitual en una demo de «la IA escribió el código» es que el modelo monte una landing page, un Snake o un parser. Aquí la historia es otra. Según la descripción del autor de la demo (la cuenta fofrAI en X, recogida en el canal de Telegram «Metaversishche i AIshche»), el modelo Gemini 4 Carbon recorrió por sí solo el camino desde una carpeta vacía hasta un vídeo terminado: con geometría, luz, física, cámara y música.

Qué construyó exactamente el modelo

La lista del post es la siguiente.

Primero: un renderizador 3D propio en C++ y CUDA. Incluye path tracing, es decir, un cálculo honesto de la luz, los reflejos y las sombras mediante trazado de rayos en una GPU de NVIDIA. No es la llamada a un botón «Render» ya hecho en Blender, sino código que calcula por sí mismo cómo rebota la luz en las superficies.

Segundo: física con MuJoCo. Es un motor habitual en robótica. Calcula la gravedad, las colisiones, la fricción y la interacción de cuerpos rígidos.

Tercero: la escena. El modelo diseñó una máquina de Rube Goldberg, en la que bolas y palancas se activan unas a otras en cadena. Después creó un estudio 3D y un recorrido continuo de cámara.

Cuarto: el ritmo. El movimiento de la cámara se sincronizó con una pista de Lyria 3.5, el modelo musical de Google.

Por qué no es solo una imagen bonita

La cifra clave es 60 segundos de simulación con 120 000 pasos, es decir, 2000 pasos por segundo. No hay fotogramas clave. Los objetos se mueven porque los empujan fuerzas simuladas, no porque alguien haya dibujado una trayectoria. Para una máquina de Rube Goldberg esto es fundamental: si aunque sea un eslabón de la cadena está mal calculado, la bola no llega y toda la reacción se viene abajo. Un vídeo así no se puede imitar «a ojo»: la física funciona o no funciona.

El segundo punto es la amplitud de la tarea. Aquí confluyen programación gráfica, código para GPU, modelado físico, composición de escena, trabajo de cámara y ajuste temporal al sonido. Estas tareas se verifican mal con los benchmarks estándar: el modelo conoce bien cada parte por separado, y la dificultad está en que las partes encajen entre sí y no se rompan en centésimas de segundo.

Hay además una ironía aparte en el chiste sobre NVIDIA Omniverse en el titular del post original. Omniverse se vendía como plataforma para simulación y pipelines 3D. Aquí el modelo montó un flujo de trabajo de sentido parecido a partir de componentes abiertos y ya hechos. Y aun así funciona sobre CUDA, de modo que un escenario así resulta, más bien, favorable para el hardware de NVIDIA.

Lo que no sabemos

Aquí hace falta cautela. La fuente es un post de Telegram que recoge tuits, y se trata de un único vídeo de demostración, no de un experimento reproducible. Del material no se ve cómo era el prompt, cuántas iteraciones hubo, si intervino una persona, si corrigió errores ni cuánto costó la ejecución. Tampoco está clara la calidad de la imagen: un path tracer «desde cero» puede producir ruido y artefactos que un renderizador maduro no tendría. Por último, «lo escribió solo» no significa «lo ideó solo»: MuJoCo y CUDA son herramientas ya hechas, y el modelo las ensambló.

Por eso, la afirmación del post de que «los artistas 3D ya no hacen falta» es una broma, no una conclusión. El artista sigue decidiendo qué merece la pena mostrar, y el pipeline de un estudio tiene cosas que la demo no muestra: assets, correcciones de animación, aprobación del cliente.

Qué hacer con esto en la práctica

Para desarrolladores y product managers, la conclusión es más modesta, pero más útil. Primero, conviene dejar de medir el modelo con tareas pequeñas. Si de una sola vez monta la combinación de «código para GPU más física más visuales más sonido», los prototipos de simuladores, visualizaciones y entornos de entrenamiento pueden hacerse mucho más rápido. Segundo, los motores físicos como MuJoCo son un verificador cómodo: el resultado es verosímil o no lo es, y eso ayuda a detectar errores del modelo. Tercero, si desarrolla herramientas para 3D, juegos o robótica, conviene ejecutar en su propio stack un escenario largo similar y ver exactamente dónde falla.

Una demo no es una prueba, pero sí un buen motivo para actualizar el conjunto de tests. Si Gemini 4 Carbon realmente hace esto a demanda y no por una feliz casualidad, lo que más cambiará será la barrera de entrada a los prototipos gráficos complejos.