Vom CAD-Modell zum Visual Twin: Warum kein einzelnes Format die Antwort ist

Zwischen Konstruktionsdaten und der nutzbaren Anwendung im Browser, am Touchtable oder in der AR-Brille liegt Übersetzungsarbeit, die selten als solche erkannt wird. Ein Blick auf die Pipeline – und warum Blender heute der Hub ist, OpenUSD aber das Spielfeld der nächsten Jahre prägt.

Die Frage taucht in fast jedem Erstgespräch auf, manchmal vorsichtig, manchmal mit dem Anspruch, eigentlich schon fertig zu sein: „Wir haben CAD-Daten. Können Sie uns daraus einen Konfigurator bauen?". Die Antwort wäre einfach, wenn sie nicht falsch wäre. Sie lautet: "Ja, natürlich." Sie lautet aber auch: "Nicht aus diesen Daten."

Ein Kunde hat uns vor Kurzem eine STEP-Datei geschickt und gefragt, warum die nicht direkt im Browser läuft. Die ehrliche Antwort ist: weil eine STEP-Datei nie für den Browser gedacht war. Sie ist für die Fertigung gedacht. Das ist ein Unterschied, der erstaunlich oft erklärt werden muss.

In nahezu jedem Industrieunternehmen werden heute hochwertige 3D-Daten erstellt. Sie entstehen täglich in der Konstruktion, im Engineering und der Produktentwicklung – als STEP, IGES oder als native Files aus Siemens NX, CATIA, SolidWorks, Inventor, Creo. Diese Daten sind technisch präzise: Sie beschreiben Bauteile, Toleranzen, Flächen und Baugruppen exakt so, wie sie für die Fertigung gebraucht werden. Für eine digitale Anwendung sind sie trotzdem unbrauchbar. Sie sind zu schwer, zu detailliert, nicht texturiert, nicht für Echtzeit optimiert und visuell nicht aufbereitet. Wer eine STEP-Datei ohne Umweg in einen WebGL-Viewer schiebt, scheitert spätestens an der Performance – meistens aber früher, am Look.

Zwischen Konstruktionsdaten und digitaler Anwendung liegt also keine Konvertierung, sondern eine Übersetzung. Genau diese Arbeit ist das, was wir bei DIGITALE meinen, wenn wir vom "Digitalen Zwilling für die Visualisierung" oder auch Visual Twin sprechen.

Vier Begriffe, und ein Markt, der sich noch sortiert

Wer heute über digitale Zwillinge redet, redet selten über dasselbe. "Digital Twin", "Virtual Twin", "Visual Twin", "Product Twin", "3D Twin" – die Begriffe sind im Umlauf, auf Deutsch oder Englisch. Pragmatisch lassen sie sich so ordnen: Ein Digital Twin im engeren Sinn ist ein datengetriebenes Modell, das mit realen Zuständen, Sensorik oder Systemdaten verknüpft ist. Ein Virtual Twin wird häufig im Kontext von Simulation und virtueller Produktentwicklung verwendet. Ein Visual Twin beschreibt die visuelle, interaktive Repräsentation eines Produkts – fotorealistisch, in Echtzeit, in AR oder eben auf einem Multitouch-Tisch in der Messehalle.

Für die meisten Projekte ist diese Unterscheidung allerdings zweitrangig. Wichtig ist die strategische Idee dahinter: Die vorhandene CAD-Basis wird nicht weggeworfen. Sie wird übersetzt, veredelt und so vorbereitet, dass aus ein und derselben Datenbasis später ein WebGL-Konfigurator, ein iPad-AR-Modell oder ein fotorealistisches Rendering entstehen kann.

„Wir hatten lange das Gefühl, wir müssten uns auf einen Begriff festlegen. Inzwischen denken wir eher von der Anwendung her zurück. Erst klären wir, was der Kunde zeigen will, dann sortiert sich die Bezeichnung von selbst."

Aus Konstruktionsdaten wird ein Twin

