Omniverse Tutorial

Was ist Omniverse?

Omniverse ist eine Plattform von NVIDIA, mit der man virtuelle 3D-Welten erstellen, verbinden und simulieren kann – und das in Echtzeit. Omniverse ist eine offene Plattform für Entwickler, Designer, Ingenieure, Forscher und Kreative, um:

• 3D-Anwendungen miteinander zu verbinden (z. B. Blender, Maya, Unreal Engine)
• Gemeinsam in einer einzigen Szene zu arbeiten – live und gleichzeitig.
• Physikalisch realistische Simulationen und KI-gesteuerte Anwendungen zu erstellen.

Wofür wird Omniverse verwendet?

• Design, Visualisierung & Simulation von Fahrzeugen in Echtzeit.
• Digitale Zwillinge von Fabriken zur Optimierung von Abläufen.
• Asset-Erstellung und visuelle Simulationen.
• Training mit synthetischen Daten, z. B. für autonome Fahrzeuge.
• Echtzeit-Collaboration beim Animieren und Rendern.

Was ist USD?

Omniverse basiert auf dem OpenUSD-Format (Universal Scene Description) von Pixar – ein Dateiformat, das komplexe 3D-Szenen beschreiben kann.

Was ist das Omniverse Kit SDK?

Das Omniverse Kit SDK ist das Entwicklungs-Framework von NVIDIA Omniverse, mit dem sich eigene 3D-Anwendungen erstellen lassen. Kernstück ist der Kit Kernel, der Lifecycles verwaltet und als Runtime für Erweiterungen dient. Wichtigstes Konzept sind Extensions (Erweiterungen): Alles in Kit ist als Erweiterung modular aufgebaut – vom Rendering über Asset-Management bis zur UI​. Das Kit SDK liefert eine Sammlung an Basiserweiterungen (z.B. Rendering, Viewport, omni.ui für die Benutzeroberfläche) und Tools, die Entwickler nutzen können​.

NVIDIA beschreibt das Kit SDK folgendermaßen:
„At its core, the Omniverse Kit SDK is a framework for efficiently managing extensions and plugins. It provides the tooling necessary for developers to assemble a blend of NVIDIA-provided and custom-developed extensions to create rich, full-featured applications.“​

Einfach gesagt stellt das Kit SDK die Bausteine und das Grundgerüst bereit, um mithilfe von Erweiterungen komplette Omniverse-Anwendungen zu bauen. Viele offizielle Omniverse-Apps (wie USD Composer für 3D-Szenenerstellung oder Omniverse Code zur Erweiterungsentwicklung) basieren selbst auf dem Kit SDK und nutzen es, um ihre Funktionalität zusammenzustellen.

Architektur von Omniverse Kit:
Unten das Kit SDK (Kit Kernel und Bibliotheken), darüber eine kundenspezifische Kit-Anwendung mit ihrer .kit-Konfigurationsdatei und Erweiterungen. Links der Extension Registry (Erweiterungs-Katalog) mit NVIDIA-Kern-Erweiterungen und Beispiel-Erweiterungen.

Was ist das Omniverse Kit App Template?

NVIDIA Omniverse Kit SDK und das Kit App Template sind zwei eng verbundene Bausteine für die Entwicklung eigener Omniverse-Anwendungen. Das Kit SDK bildet das fundamentale Software Development Kit – also das Rahmenwerk, auf dem Omniverse-Apps basieren. Das Kit App Template hingegen ist ein von NVIDIA bereitgestelltes Projektvorlagen-Repository (auf GitHub), das Entwicklern den Einstieg in die App-Entwicklung mit dem Kit SDK erleichtert.

Das Omniverse Kit App Template ist eine Projektvorlage und Tool-Sammlung, die auf dem Kit SDK aufsetzt. NVIDIA stellt damit vorkonfigurierte Templates und Boilerplate-Code bereit, um schnell eigene Omniverse-Apps oder -Erweiterungen zu starten. Man kann sich das Kit App Template als Starthilfe vorstellen: Es liefert Beispielanwendungen, Ordnerstrukturen, Skripte und einen Baukasten, der gängige Aufgaben automatisiert (z.B. das Laden des Kit SDK oder das Erstellen einer Grund-UI).

