Into the Omniverse: Wie Entwickler mit Frontier-KI-Agenten Ideen in Simulationen verwandeln
Die NVIDIA-Reihe Into the Omniverse zeigt sieben Projekte, in denen Entwickler Frontier-KI-Agenten wie GPT-6 Astra und Claude Fable 5 per natürlicher Sprache steuern. Die Agenten nutzen Omniverse-Bibliotheken für Physik, Rendering und Sensorsimulation. Entstanden sind ein Humanoiden-Simulator für Lager, eine Testumgebung für autonomes Fahren, sensorvalidierte digitale Zwillinge, ein Roboter-Demontagetest und eine Browser-App der Internationalen Raumstation. Menschen setzen Ziele und prüfen, Agenten bauen und verifizieren.
Am 8. Oktober 2026 veröffentlichte NVIDIA einen neuen Beitrag der Reihe Into the Omniverse mit dem Titel „Wie Entwickler mit Frontier-KI-Agenten Ideen in Simulationen verwandeln“. Der Ausgangspunkt ist schlicht. Wer eine Simulationsidee in eine lauffähige Anwendung verwandeln will, muss Assets zusammenstellen, Physik und Rendering verbinden und prüfen, ob sich die Szene wie vorgesehen verhält. Entwickler koppeln dafür nun Frontier-KI-Modelle mit NVIDIA-Omniverse-Bibliotheken, damit Agenten einen großen Teil dieser Montage- und Prüfarbeit übernehmen. Die Rollenverteilung bleibt im ganzen Text gleich. Entwickler steuern die Agenten mit natürlicher Sprache, prüfen die Ergebnisse und lenken Änderungen. Omniverse-Bibliotheken liefern GPU-beschleunigte Physik, Rendering und Sensorsimulation. Die KI-Agenten verbinden diese Teile und schreiben Animations- und Anwendungscode. Genannt wird unter anderem GPT-6 Astra, und in einem Projekt arbeiten Claude-Fable-5-Agenten neben Astra. NVIDIA kündigt an, weitere Beispiele aus eigenen Teams und von Entwicklern des Ökosystems nachzureichen. Das erste Projekt ist ein Humanoiden-Simulator für ein Lager. Frank DeLise, Omniverse-Produktmanager bei NVIDIA, ließ Astra ein SimReady-Lager und einen humanoiden Roboter zu einem interaktiven Simulator mit Ego- und Außenansicht zusammensetzen. Er wies Astra an, Omniverse-Bibliotheken für Physik (ovphysx), Szenenaktualisierung (ovstage), Rendering (ovrtx) und Benutzeroberfläche (ovui) zu verbinden. Außerdem nutzte er Astra mit SimReady (simready-foundation), um die physische Szene zu erstellen. Astra erzeugte danach Animation und Anwendungscode, die diese Fähigkeiten zusammenführen. Der Nutzen ist praktisch: Bevor ein Team Lageraufgaben automatisiert, erhält es eine interaktive Umgebung, in der es das Aufgabenverhalten untersuchen und den Arbeitsablauf bewerten kann.
Das zweite Projekt zielt auf Tests für autonomes Fahren. Doyub Kim, Manager im Simulationstechnik-Team von NVIDIA, bat Astra, Zero to Alpamayo zu bauen, eine wiederverwendbare Simulationsumgebung auf Basis der Market Street in San Francisco. Kim ließ zuerst den Arbeitsablauf skizzieren. Danach verband Astra schrittweise Asset-Erstellung, Verkehr, Omniverse-RTX-Sensorsimulation und das Fahren mit Alpamayo, und Kim prüfte jede Integration. Der Prototyp wurde zu einem Testfeld, um Modelle zu vergleichen und nachzuverfolgen, wie sich Änderungen an Szene oder Sensor auf das nachgelagerte Fahrverhalten auswirken. Ein separates Experiment mit Cosmos3-Nano variierte Wetter und Beleuchtung in aufgezeichneten Simulationsvideos, sodass Kim die Reaktionen des Fahrmodells auf dasselbe Szenario unter verschiedenen Bedingungen vergleichen konnte. Das dritte Projekt zeigt am deutlichsten, wie Ergebnisse überprüft werden. Ashley Reid, die bei NVIDIA an der RTX-Sensorvalidierung arbeitet, ließ Astra- und Claude-Fable-5-Agenten die ovrtx-Kameraausgabe und die rohe LiDAR-Ausgabe mit aufgezeichneten Daten vergleichen. Die Agenten erstellten zwei digitale Zwillinge von Grund auf und verbesserten zwei vorhandene. Über etwa drei Tage leitete Reid einen iterativen Ablauf: Die Agenten maßen Unterschiede, erstellten oder änderten OpenUSD-Szenen und prüften die Ergebnisse. Die Änderungen betrafen fehlende Objekte, Geometrie und Materialien, und die Abnahme hing von Kamera- und LiDAR-Metriken ab. Für Entwickler heißt das: gemessene Abweichungen sollen die Erstellung und Verbesserung der Szene steuern. NVIDIA empfiehlt, zunächst eine OpenUSD-Szene mit dem minimalen Python-Beispiel von ovrtx zu rendern und dann ein Sensormaß zu definieren, das mit den aufgezeichneten Daten verglichen wird.
Das vierte Projekt heißt Robo Olympics. Tae Kim, der bei NVIDIA Omniverse-Engineering und -Produkt leitet, führte Astra mit Sportvideos und Anweisungen in natürlicher Sprache dazu, ein experimentelles Projekt zu bauen, in dem simulierte Unitree-G1-Humanoide sportliche Bewegungen ausführen. Unter Kims Anleitung baute Astra Regler und verfeinerte sie durch Physikversuche. Die Newton Physics Engine simulierte das Verhalten, das quelloffene NVIDIA-Warp-Framework beschleunigte die Berechnungen, und ovrtx rendete Szenen und Bilder einer virtuellen Kamera. In einem Experiment übersprang der Roboter eine einzelne Hürde in 64 von 100 Simulationsversuchen. Dieses Ergebnis gab Kim Rückmeldung, um Timing und Steuerung des Roboters zu verbessern. Das fünfte Projekt betrifft die robotergestützte Demontage. Jens Jebens, Senior Product Manager für OpenUSD bei NVIDIA, ließ Astra ein Autofahrwerk in PTC Onshape modellieren und in NVIDIA Isaac Sim konfigurieren. Der Agent maß den verfügbaren Platz und entwarf einen Schraubenschlüssel, mit dem der Roboter die Schrauben des Fahrwerks erreichen kann. Jebens berichtet, in der Simulation sei ein Fahrwerksteil erfolgreich entfernt worden. Das verknüpft Konstruktions- und Werkzeugentscheidungen mit Demontageergebnissen und bietet einen Ausgangspunkt für das Training von Roboterstrategien. Im sechsten Projekt setzte Nic Johns, Engineering Director bei NVIDIA, NASA-Assets mit Astra zu einem OpenUSD-Modell der Internationalen Raumstation mit Telemetrie zusammen. Johns baute die Anwendung mit einem einzigen Prompt und verschob die Szene mit einem Folge-Prompt auf die Tagseite der Erde, damit der Planet sichtbar wurde. Der Ablauf nutzte Blender für die Asset-Vorbereitung und Omniverse-Bibliotheken für Rendering (ovrtx), Szenenlaufzeit (ovstage) und Streaming (ovstream).
Der Beitrag nennt ein siebtes Projekt, in dem erfasste Räume zu Testumgebungen werden, wobei ein digital rekonstruierter Raum bearbeitbare Objekte braucht. Der für diesen Bericht vorliegende Quelltext bricht mitten in diesem Abschnitt ab, daher werden hier keine Details zitiert. Leser sollten den Originalbeitrag von NVIDIA heranziehen. Drei Muster ziehen sich durch die Fälle. Erstens endet jedes Projekt mit etwas Messbarem oder Prüfbarem: Sensormetriken, 64 übersprungene Hürden in 100 Versuchen, ein in der Simulation entferntes Fahrwerksteil. Zweitens liefern die Agenten nicht in einem Zug, sondern arbeiten in einer Schleife aus Messen, Ändern und Neuprüfen, mit einem Menschen für die Richtung. Drittens beruhen alle Fälle auf der gemeinsamen Basis aus OpenUSD und Omniverse-Bibliotheken, was Werkzeuge und Assets leichter verbindbar macht. Nüchtern gelesen: Der Beitrag ist eine Eigenpräsentation von NVIDIA. Er nennt keine Kosten, keinen Vergleich der Gesamtzeit und keinen Anteil gescheiterter Versuche. Ein allgemeiner Effizienzgewinn lässt sich daraus nicht ableiten.
Die Folgerungen bleiben dennoch klar. Für Robotik- und Fahrteams ist Simulation ein Kernschritt für Training und Validierung, und ihr Aufbau hing lange von wenigen Ingenieuren ab, die Grafik und Physik beherrschen. Machen Agenten den Verbindungscode billig, erreichen mehr Teams früher das Testen in der Simulation. Für NVIDIA stärkt es die Bindung an das Software-Ökosystem, wenn Frontier-Modelle Omniverse-Bibliotheken als Werkzeuge aufrufen. Offene Aufgaben sind, die Lücke zwischen simulierten und echten Sensoren weiter zu schließen, nachzuvollziehen, was ein Agent geändert hat, und Szenen bei Teamarbeit rückverfolgbar zu halten. Die Antworten darauf entscheiden, ob agentengetriebene Simulation von der Demonstration in den Ingenieursalltag wechselt.