Ein Modell mit 80.000 Bauteilen und bis zu neun Jahren Support: die Erfahrungen von i3 Corps

Das US-Unternehmen i3 Corps, das virtuelle Trainingssysteme für staatliche Auftraggeber in den USA entwickelt, hat erläutert, wie seine 3D-Pipeline aufgebaut ist. Das Unternehmen speichert die Modelle der Fahrzeuge und Luftfahrzeuge getrennt von den Anwendungen über Unity Addressables. Einen eigenen Asset-Katalog hatte es zunächst selbst aufgebaut, dessen Weiterentwicklung dann jedoch eingestellt und stattdessen den Unity Asset Manager in einer staatlichen Cloud ausgerollt. Nun arbeitet i3 Corps gemeinsam mit Unity daran, wie dieser Dienst für Pipelines wie die eigene aussehen sollte.

Die Aufgabenstellung des Unternehmens ist für eine gewöhnliche 3D-Produktion ungewöhnlich. Ein Modell ist hier der digitale Zwilling realer Technik, und mit der Veröffentlichung der Anwendung endet die Arbeit daran nicht. Die Betreuung eines einzelnen Modells kann acht bis neun Jahre dauern, und pro Jahr kommen zehn bis fünfzehn neue hinzu. Von ihren Erfahrungen berichteten Marketingleiter Daniel Starkey und Systemarchitekt John Thornton in einem Gastbeitrag im Unity-Blog vom 10. November 2026.

Ein Asset, das das Beschaffungsprogramm überdauert

In Unity hat das Unternehmen Hunderte von Trainingsszenarien erstellt. Sie decken den Großteil der Flugausbildung ab, die i3 Corps unterstützt, sowie Plattformen der Marine und Landfahrzeuge. In die Schulungsräume auf Militärstandorten im ganzen Land gelangen die Anwendungen über eine Distributionsplattform. Diese hat i3 Corps selbst aufgebaut, sie gehört dem Staat und läuft in einer gesicherten staatlichen Cloud.

Das Schwierigste liegt den Autoren zufolge unterhalb der Anwendungen, in der 3D-Bibliothek. Die Technik verändert sich ständig: Eine neue Komponente wird eingeführt, der Hersteller überarbeitet ein Bauteil, der Auftraggeber schickt ein aktuelles CAD-Paket. Jedes Mal muss jemand herausfinden, welche Teile ersetzt werden, welches Modell davon betroffen ist und welche Anwendungen in den Schulungsräumen davon abhängen.

«Eines unserer Luftfahrzeugmodelle umfasst 80.000 Komponenten – bis hin zu Muttern und Schrauben».
— Daniel Starkey und John Thornton, i3 Corps

Dasselbe gilt für die Ausgangsdaten. Die Modelle werden aus CAD-Paketen unterschiedlicher Herkunft und aus eigener Fotogrammetrie zusammengesetzt. Eine einzige Aufnahmereise kann Millionen Fotos eines Fahrzeugs liefern. Einige Jahre später kommt ein neues CAD zur selben Plattform, und man muss nachvollziehen, woraus das alte Modell entstanden ist, um beide zu vergleichen. Die Autoren schreiben, dass eine solche Antwort leicht verloren geht und ihre Wiederherstellung teuer ist. Dabei werden die Assets über Jahre von zehn Art-Teams bearbeitet – wöchentlich, manchmal täglich.

Eine Zelle, viele Hubschrauber

Den Maßstab veranschaulichen die Autoren am UH-60 Black Hawk. Allein die US Army verfügt über UH-60A, L, M und V, den Sanitätshubschrauber HH-60M sowie Spezialmaschinen für die Spezialeinsatzkräfte und weitere Aufgaben. Nimmt man Marine, Luftwaffe und ausländische Betreiber hinzu, wächst die Zahl der Konfigurationen für die Ausbildung rasch. Die meisten von ihnen nutzen denselben Rumpf, denselben Heckausleger, dasselbe Rotorsystem und dasselbe Fahrwerk. Der UH-60V behält den Großteil der Zelle der Variante L und erhält ein digitales Cockpit. Der HH-60M baut auf dem UH-60M mit medizinischer Ausrüstung und Zielsystemen auf.

Modelliert man jede Version von Grund auf neu, müssen dieselben Bauteile immer wieder neu erstellt, geprüft und gepflegt werden. Deshalb hält i3 Corps ein gemeinsames Basismodell aus wiederverwendbaren Komponenten für den richtigen Ansatz, bei dem jede Variante nur das hinzufügt, worin sie sich tatsächlich unterscheidet: Struktur, mechanische Systeme, Avionik oder Zielausrüstung.

Modelle außerhalb des Builds, Katalog in der Cloud

Um die Modelle nicht in den Anwendungen selbst vorzuhalten, nutzt das Unternehmen Unity Addressables. Die Modelle liegen getrennt vom Build in einem Katalog, werden bei Bedarf nachgeladen und lokal zwischengespeichert. Ein Asset, auf das fünfzehn Anwendungen verweisen, wird nur einmal gespeichert, und die Anwendungen selbst müssen nur dann geändert werden, wenn sich ihr Code ändert.