Beim Verwenden des Kit App Template klont man zunächst das Repository und führt dann einen mitgelieferten Assistenten aus. Dieser „Wizard“ generiert aus Vorlagen eine neue Anwendung oder Erweiterung nach Wahl​.
So können Entwickler z.B. mit ein paar Befehlen eine minimale Viewer-App oder eine komplexere Editor-App erstellen, ohne alles von Grund auf neu schreiben zu müssen. Das Kit App Template abstrahiert viel von der Komplexität und bietet verschiedene Startpunkte, u.a.:

• Kit Base Editor: Minimalistische Editor-Anwendung mit grundlegender USD-Szene Ansicht​.
• USD Composer: Umfangreiche Template-App zum Authoring komplexer OpenUSD-Szenen (ähnlich der offiziellen USD Composer-App)​.
• USD Viewer: Vereinfachte Viewer-App (nur Viewport), ideal zum Streamen in einen Webbrowser​.
• Kit Service: Kopflose (ohne GUI) Service-Anwendung, z.B. für Cloud-Backends.

Für Anfänger ist das Kit App Template in der Regel der bessere Weg. Es reduziert den Anfangsaufwand und zeigt best practices. Das Kit SDK direkt zu nutzen bleibt eher Fortgeschrittenen vorbehalten oder denen, die sehr spezifische Kontrollbedürfnisse haben.

Wie starte ich eine Omniverse Anwendung via SDK?

Um das Beispiel aus dem Video lokal laufen zu lassen, müssen wir erst einmal Omniverse Kit SDK downloaden:

https://developer.nvidia.com/omniverse

Die einzelnen Projekte wie z.B. „Factory Planning 3D Sample Asset“ können wir hier beziehen:

https://developer.nvidia.com/usd#section-samples-and-examples

Als Nächstes können wir Omniverse lokal ausführen und die USD-Datei der Fabrik laden:

C:\tools\omniverse\kit-sdk-public_107.0-rc.4\omni.app.editor.base.bat

Eigene Anwendung / Erweiterung via Omniverse Kit App Template erstellen

Die notwendigen Schritte sind auf der folgenden Seite zu finden:

https://github.com/NVIDIA-Omniverse/kit-app-template

Zusammenfassung der Vorgehensweise unter Windows, um ein neues Projekt zu erstellen:

git clone https://github.com/NVIDIA-Omniverse/kit-app-template.git
cd kit-app-template
.\repo.bat template new

Bei der Erstellung eines neuen Projekts mit dem Omniverse Kit-Template kannst du zwischen zwei Optionen wählen:
Application: für eine eigenständige, vollständig konfigurierbare Omniverse-Anwendung – oder
Extension: für eine modulare Erweiterung, die bestehende Anwendungen gezielt um neue Funktionen ergänzt.

Eine Application ist eine vollständige Applikation, die auf dem Omniverse Kit basiert. Sie ist wie ein eigenes Programm, das alle gewünschten Extensions und Konfigurationen zusammenbringt.

Application

Eigenschaften einer Application:

• Definiert die Hauptstruktur einer App.
• Legt fest, welche Extensions geladen werden.
• Enthält Startskripte, Logos, Fenstergröße, Layouts usw.
• Kann als Standalone-Anwendung ausgeführt werden.
• Wird oft über eine .kit oder .json Datei konfiguriert.

Einsatzgebiet von Applications:

• Eine eigene Visualisierungsumgebung für deine Industrie-Assets.
• Ein spezielles Review-Tool für Ingenieure oder Architekten.
• Eine eigene App für KI-gestützte Simulationen oder Trainings.

Extension

Eine Extension ist ein modularer Baustein, den du zu einer bestehenden Omniverse-Anwendung hinzufügen kannst. Sie erweitert die Funktionalität, ohne die Hauptanwendung selbst zu verändern.

Eigenschaften einer Extension:

• Wird in Python/USD/C++ geschrieben.
• Kann UI-Elemente, Tools, Panels, Menüs, Logik usw. bereitstellen.
• Ist leichtgewichtig und einfach zu entwickeln.
• Kann unabhängig aktiviert/deaktiviert werden.
• Wird z. B. in kit/exts oder extensions gespeichert.

Einsatzgebiet von Extensions:

• Ein UI-Fenster zum Hochladen von Assets in die Cloud.
• Ein Button zum Auslösen einer Simulation.
• Eine Integration mit einem externen Dienst wie Git, Datenbank oder MQTT.

