Vom 3D-Modell zum Web-Konfigurator: Was OpenUSD & USDZ im B2B-Vertrieb wirklich leisten: USDconfig 1.1
USDconfig ist ein modulares Web-Framework für 3D-Produktkonfiguratoren auf Basis von OpenUSD und USDZ — nativ im Browser, AR ohne App.
- USDconfig liest OpenUSD-Variantensets direkt aus USDZ-Masterdateien, d.h. kein manuelles Setup, keine kombinatorische Datei-Explosion.
- Safari auf VisionOS rendert USDZ nativ über den <model>-Tag mit vollem OpenUSD-Fidelity, alle anderen Browser nutzen vorerst GLB via model-viewer. Beide Pfade, ein Player, kein Reload.
- iOS-AR startet direkt in Quick Look, Android-AR via Scene Viewer — aus demselben Web-Player heraus, ein einziger Button.
Was ist USDconfig 1.1?
USDconfig ist ein modulares Web-Framework für 3D-Produktkonfiguratoren auf Basis von OpenUSD & dem USDZ-Dateiformat. Es verbindet die native 3D-Rendering-Kompetenz von Apples OpenUSD-Standard mit dem offenen Web — und macht erklärungsintensive B2B-Produkte direkt im Browser und in Augmented Reality konfigurierbar.
Entstanden aus der Arbeit mit Industriekunden, die komplexe Produktvarianten in Vertriebsgesprächen zeigen müssen — ohne Musterkoffer, ohne Vor-Ort-Termin, ohne App-Installation auf Kundenseite.
→ Produktübersicht: USDconfig für B2B-Vertrieb
Vorgeschichte: AR-Player, ConfigXR & USDconfig 1.0
2021 begannen wir mit der Entwicklung unseres ersten AR-Players, der dann von unsrem Produkt ConfigXR (Builder) abgelöst wurde, inzwischen OpenSource auf Github zu finden.
Mit dem Start der Apple Vision Pro kam ein neuer Bedarf auf und wir entwickelten ein neues Web-Player-Tool USDconfig. Dazu gehörte schon ein neuer Konvertierungsansatz.
→ Fallbeispiel RENZ: Verkauf beginnt mit Erleben (USDconfig 1.0)
Neu mit Version 1.1. ist der automatische USDconfig-Analyzer, der direkt eine USDZ-Masterdatei analysiert und für die weiteren Schritte aufbereitet.
Welches Problem löst USDconfig?
3D-Produktkonfiguratoren im B2B scheitern meist nicht am 3D, sondern an der Infrastruktur dahinter. Varianten werden als separate Dateien verwaltet, AR erfordert App-Downloads, und was in Safari funktioniert, bricht in Chrome zusammen.
USDconfig trennt strukturelle Varianten — verschiedene Geometrien wie Armlehnen, Sockeltypen oder Gehäuseformen — von materiellen Varianten wie Farben, Oberflächen und Texturen. Strukturvarianten werden als separate Dateien generiert: überschaubar in der Anzahl. Materialvarianten leben als KHR_materials_variants-Extension direkt im GLB-File und werden ohne Datei-Reload live umgeschaltet.
Keine kombinatorische Explosion, keine 400 Einzeldateien pro Produkt.
Live Demo — Vitra ID Chair (Konzeptansicht)
Der folgende Beta-Player zeigt den USDconfig-Konfigurator in Aktion — alle Assets sind live. 39 Bezugfarben, alle Strukturvarianten und die AR-Übergabe funktionieren vollständig.
Dislaimer: Wir haben von der Vitra-Website die Elemente übernommen und für USDZ mit Varianten und Top-Texturen optimiert. Dies war die Highend-Testdatei für unseren neuen Analyser.
→ Alternativ: Als Step-by-Step-Guide-Konfigurator / Wizard
→ Technik-Demo (Mobile) mit Web-Konfigurator & Apple-Pay-Button in AR
Wie funktioniert das USDconfig-Produkt-Package?
Das System besteht aus vier Modulen — zwei Python-seitig (viSales-Lokal), zwei im Browser. Die Pipeline startet bei der USDZ-Masterdatei aus Reality Composer Pro oder einem anderen USD-Workflow wie z.B. NVIDIA Omniverse via USDbridge und endet beim fertigen Web-Produktkonfigurator mit AR-Button.
Aktuell nutzen wir <model>-Tag nur für die Apple Vision Pro, sind aber für die weitere Apple-Zukunft vorbereitet. Sollte Apple für iOS, iPadOS oder macOS <model>-Tag aus der Beta herausholen, so können wir sehr kurzfristig das höhere Potential von nativem USDZ im Browser Rechnung tragen.
Roadmap-Pläne
v1.2 — Quick Wins (kurzfristig)
- Desktop AR → QR-Code-Flow: Wer am Desktop auf "In AR anzeigen" klickt, bekommt heute nichts Brauchbares. Besser: Modal mit QR-Code der direkt auf die aktuelle Konfiguration zeigt, daneben "Öffne diesen Link auf deinem iPhone → AR startet automatisch". Konfigurationslink via URL-Parameter übergeben. (So ca. wie USDconfig 1.0 es auch gelöst hat.)
- Wizard: Summary-Screen: Nach Bezug-Auswahl eine Zusammenfassung aller Choices zeigen, bevor AR/Teilen erscheint. Visueller Abschlussmoment, ggf. Kamerafahrt?
v1.3 — Plattform-Ausbau (mittelfristig)
- visionOS-Modus: User-Agent-Erkennung für visionOS → statt vollem 2D-Konfigurator: ein minimales Floating-Menu mit 3-4 Buttons +
<model>-Tag mit der Masterdatei im Vordergrund. "Produkt in AR erleben — Variante wählen und starten." Der Headset-User soll nicht tippen, er soll schauen. - media.visales.de als USDZ-Host:
.htaccessmit korrektem MIME-Type →<model>-Tag läuft in Safari macOS. Dann: Safari-Badge wird zu "Safari · native USD" mit echter Funktion. - Gestell-Farbvariante: Pulverbeschichtet (weiß/schwarz/RAL) als zweite KHR-Gruppe — ohne neue Dateien.
v2.0 — OpenUSD-Native (langfristig, mit v26.03)
- WebAssembly USD-Runtime: OpenUSD läuft direkt im Browser. USD-VariantSets live schalten ohne GLB-Konvertierung. Kein KHR_materials_variants mehr nötig. Die Masterdatei IS der Player.
- Konfigurator-Generator: URL-Builder als Tool — Kunde gibt Produkt-URL ein, bekommt Embed-Snippet für sein CMS.
- Analytics: Welche Variante wird am häufigsten gewählt? Heatmap der Bezugfarben. Abbruchpunkt im Wizard.
Typische (Technik-) Entscheiderfragen
Welche 3D-Formate werden unterstützt?
USDconfig arbeitet nativ mit USDZ (OpenUSD) und GLB (glTF 2.0). USDZ ist das Primärformat für Safari-Rendering und iOS-AR via Quick Look. GLB wird für alle anderen Browser sowie Android-AR via Scene Viewer genutzt. CAD-Daten aus gängigen Systemen (STEP, SolidWorks, CATIA) werden im Rahmen der viSales-Pipeline konvertiert.
Brauche ich eine eigene App für die AR-Funktion?
Nein. iOS-AR läuft über Apples Quick Look — direkt aus dem Browser, ohne App-Download. Android-AR nutzt Google Scene Viewer, der auf jedem modernen Android-Gerät vorinstalliert ist. Kein App Store, kein Update-Zwang auf Kundenseite.
Wie viele Varianten-Kombinationen sind realistisch umsetzbar?
USDconfig trennt strukturelle Varianten (Geometrieänderungen) von materiellen Varianten (Farben, Texturen). Strukturvarianten erzeugen separate Dateien — realistisch sind 4–12 Kombinationen. Materialvarianten laufen über KHR_materials_variants im GLB und verursachen keine zusätzlichen Dateien. Beispiel Bürostuhl: 3 Armlehnen × 2 Sitzformen = 6 GLB-Dateien, dazu beliebig viele Bezugfarben ohne Mehraufwand.
Funktioniert der Player auch in Ghost CMS oder anderen CMS?
Ja. Der Player wird als statische HTML-Datei auf einem Webserver oder GitHub Pages gehostet und per iframe in Ghost, WordPress, Webflow oder jedes andere CMS eingebunden. Der iframe-Snippet ist parametrisierbar — Produkt, Startvarianten und Asset-URLs werden als URL-Parameter übergeben.
Was ist der Unterschied zu model-viewer alleine?
Google model-viewer rendert GLB-Dateien über WebGL in allen Browsern — solide, aber ohne nativen OpenUSD-Support. USDconfig ergänzt einen Safari-Pfad über den HTML-<model>-Tag, der USDZ mit vollem OpenUSD-Fidelity direkt in WebKit rendert — inklusive Variant Sets aus dem USD-Schema, ohne Konvertierungsverluste. Beide Pfade werden vom selben Web-Player automatisch erkannt und genutzt.
Warum nicht einfach three.js oder Babylon.js?
three.js und Babylon.js sind leistungsstarke 3D-Engines für das Web — aber sie rendern über WebGL und kennen kein OpenUSD nativ. Das bedeutet: Alle USD-spezifischen Konzepte wie Variant Sets, Layering, Stage-Composition müssen entweder weggelassen oder manuell nachgebaut werden. Der Konvertierungsweg von USDZ → glTF → WebGL kostet Fidelity & Qualität, vor allem bei Materialien und Texturauflösung.
USDconfig nutzt model-viewer als WebGL-Fallback für Chrome, Firefox und Edge — und legt für Safari bewusst den nativen <model>-Pfad oben drauf. So bleibt OpenUSD-Fidelity erhalten, wo der Browser es unterstützt, ohne für alle anderen Geräte auf Kompatibilität zu verzichten.
