Der CEO von Unreal Engine schaut sich das neueste Weltmodell an: Codegetrieben, das Videomodell erzeugt die Bilder.

In den letzten Jahren haben Videogenerationsmodelle rasche Fortschritte in Bezug auf Klarheit, zeitliche Konsistenz und Steuerbarkeit erzielt. Ausgehend von Texten, Bildern, Kameratrajektorien oder Spieleraktionen sind die Modelle bereits in der Lage, zusammenhängende aufeinanderfolgende Bilder zu synthetisieren, wodurch die „interaktive Videowelt“ allmählich von einem Konzept zu einem ansehbaren und bedienbaren Prototyp übergeht.

Aber die Fähigkeit, Bilder fortzusetzen, bedeutet nicht, dass man eine ganze Welt betreiben kann. Verschiebungen und Kollisionen im Bild stellen nur die intuitivste Ebene der Interaktion dar; in komplexeren Umgebungen haben Charaktere zudem Ziele, Identitäten und Beziehungen, Ereignisse unterliegen Regeln und hinterlassen kausale Folgen, die sich über einen längeren Zeitraum erstrecken. Viele Zustände entstehen sogar außerhalb des Bildausschnitts, verändern aber dennoch die nachfolgende Handlung und die Aktionen. Wenn man nur auf die Vorhersage lokaler Pixel setzt, um die nächste Beobachtung zu generieren, ist es sehr schwierig, diese hochgradigen semantischen Elemente explizit aufrechtzuerhalten.

Komplexe Welten erfordern zuerst das „Verständnis, warum etwas geschieht“. Ziele, Regeln, Erinnerungen und Kausalketten lassen sich normalerweise nicht direkt aus einem einzelnen aktuellen Frame ablesen, bestimmen aber, wie sich die Welt im nächsten Schritt verändern sollte. Die Fähigkeiten von Sprachmodellen zur Wissensabfrage, Schlussfolgerung, Planung und Programmierung eignen sich für die Bearbeitung solcher Entscheidungen mit geringer Häufigkeit aber hoher Komplexität und setzen diese Entscheidungen weiter in ausführbare Regeln um.

Eine weitere oft übersehene Tatsache lautet: Spielvideos sind nicht die Welt selbst, sondern eine Pixelprojektion, die nach der Ausführung eines Programms gerendert wird. Derzeit bilden Spiele und Simulatoren die wichtigste Quelle für interaktive Daten für Videoweltmodelle. Wenn man nur Aktionen und Pixel beibehält und das Videomodell direkt die Abbildung zwischen diesen beiden Elementen erlernen lässt, umgeht man die ursprünglich vorhandenen Programme, Regeln und expliziten Weltzustände und verlangt stattdessen vom Modell, das gesamte Programmverhalten aus den visuellen Ergebnissen rückwärts anzunähern. Ein solcher Lernpfad ist nicht nur ineffizient, sondern koppelt auch „wie sich die Welt entwickelt“ und „wie die Welt dargestellt wird“ in ein und demselben Modell.

Auf der Grundlage dieser Beobachtung haben die Forschungsteams des AGI Lab der Westlake-Universität und der Nanyang Technological University das Code World Model vorgeschlagen, ein neues Paradigma für Weltmodelle, das ein Sprachmodell als „Gehirn“ verwendet. Der Kerngedanke besteht darin, dass ein Coding-Agent durch kontinuierliches Schreiben, Aufrufen und Ändern von Code ausführbare Weltzustände pflegt und aktualisiert; die mit der aktuellen Beobachtung verbundenen Zustände werden dann in einen Proxy umgewandelt, der das Videomodell anleitet, detaillierte visuelle Bilder zu generieren.

Link zum Papier: https://arxiv.org/abs/2608.25927

Projekt-Homepage: https://buaacyw.github.io/cwm/

Code-Repository: https://github.com/buaacyw/code-world-model

Das Sprachmodell hier ersetzt das Videomodell nicht. Das Code World Model teilt die Zuständigkeiten der beiden neu auf: Wissen, Ziele, Regeln und langfristige Kausalität werden vom Coding-Agent und dem Code übernommen, während Aussehen, Bewegungsdetails, Beleuchtung und Textur vom Videomodell übernommen werden. Mit anderen Worten: Ersteres bestimmt, was in der Welt geschieht, Letzteres bestimmt, wie all dies aussieht.

Abbildung 1 Kernaufteilung des Code World Model: Der Coding-Agent entwickelt den Weltzustand über Code, der Proxy wandelt die relevanten Zustände in visuelle Bedingungen um, und das Videomodell generiert die endgültigen Bilder.

Überblick über die Methode

Auf der Grundlage der oben genannten Aufteilung unterteilt das Code World Model den Betriebsprozess der Welt in drei miteinander verbundene Teile.