Template

Nachdem du z.B. Application ausgewählt hast, wirst du nun gefragt, welches Template du für deine neue Anwendung verwenden möchtest:

Du wählst jetzt eines von mehreren vordefinierten Anwendungstemplates, die als Grundlage für deine App dienen. Jedes dieser Templates bringt bestimmte Extensions und Funktionen mit, die für bestimmte Anwendungsfälle gedacht sind.

*.kit & *streaming.kit

Eine .kit-Datei (aaron_usd_composer.kit) ist eine Konfigurationsdatei im JSON-Format, die definiert, wie deine Omniverse-Anwendung gestartet wird. Sie ist der Einstiegspunkt für deine Anwendung – vergleichbar mit einer main()-Funktion in Programmiersprachen oder einer package.json in Node.js.

Die *.kit Datei enthält:

In Omniverse Kit ermöglichen sogenannte Streaming-Layer die Erweiterung einer Anwendung um Funktionen für Remote-Zugriff und Live-Visualisierung.
Die Datei (aaron_usd_composer_streaming.kit) ist eine spezielle Konfigurationsvariante, die auf der Hauptanwendung basiert und zusätzliche Module für Pixel-Streaming und WebSocket-Kommunikation aktiviert.

Sie erlaubt es, die Anwendung z. B. über das Netzwerk oder sogar im Browser bereitzustellen – ideal für Cloud-Umgebungen, Remote-Zusammenarbeit oder interaktive Demos.

Durch die Trennung von Hauptanwendung und Streaming-Konfiguration bleibt die Architektur modular und flexibel – je nach Bedarf kann die Anwendung lokal oder gestreamt gestartet werden.

Lokal sind die Dateien innerhalb von z.B. „C:\tools\omniverse\kit-app-template\source\apps“ zu finden.

Setup Extension

Die (aaron_usd_composer_setup_extension) ist eine automatisch generierte Setup-Extension, die dafür sorgt, dass die App richtig konfiguriert, initialisiert und ggf. erweitert wird. Hier kann das Standardverhalten der Anwendung festgelegt werden oder benutzerdefinierte Einstellungen, Workflows oder Startup-Aktionen eingefügt werden.

Die Setup Extension enhält:

Lokal ist der Ordner hier zu finden:
C:\tools\omniverse\kit-app-template\source\extensions\aaron_usd_composer_setup_extension

Application Layer

Application Layers in Omniverse sind nicht zu verwechseln mit Szenen-Layern (wie in USD oder Photoshop), sondern sie dienen dazu, Konfigurationen modular und sauber voneinander zu trennen – vergleichbar mit Umgebungsprofilen in klassischen Software-Projekten.

Wenn du z. B. eine Omniverse-Anwendung erstellst, hast du eine sogenannte Hauptanwendung, die in einer .kit-Datei gespeichert ist. In deinem Fall heißt diese Datei aaron_usd_composer.kit. Sie enthält alles, was deine Anwendung zum Laufen braucht: die Benutzeroberfläche, Extensions, das Verhalten beim Start usw.

Jetzt möchtest du aber, dass deine App gestreamt werden kann – also z. B. im Browser angezeigt werden kann oder über WebSocket-Verbindungen steuerbar ist. Dafür brauchst du zusätzliche Extensions und Einstellungen, wie etwa eine WebSocket-Schnittstelle, Streaming-Module oder Netzwerkdienste.

Diese Streaming-Funktionen werden aber nicht direkt in deine Haupt-App-Datei geschrieben – warum? Weil das gegen das Prinzip der Trennung von Konfiguration und Funktionalität verstoßen würde. Wenn du alles in eine .kit-Datei schreiben würdest, hättest du bald ein unübersichtliches Konstrukt aus vielen Funktionen, die du vielleicht nicht in jeder Situation brauchst.

Und genau hier kommen die Application Layers ins Spiel.

Ein Application Layer wie z. B. omni_default_streaming.kit ist eine von NVIDIA vordefinierte Konfigurationsdatei, die ausschließlich dafür da ist, Streaming-Funktionalität bereitzustellen. Er enthält keine App-Logik, kein UI – nur die relevanten Extensions und Konfigurationen, die für Streaming benötigt werden.