Für die Verwaltung der Assets selbst ging man zunächst einen eigenen Weg: Auf Basis der Versionskontrolle und der Automatisierung begann man, eine Datenbank und eine Suche aufzubauen. Diesen Katalog weiterzuentwickeln gab man letztlich auf und rollte den Unity Asset Manager in einer staatlichen Cloud-Umgebung aus.

Was der Dienst kann, zeigt seine Dokumentation. Die Versionen eines Assets werden linear geführt, die benötigte Version lässt sich mit einem Label für eine bestimmte Pipeline markieren, und die Versionen unterteilen sich in eingefrorene und bearbeitbare. Verschiedene Teams können dasselbe Asset in unterschiedlichen Projekten verwenden und verändern, ohne sich gegenseitig zu stören. Abhängigkeiten verknüpfen etwa ein Prefab mit seiner FBX-Datei und den Materialien, sodass ein Kollege alles gemeinsam importiert. Am 16. Juli 2026 erschien in der Webversion ein interaktiver Abhängigkeitsgraph. Er hilft dabei, komplexe Strukturen wie Baugruppen zu durchdringen und zu verstehen, welche Assets eine Änderung betrifft. Gleichzeitig wurde die hierarchische Ansicht mehrteiliger Assets überarbeitet. Seit Mai 2026 werden optimierte und konvertierte Kopien als separate verknüpfte Assets angelegt und ändern die Version des Originals nicht.

Es gibt auch automatische Metadaten: Beim Hochladen eines Modells zählt der Dienst selbst Dreiecke, Vertices, Materialien und Texturen, die maximale Texturgröße und die Zahl einzelner Objekte. Er erkennt zudem, ob ein Rig, eine Animation und UVs vorhanden sind. Eigene Felder lassen sich als Text-, Boolesche, numerische Felder sowie als Feld mit Link, Nutzer oder Datum anlegen.

Wo der Dienst bislang nicht passt

Das Unternehmen hat einen eigenen Artikel darüber angekündigt, wo der Asset Manager bislang nicht zu seiner Pipeline passt und was es gemeinsam mit Unity entwickelt, um diese Lücke zu schließen. Außerdem wird i3 Corps vom 30. November bis 3. Dezember auf der I/ITSEC 2026 in Orlando vertreten sein, Stand #1761.

Im größeren Rahmen sehen es die Autoren so: Der Staat hat gewaltige Mengen an CAD- und parametrischen Modellen angesammelt. Vieles wurde vor Jahren im Rahmen von Verträgen abgeliefert, und diese Daten heute zu finden, ist praktisch unmöglich. Die Nachfrage verschiebt sich ihrer Einschätzung nach hin zu Simulation, Visualisierung und Content-Erzeugung mit Hilfe von KI.

Was daraus für Studios folgt

Stellt man die Anforderungen von i3 Corps der Dokumentation des Asset Manager gegenüber, werden Schwachstellen sichtbar. In der Weboberfläche werden Abhängigkeiten über einen Bearbeitungsmodus hinzugefügt und nur in eine Richtung, abwärts in der Kette; beim Hochladen aus dem Unity-Editor lassen sich Abhängigkeiten automatisch als separate Assets ausgeben. Für eine Baugruppe mit 80.000 Teilen bedeutet das ohne solche Automatisierung viel Handarbeit. Der Graph zeigt, was eine Änderung betrifft, doch einen fertigen Vergleich «was hat sich zwischen den Versionen auf Bauteilebene geändert» gibt es in der Funktionsbeschreibung nicht – und genau diese Aufgabe nennen die Autoren als nächste. Einheiten in numerischen Feldern rechnet der Dienst nicht um, sie müssen im Feldnamen vermerkt werden.

Auch bei der Lizenzierung gibt es Fragen. Asset-Manager-Plätze sind in allen Unity-Plänen enthalten, doch alle Rollen in Organisationen der Stufen Enterprise und Industry stehen nur mit Enterprise- oder Industry-Floating-Plätzen zur Verfügung. Der Collaborate-Platz ist dort auf die Consumer-Rolle beschränkt. Bei einer Höherstufung der Organisation werden Plätze, die nicht auf die neue Stufe umgestellt wurden, auf Leserechte reduziert. Preise finden sich auf der Seite zu den Plätzen nicht. In der öffentlichen Dokumentation ließ sich auch keine Beschreibung dazu finden, worin sich die Variante für die staatliche Cloud von der regulären unterscheidet und wie ein aktualisiertes Modell zu einer alten Kopie im Cache eines Schulungsraum-Rechners gelangt.

Dieselben Probleme dürften allen vertraut sein, deren Assets länger leben als ein einzelnes Projekt: der Industrievisualisierung, der Architekturvisualisierung mit mehrjährigen Objekten, Studios, die eine gemeinsame Fahrzeugdatenbank für mehrere Spiele pflegen. Für sie könnte die angekündigte Analyse der Einschränkungen nützlicher sein als der jetzige Beitrag.

Warum hat i3 Corps den eigenen Katalog zugunsten des Asset Manager aufgegeben: teure Pflege des eigenen Codes, Anforderungen der staatlichen Cloud, die Aussicht auf Einfluss bei Unity?