Der häufigste Irrtum lautet: Man nehme eine CAD-Datei, exportiere sie in ein anderes Format, und damit sei der Twin gebaut. In der Praxis funktioniert das selten sauber, weil CAD-Daten und Echtzeit-Daten unterschiedliche Welten beschreiben. CAD arbeitet mit mathematisch exakten Flächen, mit NURBS und B-Reps. Digitale Anwendungen wollen optimierte Polygonmodelle. Der erste technische Schritt ist daher die "Tessellation" – die Übersetzung präziser Flächen in darstellbare Meshes.

Erst danach beginnt die eigentliche Arbeit, und sie ist weniger glamourös, als der Begriff "Digital Twin" vermuten lässt. Geometrie wird reduziert, ohne dass das Bauteil seine Erkennbarkeit verliert. Innenliegende Teile, die niemand jemals sehen wird, fliegen raus. Hierarchien werden neu aufgebaut, Bauteile sinnvoll benannt, Varianten vorbereitet, Symmetrien genutzt. UVs werden gelegt, Texturen zugewiesen, Materialien physikalisch plausibel definiert. Das Ergebnis ist kein Export. Es ist ein strukturierter, anwendbarer Datenkern – und aus diesem Kern werden die unterschiedlichen Zielformate erst danach abgeleitet.

„Die Reduktionsarbeit unterschätzt fast jeder, der zum ersten Mal mit dem Thema zu tun hat. Eine Industriebaugruppe mit dreißigtausend Schrauben sieht im CAD beeindruckend aus. Im Browser bringt sie den Rechner oder das Smartphone zum Schwitzen."

Die Konsequenz daraus klingt unspektakulär, ist in der Praxis aber entscheidend: Das Zielformat steht nicht am Anfang einer Pipeline, sondern an ihrem Ende. Am Anfang steht eine saubere, strukturierte 3D-Datenbasis, aufgebaut so, dass daraus mehrere Anwendungen abgeleitet werden können. Ein Web-Konfigurator hat andere Anforderungen als eine iPhone-AR-Anwendung; ein Messe-Rendering braucht andere Daten als eine Echtzeit-Anwendung auf dem Multitouch-Tisch.

Blender – der ehrliche Mittelpunkt

Strategisch wird auf Konferenzen viel über OpenUSD gesprochen. Operativ, im Agenturalltag und im Tagesgeschäft, läuft das meiste gerade über Blender. Das ist keine Verlegenheit. Es hat Gründe, und sie sind gut.

Blender ist verfügbar, leistungsfähig, frei, sauber dokumentiert und in nahezu jedem 3D-Workflow anschlussfähig. Es eignet sich für die Modellbereinigung nach dem CAD-Import, für Materialaufbau und Texturierung, für Animation und Variantenmanagement, für die Echtzeitvorschau in Eevee genauso wie für das fotorealistische Rendering in Cycles. Und es exportiert in praktisch jedes relevante Zielformat. Drei Eigenschaften machen es im Agenturkontext besonders stark – seine Allgegenwart, seine Offenheit und seine Produktivität. Jede 3D-Agentur, jede Designabteilung, fast jeder qualifizierte Freelancer kann Blender öffnen. Das senkt die Reibung in Projektpartnerschaften erheblich, weil sich Daten übergeben lassen, ohne vorher über Lizenzen sprechen zu müssen. Kein Dongle, kein Wartungsvertrag, keine Floating-Lizenz – Onboarding und Skalierung gehen schneller. Und der gesamte Pipeline-Mittelteil, vom CAD-Import bis zum finalen GLB- oder USDZ-Export, lässt sich in einem einzigen Werkzeug abbilden.

„Blender ist für uns der Pragmatismus in Reinform. Es ist nicht das Tool, das am lautesten beworben wird, aber es ist das Tool, mit dem wir am verlässlichsten ans Ziel kommen. Und wenn wir einen Teil einer Produktion an ein Partnerstudio abgeben, müssen wir nicht erst eine halbe Stunde über Software reden."

Für viele Studios, auch für uns, ist Blender deshalb kein bloßes Werkzeug, sondern der praktische Hub zwischen CAD-Import, visueller Bearbeitung und Zielformat.

OpenUSD ist das Spielfeld der nächsten Jahre – nicht das nächste Format

