Skywork acelera el renderizado neuronal de Matrix-Game 4.0 hasta 67 FPS en una RTX 5080

Tienes un prototipo de juego: el personaje corre, el coche gira y las colisiones funcionan. Pero los gráficos todavía se componen de modelos sencillos. Matrix-Game 4.0 propone pasarlos por una red neuronal de vídeo que añade detalles mientras el motor del juego sigue simulando lo que ocurre. Para los desarrolladores, es una oportunidad de comprobar hasta qué punto los gráficos generativos sirven para un prototipo interactivo.

Skywork ha publicado el código, los pesos y los recursos del juego. Según el equipo, el renderizador neuronal alcanza 67 FPS en una RTX 5080 a una resolución de 864×480. Hay una salvedad importante: es la velocidad del modelo en régimen estable, con prompts fijos y SageAttention, sin contabilizar la entrada y la salida de vídeo. El lanzamiento también es anterior a la publicación de hoy: en el repositorio figura con fecha del 15 de octubre, y las optimizaciones para la 5080, del 16 de octubre. Fuente: repositorio del proyecto.

Quién se encarga del muro y quién de su textura

Imagina una carrera por una ciudad. El motor registra la posición del coche, calcula los giros y determina cuándo choca contra una barrera. Después renderiza una escena simplificada. El modelo de vídeo recibe esos fotogramas y los transforma en una imagen más detallada.

Este reparto de responsabilidades permite mantener las reglas del juego en código ejecutable. En la página del proyecto, los autores también describen un agente que convierte las peticiones del jugador en nuevas reglas y descripciones textuales de la escena. El generador utiliza los gráficos sencillos, la descripción y los fotogramas de referencia para producir imágenes en bloques de cuatro fotogramas. Fuente: descripción de la arquitectura.

Una pregunta sencilla ayuda a entender el enfoque: ¿quién decide si se puede atravesar un muro con el coche? Aquí lo decide el motor. Sin embargo, eso no implica que el muro dibujado coincida siempre con precisión con el obstáculo. La lógica puede seguir siendo correcta aunque haya un error visual. Ese es precisamente el tipo de discrepancia que conviene buscar en la primera prueba del prototipo.

Qué hay detrás de los 67 FPS

En el informe técnico, el equipo distingue entre la tasa de procesamiento y la latencia de los controles. Para la RTX 5090, indica 60 FPS durante el juego a 480p y 112 ms desde que se pulsa una tecla hasta que aparece la respuesta en pantalla. Por separado, señala una velocidad de generación de un solo paso de 83 FPS. Son mediciones distintas; no se puede extrapolar a la 5080 la latencia medida en la 5090. Fuente: informe técnico.

La diferencia práctica es fácil de imaginar. Un coche puede moverse con fluidez en pantalla, pero girar con una pausa perceptible después de recibir la orden. Por tanto, la tasa de fotogramas por sí sola no permite saber si resulta cómodo jugar. Para cada caso de uso habrá que medir por separado la respuesta a los controles y comprobarla durante maniobras bruscas.

También hay un compromiso entre calidad y velocidad. La ficha del modelo describe un modo rápido con un paso de generación y el códec TAEHV, así como un modo de calidad con dos pasos y Wan VAE. Los modelos están especializados en las escenas y cámaras suministradas. La geometría desconocida, las oclusiones entre objetos, los movimientos rápidos de cámara y las sesiones largas pueden provocar distorsiones visuales. El código y los datos de entrenamiento no se han publicado. Fuente: ficha del modelo.

Por dónde deberían empezar los desarrolladores

Mi conclusión práctica: conviene empezar con una escena ya preparada y una prueba breve y verificable. Por ejemplo, completar una vuelta en coche, dar media vuelta bruscamente y regresar al mismo cruce. Comparar la geometría visible con la escena simplificada del motor, registrar la latencia de los controles y comprobar si los objetos conservan su aspecto.

El siguiente experimento consiste en modificar un objeto o un tramo del recorrido. Así se verá hasta qué punto el modelo admite cambios más allá de la escena que conoce. Para un equipo de producto, esto resulta más útil que un vídeo vistoso: permite entender cuánta libertad se puede dar al usuario y qué errores habrá que ocultar o corregir.

El valor potencial está en una conexión verificable entre el código del juego y las imágenes generativas. Pero el ahorro en la creación de gráficos sigue siendo una hipótesis que debe comprobarse en cada proyecto: hay que contrastarlo con los costes de ejecución, adaptación de las escenas y control de los errores visuales.