Wenn du also beim Erstellen deiner App in repo.bat gefragt wirst, ob du „Application Layers“ hinzufügen möchtest – und du z. B. „omni_default_streaming“ auswählst – dann bedeutet das:

„„Ja, ich möchte meine Haupt-App durch diesen zusätzlichen Layer um die Fähigkeit erweitern, gestreamt werden zu können.“

Die Folge davon ist, dass eine neue .kit-Datei generiert wird, z. B. aaron_usd_composer_streaming.kit. Diese Datei ist nichts anderes als eine Kombination aus:

• deiner Haupt-App (aaron_usd_composer.kit)
• dem ausgewählten Application Layer (omni_default_streaming.kit)

Sie ist also ein „Wrapper“, der über die Angabe von extends beide .kit-Dateien verbindet. Das bedeutet: Wenn du aaron_usd_composer_streaming.kit startest, wird zuerst deine App geladen und dann der Streaming-Layer „darübergelegt“. So bekommt deine App alle Streaming-Fähigkeiten – aber ohne, dass du sie in der Hauptkonfiguration eingebaut hast.

Diese Trennung hat große Vorteile: Du kannst deine Anwendung in unterschiedlichen Kontexten starten, z. B. mit oder ohne Streaming, oder mit einem Debug-Layer, oder mit einem Cloud-Layer – alles, ohne an der eigentlichen App-Datei etwas ändern zu müssen.

Das ist besonders wertvoll, wenn du eine App z. B. in verschiedenen Umgebungen einsetzen möchtest: lokal beim Entwickeln, in der Cloud beim Präsentieren oder im Firmennetzwerk für dein Team. Du musst dann lediglich unterschiedliche .kit-Dateien starten, die sich jeweils aus deiner App + passenden Layern zusammensetzen.

Build Prozess

Bevor wir die Omniverse-Anwendung mit repo.bat launch starten können, müssen wir sie erst einmal bauen, also kompilieren bzw. vorbereiten lassen.

C:\tools\omniverse\kit-app-template>repo.bat build

Anschließend kann die neue Anwendung wie folgt gestartet werden:

C:\tools\omniverse\kit-app-template>repo.bat launch