So produktiv Blender heute ist – an OpenUSD wird mittelfristig kaum ein Weg vorbeiführen, jedenfalls nicht in den Pipelines, in denen Skalierung, Modularität und tool­übergreifende Zusammenarbeit eine Rolle spielen.

OpenUSD (Universal Scene Description) wurde ursprünglich von Pixar entwickelt und ist heute ein offener Industriestandard. Es ist kein Dateiformat im klassischen Sinn, sondern eine Beschreibungssprache für Szenen – mit Hierarchien, Abhängigkeiten, Varianten, Layern und Referenzen. Damit löst USD Probleme, an denen klassische Austauschformate scheitern, sobald die Szene komplex, kollaborativ oder modular wird.

Den entscheidenden Schub bekommt OpenUSD aktuell von Nvidia® Omniverse. Nvidia® setzt USD konsequent als Rückgrat seiner Plattform ein – für industrielle Visualisierung, Simulation, Robotics, Fabrik-Twins, KI-Trainingsumgebungen. Wer in den kommenden Jahren mit Industriekonzernen über digitale Zwillinge spricht, wird Omniverse und USD zunehmend im Raum stehen sehen. Und je größer die Pipeline, je modularer die Zusammenarbeit zwischen Teams und je näher das Thema an Simulation rückt, desto schneller wird USD vom Nice-to-have zum Default.

„OpenUSD ist nicht das nächste Format. Es ist eine andere Denkweise."

Die ehrliche Einordnung lautet trotzdem: OpenUSD ist nicht für jedes Projekt die einfachste Antwort. Die Einführung ist anspruchsvoll, die Lernkurve ist real, und für ein einzelnes Produktrendering ist es schlicht überdimensioniert. Die richtige Haltung heißt daher nicht "Blender oder OpenUSD", sondern: Blender heute produktiv nutzen, OpenUSD dort einsetzen, wo Modularität, Skalierung und Zusammenarbeit den Mehrwert bringen.

Das "Who is who?" der Ausgabeformate

Aus dem zentralen Twin werden Ausgabeformate abgeleitet, immer abhängig vom Zielsystem. glTF und GLB sind der Web-Ausgang. Das Format wurde genau für diesen Zweck entworfen: 3D-Daten effizient übertragen, schnell laden, in Echtzeit darstellen. GLB ist die kompakte binäre Variante, in der Geometrie, Materialien und Texturen in einer einzigen Datei zusammenliegen. Wenn ein Twin im Browser, in einem Konfigurator oder in einer interaktiven Produktpräsentation laufen soll, ist GLB der naheliegende Weg.

USDZ ist der Apple-AR-Ausgang. Wer einen QR-Code scannt und ein Produkt auf seinem Tisch betrachtet, landet im Apple-Ökosystem bei USDZ. Wichtig dabei: Die CAD-Daten werden nicht *zu USDZ*. Sie werden zu einem optimierten Twin – und aus diesem Twin wird die USDZ-Version abgeleitet, parallel zum GLB für Android und Web. Es ist derselbe Datenkern, zwei Ausgänge.

FBX, OBJ, C4D, 3ds verschwinden trotz aller neuen Standards nicht über Nacht. FBX ist in Game Engines wie Unity und Unreal verbreitet, OBJ funktioniert als kleinster gemeinsamer Nenner praktisch überall, und C4D- oder 3ds-Files sind in vielen Produktions-, Werbe- und Architekturpipelines oft noch gesetzt. Eine professionelle Pipeline ist deshalb nicht dogmatisch, sondern lieferfähig – sie leitet aus der sauberen Datenbasis das Format ab, das der jeweilige Partner, Kanal oder Use Case verlangt.

„Es gibt Projekte, bei denen am Ende verschiedene Ausgaben aus einem einzigen Master entstehen – GLB für die Website, USDZ für die AR-Demo, .blend für alle Visuals des Messekatalogs und eine C4D-Datei für die Werbeagentur des Kunden. "

Intern bleibt der native Blender-Stand bzw. die USD-Layerstruktur der eigentliche Master, mit dem sich weiterarbeiten lässt.