Coding-Agent: Er versteht die Absichten des Spielers und neue Ereignisse, ruft das Weltwissen ab, schließt auf potenzielle Folgen und entscheidet, welche Mechanismen ausgeführt, kombiniert oder geändert werden müssen.

Code: Er führt mit höherer Frequenz deterministische Aktualisierungen wie Position, Eigenschaften, Kollisionen, Abkühlung und Ereignisauslösung aus und wandelt hochgradige Entscheidungen in überprüfbare, wiederverwendbare und nachhaltig ausführbare Regeln um.

Videomodell: Es liest die entwickelten Zustandsbedingungen und generiert mit den Prioritäten für Aussehen, Bewegung und Interaktion, die aus großen Mengen visueller Daten erlernt wurden, visuelle Beobachtungen mit reichhaltigen Texturen, Beleuchtung und lokalen Dynamiken.

Diese Aufteilung entspricht auch unterschiedlichen Rechenfrequenzen. Der Coding-Agent muss nur dann spärliche Entscheidungen treffen, wenn neue Ziele, komplexe Ereignisse auftreten oder die vorhandenen Mechanismen unzureichend sind; sobald die Entscheidung in den Code geschrieben ist, kann das Programm kontinuierlich dichte Zustandsaktualisierungen ausführen.

Noch wichtiger ist, dass der Coding-Agent nicht nur numerische Werte zu einem bestimmten Zeitpunkt ändert, sondern auch die Betriebsweise verändern kann, der die Welt danach folgt.

Abbildung 2 Gesamtrahmen des Code World Model. Die vollständige Konzeption umfasst visuelle Rückkopplung; das aktuelle Prototyp validiert hauptsächlich die Vorwärtsverbindung von Coding-Agent / Code → Weltzustand → Proxy → Videomodell.

Der Proxy verbindet ausführbare Zustände mit der Videogenerierung

Nach Abschluss der Aufteilung der Zuständigkeiten verbleibt noch ein wichtiges Schnittstellenproblem: Der Coding-Agent und der Code pflegen ausführbare Zustände, während das Videomodell Text-, Bild- oder Video-Token empfängt. Zwischen den beiden Elementen wird eine gemeinsame Sprache benötigt, die sowohl leicht vom Programm erstellt werden kann als auch raumliche Einschränkungen pro Frame liefert.

Strukturierter Text ist flexibel genug, aber es ist schwierig, die Positionen von Entitäten, ihre relativen Beziehungen, Bewegungstrajektorien und genaue Kameränderungen in jedem Frame stabil zu beschreiben; obwohl der vollständige Aufbau und das Rendern einer 3D-Welt eine stärkere Steuerung bieten, würden sie erneut die hohen Kosten für Assets, Geometrie, Materialien, Animationen und Rendering-Pipelines mit sich bringen.

Aus diesem Grund führt diese Arbeit den Proxy ein. Er extrahiert die Informationen, die die aktuelle Beobachtung wirklich einhalten muss, aus dem Weltzustand und organisiert sie in eine grobkörnige visuelle Darstellung. Ein leichtgewichtiger, deterministischer Compiler rendert den Proxy zu einem Proxy-Video und leitet ihn zusammen mit strukturiertem Text an das Videomodell weiter.

Der Text ist dafür zuständig, zu erläutern „wer es ist, was es ist und was es tun wird“, während der Proxy festlegt „wo es sich befindet, wie es sich bewegt und wie die Kamera aufnimmt“.

Der Proxy kann Kamera und Perspektive, Position und Ausrichtung von Entitäten, Maßstab und Trajektorie, Szenenlayout und Verdeckung sowie die grobkörnigen Zustände ausdrücken, die für die aktuelle Interaktion erforderlich sind; Texturen, Materialien, feine Beleuchtung und vollständige lokale Bewegungen werden bewusst dem Videomodell überlassen. Der Artikel fasst dieses Designprinzip zusammen: Behalten Sie nur die minimalen ausreichenden Zustände bei, die für die aktuelle Beobachtung erforderlich sind, um ein Gleichgewicht zwischen Steuerungsfähigkeit und Kosten der Zustandscodierung zu erreichen.

Der Proxy in der aktuellen Implementierung hat sowohl in der Breite als auch in der Höhe nur ein Viertel des Zielvideos, und die Pixelmenge beträgt etwa 1/16 des Ziels. Er besteht aus einfachen, wiederverwendbaren geometrischen Primitiven, benötigt keine Assets in Produktionsqualität, kann aber ein pro Frame bearbeitbares raumzeitliches Skelett liefern.

Erhalt von streng ausgerichteten Daten aus den Laufzeitaufzeichnungen von Spielen

