USD, USDA, USDC, USDZ und Reality: Was ist was, und wann braucht man welches OpenUSD-Format?
- USD, USDA, USDC, USDZ und Reality sind fünf Formate im OpenUSD-Ökosystem, jedes hat eine andere Rolle in der 3D-Pipeline.
- USDZ kann Animationen, Interaktionen und Physik , nicht nur statische Modelle. Wir setzen das täglich in B2B-Projekten ein.
- Reality ist Apples Black Box: Du kannst anschauen, aber nicht reinschauen, ein Vorteil für den Schutz technischer Details.
Fünf Dateiendungen, ein Ökosystem, null Überblick im Markt. In fast jedem Erstgespräch mit Kunden kommt die Frage: „Können Sie uns ein USDZ machen?“, als wäre das ein einzelnes Ding. Doch dahinter steckt eine Familie von Formaten, die aufeinander aufbauen.
Ich arbeite seit Jahren mit OpenUSD, bin mit meiner Firma Mitglied der Alliance for OpenUSD und nutzen im Team diese Formate: In CAD-Konvertierungen, AR-Projekten und Produktkonfiguratoren. Was in der Spezifikation steht, ist das eine. Was in der Praxis passiert, ist oft etwas anderes. Deshalb hier eine Einordnung, wie sie in keinem Datenblatt steht.
Fünf Formate, eine Pipeline:
Wann welches OpenUSD-Format zum Einsatz kommt
USD (.usd) ist die generische Dateiendung. Sie sagt: hier ist eine Universal Scene Description drin — aber nicht, in welchem Encoding. Eine .usd-Datei kann ASCII sein oder binär. Das klingt nach einem Detail, ist aber in der Praxis relevant, weil sich manche Tools an der Endung orientieren und andere am Inhalt. Wer Pipelines baut, sollte sich nicht auf .usd verlassen, sondern explizit .usda oder .usdc verwenden.
USDA (*.usda) ist das ASCII-Textformat
Man kann es mit jedem Texteditor öffnen und lesen. Das macht es unverzichtbar für Debugging, Versionierung und Qualitätsprüfung. Oder wenn wir "von Hand" / KI-Tool Coden. Wenn in einem Kundenprojekt ein 3D-Modell in AR falsch dargestellt wird, ist die erste Aktion immer: USDA öffnen und nachschauen, wo der Fehler in der Szenenstruktur liegt. USDA-Dateien sind größer und langsamer zu laden, aber sie sind das ehrlichste Format im ganzen Ökosystem — was drinsteht, ist das, was gemeint ist.
USDC (*.usdc) ist das binäre „Crate“-Format
Gleicher Inhalt wie USDA, aber komprimiert und für schnelles Laden optimiert. In Produktions-Pipelines ist USDC der Standard: kleine Dateien, schnelles Parsing, geeignet für automatisierte Workflows. Wer Szenen programmatisch zusammenbaut — etwa aus CAD-Daten einen Produktkonfigurator generiert — arbeitet intern fast immer mit USDC.
USDZ (*.usdz) ist das Auslieferungsformat
Technisch ein ZIP-Archiv, das eine USDC-Datei zusammen mit Texturen, Materialien und optional Audio in einem einzigen File bündelt. Keine externen Abhängigkeiten, keine fehlenden Texturen, kein Nachinstallieren. USDZ ist das Format, das Apple für AR Quick Look verwendet — ein Link oder QR-Code genügt, und das 3D-Modell erscheint auf dem iPhone im Raum. Ohne App.
Was viele nicht wissen: USDZ kann weit mehr als statische 3D-Modelle. Animationen, interaktive Elemente und sogar Physik-Simulationen sind im Format angelegt und wir haben das in zahlreichen Projekten umgesetzt. Für Siemens DDX haben wir animierte und interaktive USDZ-Modelle gebaut, für Zgoll einen vollständigen AR-Konfigurator, beides direkt in AR Quick Look erlebbar. Mehr Beispiele auf unserer Seite Augmented Reality.
Reality (*.reality) ist Apples eigenes Format für RealityKit
Erstellt wird es mit Reality Composer Pro, Apples Tool für räumliche Inhalte. Reality-Dateien laufen auf iPhone, iPad und Apple Vision Pro.
Der entscheidende Unterschied zu USDZ ist nicht der Funktionsumfang — es ist die Transparenz. Eine USDA-Datei kann jeder öffnen, lesen, debuggen. Eine USDZ-Datei lässt sich entpacken und analysieren. Aber eine Reality-Datei? Die ist wie eine schreibgeschützte PowerPoint: Du kannst sie anschauen, aber nicht mehr reinschauen.
Dass Apple damit undokumentierte Funktionen verstecken kann, haben wir bei deren eigenen Demos mehrfach erlebt, das ist ein Nebeneffekt des geschlossenen Containers. Aber der hat auch einen praktischen Nutzen für uns: Wir setzen Reality-Dateien bei Industriekunden ein, um technische Details zu sichern, die nicht ausgelesen werden können.
Kein perfekter Schutz — die Außenansicht einer Maschine lässt sich immer noch reverse-engineeren. Aber interne Konstruktionsdetails, Bewegungsabläufe, Maße? Die bleiben in der Black Box. Bei USDA liest jeder mit. Bei Reality: nur noch anschauen.
In der Praxis setzen wir USDZ ein, wenn es um breite Erreichbarkeit und Offenheit geht — und Reality, wenn ein Projekt tief in Apples Ökosystem lebt oder wenn technische Details geschützt bleiben sollen.
*.reality wird von Apple selbst in aktuellen Tools nicht mehr erzeugt. Wir nutzen in dem Fall einen älteren Stand von Reality Composer Pro. Wir hoffen das eine neue RCP-Version diese Funktion zum Export wieder anbietet. Die Dateien werden mit Sicherheit noch einige Jahre auf Apple-Geräten lauffähig sein denn Apple unterstützt ja alle älteren Funktionen für 7+ Jahre.
In der Praxis sieht die Kette so aus: CAD-Daten (STEP, IGES) kommen aus der Konstruktion. Sie werden in USD konvertiert, als USDA zur Prüfung, als USDC für die Pipeline. Aus USDC wird USDZ für die AR-Auslieferung per AR Quick Look. Und wenn das Projekt interaktive Elemente braucht, wird parallel eine Reality-Datei in Reality Composer Pro gebaut.
Wer diese Kette versteht, stellt im Erstgespräch die richtigen Fragen. Nicht „Können Sie uns ein USDZ machen?“, sondern: „Welche Daten haben wir, und was soll am Ende beim Kunden ankommen?“