Wenn mit dem kit-app-template eine Anwendung erstellt wird, befindet sich die komplette Anwendung innerhalb dieses Ordners. Der gesamte kit-app-template-Ordner stellt somit die Struktur und den Rahmen der Anwendung dar. Er enthält unter anderem die Startlogik (apps/my_app.py), Konfigurationsdateien (config/*.kit), eigene Erweiterungen (extensions/) sowie Ressourcen wie Bilder, Fonts oder Shader.

Im Regelfall sollte für jedes neue Projekt eine eigene Kopie des kit-app-template verwendet werden. Das bedeutet: Für jede individuelle Anwendung oder jedes Tool (z. B. USD-Viewer, Simulations-GUI, Material-Editor) wird der Template-Ordner geklont und an die jeweiligen Anforderungen angepasst. Dadurch bleibt jedes Projekt isoliert und unabhängig konfigurierbar. Außerdem lassen sich so verschiedene Startoptionen, Extensions und UI-Anpassungen gezielt steuern und versionieren.

Was ist Nucleus?

Omniverse Nucleus ist der zentrale Datenserver innerhalb des Omniverse-Ökosystems. Er dient als gemeinsame Plattform für den Austausch und die Verwaltung von 3D-Assets – insbesondere USD-Dateien, Texturen, Materialien und Referenzen. Anwendungen wie USD Composer, Isaac Sim oder auch selbst entwickelte Kit-Apps greifen über Nucleus auf dieselben Daten zu, um kollaborativ und konsistent arbeiten zu können.

Die Arbeitsweise ähnelt konzeptionell einem Cloud-Speicherdienst wie Dropbox, ist jedoch speziell auf professionelle 3D-Workflows und das USD-Format zugeschnitten. Anstatt Kopien lokal zu bearbeiten, arbeiten alle angebundenen Tools direkt auf der Serverstruktur – entweder lokal oder im Netzwerk. Der Zugriff erfolgt über das Omniverse-URI-Schema, z. B. omniverse://localhost/Users/username/scene.usd.

Ein wesentlicher Vorteil von Nucleus ist die Live-Kollaboration: Mehrere Anwendungen – auch unterschiedliche – können gleichzeitig dieselbe Szene geöffnet haben und Änderungen nahezu in Echtzeit synchronisieren. Zusätzlich unterstützt Nucleus Versionierung, Berechtigungen, Referenzauflösung und eine strukturierte Dateiverwaltung – essenziell für komplexe Produktionen mit vielen Beteiligten.

Wichtig: Nucleus ist nicht für die Speicherung oder Versionierung von Anwendungscode (z. B. Kit-Apps oder Python-Skripte) gedacht. Solche Entwicklungsprojekte werden lokal gehalten und typischerweise mit Tools wie Git oder Subversion versioniert. Die Anwendungen können jedoch über omniverse://-Pfade auf Dateien im Nucleus zugreifen – beispielsweise um USD-Szenen zu öffnen, zu bearbeiten oder zu speichern.

Die lokale Installation von Nucleus (z. B. über den Omniverse Launcher) ermöglicht Einzelpersonen oder kleinen Teams den Betrieb eines eigenen Servers. In Enterprise-Umgebungen kann Nucleus auch zentral im Netzwerk oder als skalierbare Cloud-Infrastruktur betrieben werden. Durch das Live-Update-Verhalten, die strukturierte Ablage und die native Unterstützung von USD ist Nucleus die Schlüsselkomponente für vernetzte, dynamische 3D-Arbeitsprozesse.

Omniverse kann entweder lokal als Nucleus Workstation oder in der Cloud über Omniverse Enterprise (kostenpflichtig) installiert werden. Bei der lokalen Workstation müssen sich alle Nutzer im gleichen Netzwerk oder VPN befinden, da direkter Dateizugriff erforderlich ist. Die Cloud-Variante bietet mehr Flexibilität für verteilte Teams, erfordert jedoch eine zentralisierte, oft containerisierte Infrastruktur.

Hinweis: Nucleus kann noch bis Oktober 2025 über den Omniverse Launcher installiert werden:
https://install.launcher.omniverse.nvidia.com/installers/omniverse-launcher-win.exe

Laufende USD-Szenen mit Python manipulieren

Als nächstes wird eine existierende USD-Szene per Python-Code verändert – so, als würde ein externer Entwickler oder ein automatisiertes System auf eine gemeinsam genutzte Szene zugreifen. Ziel ist es, bestimmte Elemente innerhalb der Szene – etwa einen Würfel – programmatisch zu manipulieren, beispielsweise dessen Skalierung zu ändern. Dieses Vorgehen ist typisch in kollaborativen Projekten, in denen mehrere Beteiligte gleichzeitig an verschiedenen Aspekten einer digitalen Szene arbeiten, oder in automatisierten Pipelines, in denen Szenen regelmäßig durch Skripte angepasst werden.

Um Szenen programmatisch zu bearbeiten, kommt das pxr-Modul zum Einsatz. Dabei handelt es sich um die Python-Bindings der USD (Universal Scene Description)-Bibliothek von Pixar. Das Modul stellt zentrale Funktionalitäten bereit, wie das Laden und Speichern von USD-Dateien, das Erzeugen oder Verändern von Prims (Szenenelementen) und das Setzen von Transformationen wie Position, Rotation oder Skalierung. Ohne pxr ist ein Zugriff auf den Inhalt einer USD-Datei in Python nicht möglich.

Ein häufiges Missverständnis besteht in der Annahme, dass ein externes Python-Skript direkt auf eine bereits laufende Omniverse-Anwendung zugreifen kann. Tatsächlich handelt es sich bei einer laufenden Anwendung – etwa einer individuell entwickelten App auf Basis des Kit App Templates – um einen separaten Prozess mit einem eigenen Speicherkontext. Wird ein externes Skript wie cube-scale.py ausgeführt, startet dieses ebenfalls einen eigenen Prozess mit einer neuen USD-Stage. Auch wenn beide Instanzen dieselbe .usd-Datei laden, handelt es sich technisch um zwei vollständig getrennte Welten. Ein direkter Zugriff auf die interne Szene einer laufenden Anwendung ist nur über gezielte Interprozesskommunikation (IPC) möglich, beispielsweise über Sockets, Shared Memory oder Remote Procedure Calls (RPC).

Eine einfache und dennoch leistungsfähige Möglichkeit zur Live-Manipulation von Szenen bietet der USD Composer. Dabei handelt es sich um eine Omniverse-Anwendung mit vollständiger grafischer Benutzeroberfläche, Viewport und eingebautem Script Editor. In diesem Editor lassen sich Python-Skripte direkt ausführen, während die Szene geladen ist. Änderungen an Objekten – wie das Skalieren eines Würfels – werden sofort sichtbar und können dauerhaft gespeichert werden.

from pxr import Usd, UsdGeom, Gf
import random

# Szene laden
stage = Usd.Stage.Open("C:/tools/omniverse/usd/cube.usd")
cube = stage.GetPrimAtPath("/World/Cube")
xform = UsdGeom.Xformable(cube)

# Existierende Skalierung holen (oder neu anlegen, falls nicht vorhanden)
scale_ops = xform.GetOrderedXformOps()
scale_op = None

# Vorhandene Skalierungsoperation suchen
for op in scale_ops:
    if op.GetOpType() == UsdGeom.XformOp.TypeScale:
        scale_op = op
        break

# Falls keine vorhanden, neu anlegen
if not scale_op:
    scale_op = xform.AddScaleOp()

# Zufällige Skalierung erzeugen
scale_value = Gf.Vec3f(
    round(random.uniform(0.5, 2.0), 2),
    round(random.uniform(0.5, 2.0), 2),
    round(random.uniform(0.5, 2.0), 2)
)

# Skalierung setzen
scale_op.Set(scale_value)

# Speichern
stage.GetRootLayer().Save()
print(f"Zufällige Skalierung gesetzt: {scale_value}")

Auch innerhalb von benutzerdefinierten Anwendungen, die auf dem Kit App Template basieren, lässt sich ein solcher Script Editor aktivieren. Standardmäßig ist er in der Basisversion nicht enthalten, kann aber über die Konfigurationsdatei app.toml eingebunden werden. Durch das Hinzufügen der Zeile „omni.kit.window.script_editor“ = {} im [dependencies]-Abschnitt wird der Script Editor beim nächsten Start der App verfügbar gemacht und kann über das Menü „Window“ geöffnet werden. Dadurch lassen sich Szenen auch in eigenen Anwendungen flexibel erweitern, testen und verändern – direkt zur Laufzeit und ohne den Umweg über externe Prozesse.

Omniverse Client Library Python API

Die Omniverse Client Library (Python API) ist eine Schnittstelle, mit der Entwickler direkt aus Python heraus mit dem Omniverse-Dateisystem und der NVIDIA Omniverse-Plattform kommunizieren können. Sie ermöglicht den Zugriff auf Dateien und Verzeichnisse, die sich lokal oder auf einem Omniverse Nucleus Server befinden, sowie das Abonnieren von Änderungen an Dateien, das Schreiben, Lesen, Löschen oder Überprüfen von Zugriffsrechten.

Die API abstrahiert das zugrunde liegende Netzwerkprotokoll und erlaubt so eine einheitliche Behandlung lokaler und entfernter Ressourcen. Entwickler können z. B. mit wenigen Zeilen Code USD-Dateien auslesen, Metadaten abrufen oder sich benachrichtigen lassen, wenn sich Dateien ändern – unabhängig davon, ob die Datei auf einem lokalen Laufwerk, in der Cloud oder auf einem Nucleus-Server liegt.

Eingesetzt wird die Omniverse Client Library typischerweise in Anwendungen, die mit digitalen Assets arbeiten: z. B. für Tools in 3D-Design, Simulation, KI-Training, Digital Twins oder bei der Pipeline-Integration in Studios. Die Python-API eignet sich besonders gut für schnelle Automatisierungen, Dashboards, Content-Validierung oder auch als Teil größerer Workflows z. B. in Verbindung mit Omniverse Kit.

Die Omniverse Client Library Python API ist unter der folgenden URL zu finden:

https://docs.omniverse.nvidia.com/kit/docs/client_library/latest/docs/python.html#

Beispiel omni.client.AccessFlags

Sensorwert in einem 3D-Objekt live anzeigen

Um Sensordaten live in einem 3D-Modell darzustellen, habe ich mehrere Technologien miteinander kombiniert: Ein physischer Sensor liefert Messdaten – zum Beispiel ein Drehregler, der Werte von -150 bis +150 ausgibt. Diese Sensordaten werden per MQTT-Protokoll an einen lokalen MQTT-Broker übermittelt. In meinem Fall nutze ich Mosquitto. Der Sensor publiziert seine Daten in regelmäßigen Abständen (z. B. jede Sekunde) an einen bestimmten MQTT-Topic, in meinem Fall: sensor/rotary_poti. Die Daten bestehen aus einfachen JSON-Payloads wie { „value“: 42 }.

Um den Datenfluss zu überwachen und eine grafische Visualisierung außerhalb des 3D-Raums zu erhalten, habe ich die Daten parallel in Node-RED abgegriffen. Node-RED erlaubt es mir, über einfache Drag-and-Drop-Logikdatenflüsse das MQTT-Topic zu abonnieren und z. B. den Wert auf einem Dashboard darzustellen. Damit konnte ich sicherstellen, dass mein Sensor korrekt sendet und der MQTT-Broker die Daten weiterleitet.

Das zentrale Ziel war jedoch, die Sensordaten auch innerhalb einer 3D-Welt darzustellen – also ein 3D-Modell live auf den Sensorwert reagieren zu lassen. Dafür verwende ich NVIDIA Omniverse USD Composer.

Die 3D-Objekte selbst – also die Ziffern 0 bis 9 sowie das Plus- und Minuszeichen – habe ich ursprünglich in Blender modelliert. Blender spielt in diesem Setup die Rolle des Modellierungswerkzeugs: Es wird genutzt, um einmalig die Form der Ziffern und Zeichen zu gestalten. Die eigentliche Animation bzw. Anzeige dieser Formen übernimmt dann die Python-Logik in Omniverse, die die Objekte bei Bedarf kopiert, verschiebt und sichtbar macht.

Nach der Modellierung habe ich die Objekte in das USD-Format exportiert oder in USD Composer importiert.

Die Logik, die diese 3D-Objekte sichtbar macht und dynamisch verändert, basiert auf einem Python-Skript innerhalb von Omniverse. Dieses Skript wird im internen Script-Editor von USD Composer ausgeführt. Es verbindet sich über eine Python-Bibliothek (paho-mqtt) mit dem MQTT-Broker und registriert sich auf das Topic sensor/rotary_poti. Sobald ein neuer Wert eintrifft, wird dieser verarbeitet: Das Skript berechnet aus dem Wert das Vorzeichen und die einzelnen Ziffern. Zum Beispiel wird der Wert -128 in vier Elemente aufgeteilt: das Minuszeichen und die Ziffern 1, 2 und 8.

Für jede dieser vier Positionen (Slots) wird das passende 3D-Modell geladen und innerhalb der Szene neu gesetzt. Das bedeutet, dass die alten Ziffern entfernt und durch neue ersetzt werden – je nachdem, wie sich der Sensorwert verändert. Die 3D-Objekte werden dabei nicht nur ausgewählt, sondern auch frei positioniert und rotiert, um sie korrekt auf einer Fläche anzuzeigen, z. B. auf einer grünen Anzeigeplatte. Die Positionen und Drehungen sind dabei für jedes einzelne Zeichen individuell konfigurierbar, sodass man das Layout frei anpassen kann.

import omni.usd
import asyncio
import json
import paho.mqtt.client as mqtt
from pxr import Usd, Sdf, Gf

# === Konfiguration
DIGIT_PATH = "/root/ziffern"
PLUS_PATH = f"{DIGIT_PATH}/plus"
MINUS_PATH = f"{DIGIT_PATH}/minus"
SLOT_BASE_PATH = "/root/slot_"

stage = omni.usd.get_context().get_stage()
event_loop = asyncio.get_event_loop()
last_sources = [""] * 4

# === Benutzerdefinierte Positionen & Rotationen pro Slot
TRANSFORMS = {
    0: {"translate": Gf.Vec3f(1.0, -3.5, 0.6), "rotate": Gf.Vec3f(0.0, 0.0, 90.0)},  # Vorzeichen
    1: {"translate": Gf.Vec3f(2.0, 1.0, 0.0), "rotate": Gf.Vec3f(0.0, 0.0, 90.0)},  # Ziffer 1
    2: {"translate": Gf.Vec3f(2.0,  1.5, 0.0), "rotate": Gf.Vec3f(0.0, 0.0, 90.0)},  # Ziffer 2
    3: {"translate": Gf.Vec3f(2.0,  2.0, 0.0), "rotate": Gf.Vec3f(0.0, 0.0, 90.0)},  # Ziffer 3
}

# === Slot bereinigen
def clear_slot(slot_index):
    path = f"{SLOT_BASE_PATH}{slot_index}/digit"
    prim = stage.GetPrimAtPath(path)
    if prim.IsValid():
        stage.RemovePrim(path)

# === Sichtbares Mesh/Text finden
def resolve_mesh_path(source_path):
    prim = stage.GetPrimAtPath(source_path)
    if not prim.IsValid():
        return None
    if prim.GetTypeName() in ["Mesh", "Text"]:
        return source_path
    for child in prim.GetChildren():
        result = resolve_mesh_path(str(child.GetPath()))
        if result:
            return result
    return None

# === Mesh kopieren und platzieren
def duplicate_mesh(source_path, target_path, slot_index):
    source_prim = stage.GetPrimAtPath(source_path)
    if not source_prim.IsValid():
        print(f"[WARN] Quelle '{source_path}' ungültig.")
        return

    if stage.GetPrimAtPath(target_path).IsValid():
        stage.RemovePrim(target_path)

    mesh = stage.DefinePrim(target_path, source_prim.GetTypeName())

    for attr in source_prim.GetAttributes():
        try:
            val = attr.Get()
            if val is not None:
                new_attr = mesh.CreateAttribute(attr.GetName(), attr.GetTypeName())
                new_attr.Set(val)
        except Exception as e:
            print(f"[ATTR-WARN] {attr.GetName()} nicht kopiert: {e}")

    # Transform setzen
    t = TRANSFORMS.get(slot_index, {"translate": Gf.Vec3f(0, 0, 0), "rotate": Gf.Vec3f(0, 0, 0)})
    mesh.CreateAttribute("xformOp:translate", Sdf.ValueTypeNames.Float3).Set(t["translate"])
    mesh.CreateAttribute("xformOp:rotateXYZ", Sdf.ValueTypeNames.Float3).Set(t["rotate"])
    mesh.CreateAttribute("xformOpOrder", Sdf.ValueTypeNames.TokenArray).Set(["xformOp:translate", "xformOp:rotateXYZ"])

# === Anzeige aktualisieren
def show_digit(source_path, slot_index):
    if slot_index > 0 and last_sources[slot_index] == source_path:
        return
    last_sources[slot_index] = source_path

    clear_slot(slot_index)

    real_path = source_path if slot_index == 0 else resolve_mesh_path(source_path)
    if not real_path:
        print(f"[WARN] Kein sichtbarer Mesh unter {source_path}")
        return

    target_path = f"{SLOT_BASE_PATH}{slot_index}/digit"
    duplicate_mesh(real_path, target_path, slot_index)
    print(f"[DEBUG] Slot {slot_index}: {real_path} → {target_path}")

# === MQTT Verarbeitung
async def process_payload(payload_str):
    try:
        payload = json.loads(payload_str)
        raw_value = int(str(payload["value"]).strip())
        print(f"[DEBUG] MQTT empfangen: {raw_value}")

        value = abs(raw_value)
        sign = PLUS_PATH if raw_value >= 0 else MINUS_PATH
        digits = f"{value:03d}"

        sources = [sign]   [f"{DIGIT_PATH}/_{int(c):02d}" for c in digits]

        for i, src in enumerate(sources):
            show_digit(src, i)

    except Exception as e:
        print(f"[Fehler bei MQTT-Parsing]: {e}")

# === MQTT Callback
def on_message(client, userdata, msg):
    asyncio.run_coroutine_threadsafe(
        process_payload(msg.payload.decode()), event_loop
    )

# === MQTT starten
def start_mqtt():
    client = mqtt.Client()
    client.on_message = on_message
    client.connect("localhost", 1883, 60)
    client.subscribe("sensor/rotary_poti")
    client.loop_start()

# === Hauptloop
async def run():
    print("[INFO] Starte MQTT-Display...")
    start_mqtt()
    while True:
        await asyncio.sleep(0.05)

# === Start
asyncio.ensure_future(run())

Dieses Demo zeigt, wie sich echte Messwerte mit digitalen Zwillingen oder interaktiven 3D-Welten verbinden lassen.