Damit das Videomodell verstehen lernt, den Proxy zu interpretieren, müssen die Trainingsstichproben gleichzeitig Proxy-Videos, strukturierten Text und das Ziel-RGB-Video enthalten, und Proxy und RGB müssen in Bezug auf Zeit, Kamera und Entitätsidentität streng ausgerichtet sein.

Die Laufzeitaufzeichnungen von Spielen behalten diese Entsprechung auf natürliche Weise bei. Das Forschungsteam zeichnet gleichzeitig RGB, Kamerazustand, Entitätsidentität, Position und Ausrichtung, ungefähren Maßstab, Szenenlayout und Interaktionszustand aus derselben Gameplay-Ausführung auf und kompiliert dann den Proxy offline über den Code. Da beide aus derselben Ausführung stammen, kann für jedes Frame eine Eins-zu-Eins-Entsprechung hergestellt werden, und die Identität über mehrere Frames hinweg kann ebenfalls stabil abgebildet werden.

Abbildung 3a Das Ziel-RGB (oben) in den Spieldaten und der Proxy desselben Frames (unten).

Abbildung 3b Das Ziel-RGB im echten Video (oben) und der Proxy, der offline über Kamerakalibrierung, 3D-Rekonstruktion und Objektmarkierung erstellt wurde (unten).

Die im Papier verwendeten Gameplay-Daten umfassen 157 Aufzeichnungen mit insgesamt etwa 5,6 Stunden Quellvideo. Das Forschungsteam probt in 2-Sekunden-Intervallen und erhält 9.420 5-sekündige Trainingssegmente; jedes RGB-Ziel enthält 124 Frames mit einer Auflösung von 1344×768 und einer Bildrate von 24 FPS, der entsprechende Proxy enthält ebenfalls 124 Frames mit einer Auflösung von 336×192 und kombiniert eine fest protokollierte Tiefe mit einer kategorischen semantischen ID-Karte.

Dieselbe Laufzeitaufzeichnung kann auch neu kompiliert werden, um Proxys mit unterschiedlichem Abdeckungsbereich und Informationsgranularität zu erhalten, ohne dass das RGB neu aufgezeichnet werden muss.

Das Papier zeigt zudem den Offline-Erstellungsprozess von Proxy-Beobachtungs-Paaren für echte Videos auf KITTI-360, um die Möglichkeit der Erweiterung dieser Schnittstelle auf echte Daten zu erläutern; die aktuelle Anpassung des Videomodells verwendet nur gepaarte Gameplay-Daten.

Wie funktioniert das Prototypsystem?

Das aktuelle Prototyp verwendet den Ref2VA-Backbone von MiniMax-H3 als Videomodell, führt eine Rank-128-LoRA-Anpassung für alle 50 Transformer-Blöcke durch, und die Anzahl der trainierbaren Parameter beträgt etwa 596 Millionen. Für das Training wurden 8 NVIDIA H800-GPUs verwendet, und es wurden insgesamt 3 Epochen mit 3.534 Optimierungsschritten abgeschlossen.

In der Inferenzphase fungiert GPT-5.6 Sol als Coding-Agent. Das System stellt ihm grundlegende Spielersteuerung, Kollisionsverarbeitung, Laufzeitaktualisierungsschleifen, vorhandene Game-Engine-Szenen und Gameplay-Logikvorlagen sowie die im Trainingsabschnitt verwendeten Proxy-Primitive zur Verfügung. Der Coding-Agent kann diese Codes kombinieren, erweitern und neu schreiben, um einfache, ausführbare und vom Spieler steuerbare Welten zu erstellen; die darin enthaltene grobkörnige 3D-Geometrie dient nur zum Ausdrücken des Proxys und wird nicht direkt als endgültiges Bild verwendet.

Für jedes 5-sekündige Segment generiert GPT Image 2 einen Erscheinungsanker basierend auf dem ersten Frame des Proxys und dem Text; MiniMax-H3 kombiniert dann das erste Frame, die vollständige Proxy-Sequenz und den Text, um ein RGB-Video mit 124 Frames, 1344×768 und 24 FPS zu generieren.

Längere Videos werden über ein gleitendes Fenster mit einer Überlappung von 34 Frames generiert: Das nachfolgende Fenster erbt den RGB-Kontext am Ende des vorherigen Fensters und verwendet denselben Erscheinungsanker wieder, um die lokale Kontinuität und das gesamte Erscheinungsbild der Entitäten aufrechtzuerhalten.

Experimentelle Ergebnisse

Die qualitativen Ergebnisse zeigen, dass das Modell selbst bei Verwendung von nur etwa 5,6 Stunden Gameplay-Quellvideo für die LoRA-Anpassung in