knowledge-base/raw/blog/2026-09-17_nvidia-ai-agents-3d-scenes-simulation.md

117 lines
11 KiB
Markdown
Raw Permalink Normal View History

---
type: blog
source_url: https://developer.nvidia.com/blog/how-to-use-ai-agents-to-prepare-3d-scenes-for-simulation/
retrieved: 2026-09-17
title: "How to Use AI Agents to Prepare 3D Scenes for Simulation"
author: "NVIDIA Developer Blog"
tags: [nvidia, omniverse, openusd, simready, blender, isaac-sim, nemoclaw, hermes, openclaw, codex, gpt-6-astra, multi-agent, physical-ai, robotics]
---
# How to Use AI Agents to Prepare 3D Scenes for Simulation
## Quelle
NVIDIA Developer Blog: [How to Use AI Agents to Prepare 3D Scenes for Simulation](https://developer.nvidia.com/blog/how-to-use-ai-agents-to-prepare-3d-scenes-for-simulation/). Abgerufen am 17.09.2026. Kein Veröffentlichungsdatum und kein Verfasser im abgerufenen Text ausgewiesen. Post ist Teil der Omniverse-/Physical-AI-Reihe; im Text wird auf einen [OpenUSD-Insider-Livestream am 30.09.2026, 11:00 PT](https://www.addevent.com/event/xyfkbgkts9nx) verwiesen („Developing a Physical AI Simulation Live with GPT-6 Astra and NVIDIA Omniverse Libraries"), der noch aussteht.
## Inhalt
Der Beitrag beschreibt einen Referenz-Workflow, in dem agentische KI eine Blender-Szene in eine simulationsreife („SimReady") OpenUSD-Welt für NVIDIA Isaac Sim oder Isaac Lab überführt.
Ausgangspunkt des Beitrags ist die Beobachtung, dass Robotik-Agenten-Workflows häufig nicht an Policy, Modell oder Trainingsloop scheitern, sondern früher: an einer fehlenden simulationsreifen Welt. Die Vorarbeit dafür — Objekte labeln, Kollisionsmeshes prüfen, Materialien simulationsfähig machen, Sensoren platzieren, sauberer USD-Export, Validierung — sei mühsam, repetitiv und fehleranfällig und liege oft außerhalb des Zuständigkeitsbereichs des Robotics-Simulation-Engineers.
### Rollenverteilung im Workflow
Der Beitrag beschreibt ein Drei-Schichten-Muster:
- **Codex** (angetrieben von OpenAI GPT-6 Astra bzw. alternativ Claude beziehungsweise „Claude Cowork" von Anthropic) ist der orchestrierende Hauptagent: übersetzt das Entwicklerziel in Aufgaben, identifiziert Abhängigkeiten, prüft Ergebnisse und entscheidet, wann die Arbeit abgeschlossen ist.
- **Spezialisierte Subagents** werden mit dem **Hermes-Agent-Harness** gebaut und über **NVIDIA NemoClaw** deployt. Der Beitrag nennt als mögliche Open-Source-Agent-Harnesses ausdrücklich **Hermes, OpenClaw und LangChain**, konfiguriert mit verschiedenen NVIDIA-Nemotron-Modellen für Vision, Reasoning und Tool-Use. Jeder Subagent besitzt einen spezifischen Job samt Akzeptanzkriterien.
- **NVIDIA Omniverse Libraries** sind die Werkzeuge, die die Subagents aufrufen: **OpenUSD**-Operationen etablieren die gemeinsame Szenenstruktur, **ovphysx** authored und prüft Physik-Eigenschaften, **ovrtx** rendert visuelle Preflight-Ansichten, die **SimReady-Validierung** prüft Assets gegen ein Zielprofil.
Im Beitrag formulierte Kurzfassung: „Codex or Claude coordinates, NemoClaw agents reason, Omniverse Libraries act."
Sichere, mechanische Probleme werden laut Beitrag automatisch behoben; Entscheidungen, die von Entwickler-Absicht abhängen (unsichere semantische Labels, physikalisches Verhalten), werden mit Kontext und Vorschlag an einen Menschen eskaliert.
### Ziel-Spezifikation
Der Beitrag empfiehlt, dem Orchestrierungsagenten ein strukturiertes Ziel vorzugeben:
- Input: Blender-Szene
- Goal: Vorbereitung für Robotik-Simulation
- Output: USD-basierte simulationsreife Welt
- Destination: Isaac Sim oder Isaac Lab
- Validation: visueller Preflight + SimReady-Validierung
### Die acht Schritte
**Schritt 1 — Szenen-Inventar über Blender MCP.** Der erste Subagent verbindet sich über einen Model-Context-Protocol-(MCP-)Server mit Blender ([Blender MCP Server](https://www.blender.org/lab/mcp-server/)) und inventarisiert die Szene: Objekte, Collections und Hierarchie, Materialien, Kameras und Lichter sowie fehlende Simulationsdaten. Beispiel-Ausgabe im Beitrag:
```json
{
"objects": 142,
"materials": 37,
"missing": [
"semantic_labels",
"collision_meshes",
"camera_sensors",
"physics_materials"
]
}
```
Dieses Inventar wird zum gemeinsamen Kontext der weiteren Subagents. Für die Demo verwendet der Beitrag die Blender-Szene [„The Junk Shop"](https://download.blender.org/archive/gallery/blender-splash-screens/blender-2-81/) von Alex Trevino (Originalkonzept von Anais Maamar).
**Schritt 2 — USD als Vertrag.** Blender bleibt die Autoring-Umgebung, USD ist die Übergabe an die Simulation. Der USD-Authoring-Agent bewahrt über Omniverse Libraries Hierarchie, Transforms, Materialien, Labels, Physik-Metadaten und Sensor-Definitionen. Merksatz des Beitrags: „if another agent or simulator needs to rely on it later, author it into USD." USD komponiere geschichtet und nicht-destruktiv, sodass Labels, Physik-Metadaten, Sensor-Definitionen und Validierungsdaten ergänzt werden können, ohne die ursprüngliche kreative Arbeit zu flatten.
**Schritt 3 — Semantische Labels.** Ein Labeling-Agent wandelt anonyme Meshes in aufgabenbewusste Objekte. Genannte Klassen: `shelf`, `bin`, `box`, `floor`, `obstacle`, `grabbable_object`, `robot_target`, `no_go_zone`. Labels können aus Objektnamen, Hierarchie, Form und Kontext abgeleitet werden, Unsicherheit soll aber markiert werden — Beispielausgabe im Beitrag: „Tagged 118 prims. 9 labels need review." Labels werden als Brücke zwischen Szeneninhalt und Robotik-Workflows (Perzeption, Task-Setup, synthetische Daten, Validierung) beschrieben.
**Schritt 4 — Simulationsbewusste Materialien.** Ein Material-Agent prüft visuelle Materialien und authored simulationsrelevante Metadaten (etwa Metallregale, Kartonboxen, Kunststoffbehälter, Betonböden, Gummirad, Glasplatten). Ziel sei nicht schönere Optik, sondern nutzbarere Information für Simulation und Validierung.
**Schritt 5 — Sensoren früh anlegen.** Ein Sensor-Subagent authored Kamera- und Lidar-Sensoren mit Position, Orientierung, Field of View, Polling-Rate, Range, Auflösung und Target-Frame. Damit lassen sich Fragen vor dem Training klären: Kann der Roboter das Ziel sehen? Ist der Sensor verdeckt? Ist das Sichtfeld brauchbar? Sind die Trainingsobjekte aus den erwarteten Blickwinkeln sichtbar? Im gezeigten Beispiel lädt ovrtx eine Szene mit konfiguriertem Lidar, wärmt die Sensor-Pipeline auf, rendert einen Punktwolken-Frame, liest gültige Punktdaten über den Count-Channel und visualisiert die Punkte mit intensitätsbasierten Farben.
**Schritt 6 — ovphysx für physische Reife.** Der ovphysx-Subagent ergänzt beziehungsweise validiert Kollisionsmeshes, statische Collider, Rigid Bodies, Masse-Eigenschaften, Reibung, Restitution, Physik-Materialien sowie beweglich versus fixiert. Als typische Befunde nennt der Beitrag:
```
46 objects missing collision meshes.
12 grabbable objects marked static.
7 collision meshes too complex.
3 props floating above the floor.
```
Der Agent überführt solche Befunde in einen Reparaturplan, wendet sichere Fixes automatisch an (etwa einfache Kollisionsmeshes für statische Props, Böden und Regale als fixe Collider, Rigid-Body-Eigenschaften für greifbare Objekte) und leitet mehrdeutige Fälle an einen Menschen weiter. Ergebnis ist nicht nur eine sauberere Szene, sondern ein Physics-Readiness-Report.
**Schritt 7 — ovrtx als Preflight-Loop.** Der ovrtx-Agent rendert Review- und Roboter-Kamera-Ansichten und prüft, ob Zielobjekte sichtbar sind, Labels an sichtbaren Objekten hängen, Materialien korrekt rendern, die Beleuchtung physikalisch plausibel ist, die Kamera blockiert oder geclippt ist und die Objektskala plausibel wirkt. Fehlt ein gelabeltes Ziel in einer Roboter-Kamera-Ansicht, kann Codex die Sensor- und Szene-Inventar-Subagents beauftragen, Kamera-Orientierung, Clipping-Einstellungen und mögliche Verdeckungen zu prüfen; nach einer Korrektur rendert der Rendering-Subagent erneut. Damit wird visuelles Review zu einem handlungsfähigen Reparatur-Loop.
**Schritt 8 — SimReady-Validierung.** Der Validierungsagent führt die SimReady-Validierung gegen das Zielprofil aus. [SimReady Foundation](https://github.com/NVIDIA/simready-foundation/blob/main/nv_core/sr_specs/docs/guides/getting_started.md) definiert Standards und Validierungsprofile für simulationsreifen USD-Content. Beispielhafter Report im Beitrag:
```
Validation failed: 14 issues
- 10 auto-fixable
- 4 require review
```
Fix-Agents reparieren sichere Probleme; mehrdeutige Fehler gehen an einen Menschen — im Beispiel zwei unsichere semantische Labels, ein greifbares Objekt mit widersprüchlichen Physik-Einstellungen und ein Objekt, das entweder Hindernis oder Ziel sein könnte. Nach menschlicher Freigabe wenden die Agenten die Korrektur an und führen die Validierung erneut aus.
### Zusammenfassung des Musters (Beitragsformulierung)
Blender MCP inspects the scene. Omniverse Libraries author the world. USD carries the contract. Semantic labels add meaning. Sensors define perception. ovphysx makes it physical. ovrtx makes it visually testable. SimReady validation makes it acceptable. Isaac Sim / Isaac Lab makes it trainable.
### Empfohlene Systeme
Der Beitrag empfiehlt vier NVIDIA-Systemklassen für den Workflow:
- [NVIDIA DGX Spark](https://www.nvidia.com/en-us/products/workstations/dgx-spark/): 128 GB kohärenter Unified Memory, für lokales Prototyping von NemoClaw-Subagents, Blender-MCP-Anbindung, USD-Authoring, SimReady-Validierung und ovrtx-/ovphysx-Loops vom Desktop aus.
- [NVIDIA DGX Station](https://www.nvidia.com/en-us/products/workstations/dgx-station/): GB300 Grace Blackwell Ultra Desktop Superchip mit bis zu 748 GB kohärentem Speicher, optional zusätzliche RTX PRO 6000 Blackwell Workstation GPU — für größere Szenen, mehr parallele Subagents, anspruchsvollere Simulations- und Visualisierungslast.
- [NVIDIA RTX PRO Server](https://www.nvidia.com/en-us/data-center/products/rtx-pro-server/): für Team-Pipelines, Batch-Szenenvorbereitung, große OpenUSD-Assets, synthetische Datengenerierung, produktionsnahe Validierungsläufe.
- [NVIDIA DGX Cloud](https://www.nvidia.com/en-us/data-center/dgx-cloud/): elastische Compute für große Trainingsjobs, Batch-Simulation und skalierte Physical-AI-Pipelines.
Als Einstieg empfiehlt der Beitrag: einen Scene-Prep-Bottleneck auswählen, einem Subagenten geben, an ein Omniverse-Tool anbinden und ein Validierungs-Gate ergänzen.
### Weitere Ressourcen im Beitrag
- [Omniverse Labs](https://nvidia-omniverse.github.io/omniverse-labs/) — Omniverse-Samples
- [NVIDIA Omniverse Libraries](https://developer.nvidia.com/omniverse) — agenten-aufrufbare Tools für USD, Rendering, Physik, Storage und Validierung
- [SimReady Foundation](https://github.com/NVIDIA/simready-foundation) — Validierungsprofile und Anforderungen an simulationsreifen USD-Content
- [Isaac Lab](https://developer.nvidia.com/isaac/lab) / [Isaac Sim](https://developer.nvidia.com/isaac/sim) — Robot Learning
- [NemoClaw](https://www.nvidia.com/en-us/ai/nemoclaw/) — Bau spezialisierter Agenten
- [OpenUSD](https://developer.nvidia.com/openusd) — Grundlage agentischer 3D-Workflows