Materialien, oder: Wenn Pipelines kippen

Geometrie lässt sich heute meist sauber übertragen. Der ehrliche Stolperstein im Twin-Workflow sind die Materialien. Ein Bauteil kann geometrisch korrekt im Browser landen und trotzdem falsch wirken: Kunststoff zu matt, Metall mit falscher Reflexion, Glas ohne Tiefe, Lack flach. Der Grund liegt nicht in der Geometrie, sondern in der Tatsache, dass Materialien Shaderlogik sind – Lichtverhalten, Reflexion, Rauigkeit, Transparenz, Subsurface Scattering, Anisotropie. Und jedes Zielsystem rechnet diese Logik anders.

Drei Standards prägen die aktuelle Diskussion. PBR beschreibt Materialien anhand physikalisch plausibler Eigenschaften und ist heute der gemeinsame Nenner über fast alle Realtime-Engines hinweg. MaterialX macht ganze Materialnetzwerke system­übergreifend beschreibbar und ist insbesondere im USD-Kontext ein zentraler Baustein. OpenPBR zielt auf ein vereinheitlichtes Materialmodell, das die Wirkung über Renderer und Tools hinweg konsistenter macht.

„Digitale Zwillinge brauchen nicht nur saubere Geometrie. Sie brauchen eine Materialstrategie. Sonst zerfällt der Twin spätestens beim ersten Wechsel des Renderers oder beim Sprung vom Studio-Rendering ins WebGL."

Die eigentliche Leistung liegt im Übersetzen

Für unsere Kunden ist die Botschaft am Ende einfach. Sie liefern, was sie ohnehin haben: ihre Konstruktionsdaten. Wir machen daraus einen sauber strukturierten Visual Twin und leiten daraus die Formate ab, die für ihre Anwendungen und Partner gebraucht werden – ein GLB für den WebGL-Konfigurator, ein USDZ für iPhone- und iPad-AR, ein FBX für Unity oder Unreal, eine .blend für die weitere Produktion, eine C4D- oder 3ds-Datei für bestehende Partner-Workflows und perspektivisch eine OpenUSD-Struktur für skalierbare Konzernpipelines und Omniverse-Szenarien.

Wir verstehen uns dabei als das, was früher ein technisches Zeichenbüro war – nur für die digitale Welt. Ganz oben in der Pyramide der Dienstleister klären wir, welche Visualisierungs­anwendungen ein Kunde wirklich braucht, und liefern den Twin so, dass alle nachgelagerten Agenturen, Studios und Partner damit arbeiten können.

„Wir sind nicht die Lautesten in der Kette. Wir sind die, bei denen sich am Ende entscheidet, ob das, was die Werbeagentur, das Konzern-Marketing oder die IT-Abteilung mit dem Modell anstellen wollen, überhaupt funktionieren kann. Das ist technische Verantwortung, die sich kein Bauchgefühl erlaubt."

Der Visual Twin ist Übersetzungsleistung, kein Dateiexport

Die Zukunft von 3D liegt nicht in einer einzelnen Datei. Sie liegt in einer durchdachten Pipeline. CAD ist der Ausgangspunkt; aus den Konstruktionsdaten entsteht durch Aufbereitung, Optimierung, Strukturierung und Materialarbeit ein nutzbarer Visual Twin. Dieser Twin wird anschließend in genau die Formate übersetzt, die für Web, AR, Rendering, Konfiguratoren, Engines oder Partnerprozesse gebraucht werden.

Heute ist Blender für die meisten Agenturen der produktivste Mittelpunkt – schnell, flexibel, allgegenwärtig. Morgen wird OpenUSD an Bedeutung gewinnen, getragen unter anderem von Nvidias Omniverse, überall dort, wo Skalierung, Modularität und Zusammenarbeit den Ausschlag geben. Die professionelle Antwort lautet daher nicht: ein Format für alles. Sie lautet: eine saubere Datenbasis, eine flexible Pipeline, situative Ausgabeformate.

Aus CAD wird bei DIGITALE kein einzelner Export. Aus CAD wird ein nutzbarer Twin – anschlussfähig für jede relevante digitale Anwendung.