Vom 3D-Modell zum Web-Konfigurator: Was OpenUSD & USDZ im B2B-Vertrieb wirklich leisten: USDconfig 1.1
- 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: Drehlix-Konfigurator
Der folgende Konfigurator zeigt USDconfig in Aktion, alle Assets sind live: vier Schritte, 39 Bezüge, Regeln mit Sperre und die AR-Übergabe.
Fiktives Demo-Produkt, Demowerte, kein Angebot
Herkunft: Fiktives Demo-Produkt, 3D-Daten nach Vorlage eines Bürodrehstuhls. Preise und Gewichte sind Demowerte und kein Angebot.
→ Technik-Demo (Mobile) mit Web-Konfigurator & Apple-Pay-Button in AR
→ Drehlix-Konfigurator mit Regeln und Werten, zeigt schon vor dem Klick, warum eine Option nicht wählbar ist
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 + -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: `.htaccess` mit korrektem MIME-Type →-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.
Einstieg in den AR-Konfigurator — mit Unterstützung.
Wir begleiten Unternehmen vom ersten USDZ-Modell bis zum vollständigen Web-Konfigurator im Vertrieb. Das erste Gespräch dauert 30 Minuten. Ohne Pitch, ohne Vorbereitungspflicht. Rheingas, Somfy und Carl Hamm haben mit einem Produkt begonnen.
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 meinem CMS?
Ja. Der Player wird als statische HTML-Datei auf einem Webserver oder GitHub Pages gehostet und per iframe in WordPress, Webflow oder jedes andere CMS, das iframes zulässt, 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–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 -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.