Wie ein Studio für militärische Trainingssimulatoren seit Jahrzehnten 3D-Digital-Twins in Unity pflegt

i3 Corps entwickelt virtuelle Trainingssysteme und Werkzeuge für Ingenieure im Auftrag von US-Regierungsbehörden. Das Unternehmen hat in Unity Hunderte von Trainingsszenarien erstellt: Sie decken den Großteil der von ihm unterstützten Flugausbildung ab, außerdem Schiffe der Navy und Bodenfahrzeuge. In die Unterrichtsräume auf Militärstützpunkten gelangen die Anwendungen über eine staatliche Vertriebsplattform, die das Unternehmen selbst aufgebaut hat und die in einer gesicherten Regierungscloud läuft. Die eigentliche Komplexität steckt jedoch nicht in den Anwendungen, sondern darunter: in der 3D-Bibliothek.

In der üblichen 3D-Entwicklung gilt ein Asset als fertig, sobald das Produkt ausgeliefert ist. Hier ist alles anders: Die Modelle sind Digital Twins realer Ausrüstung, und diese Ausrüstung verändert sich ständig. Neue Komponenten werden in Dienst gestellt, Hersteller überarbeiten Teile, Kunden schicken neue CAD-Datenpakete. Das Modell eines einzigen Flugzeugs umfasst 80.000 Komponenten, bis hin zu Muttern und Schrauben. Das Team fügt jedes Jahr zehn bis fünfzehn Modelle hinzu, und jedes davon wird anschließend acht bis neun Jahre lang gepflegt. Mit jeder neuen Lieferung technischer Daten stellen sich dieselben Fragen: Welche Teile ersetzt sie, welches Modell aktualisiert sie und welche bereits ausgerollten Anwendungen hängen von diesem Modell ab? Auch die Herkunft spielt eine Rolle: Die Modelle entstehen aus CAD-Daten verschiedener Quellen und aus eigener Photogrammetrie, wobei eine einzige Aufnahmereise Millionen von Fotos eines einzigen Fahrzeugs liefern kann.

Varianten vervielfachen das Problem. Den UH-60 Black Hawk gibt es in den Heeresversionen UH-60A, L, M und V, als Sanitätsvariante HH-60M MEDEVAC und in Ausführungen für Spezialkräfte, dazu kommen Konfigurationen für Navy, Air Force und internationale Kunden. Die meisten teilen sich Rumpf, Heckausleger, Rotorbaugruppen und Fahrwerk. Der UH-60V übernimmt weitgehend die Zelle der L-Version, hat aber ein digitales Cockpit erhalten, und der HH-60M ist ein UH-60M mit zusätzlichen medizinischen und Missionssystemen. Deshalb wird nicht jede Variante von Grund auf neu modelliert: Man nutzt eine gemeinsame Basis aus wiederverwendbaren Komponenten, und für jede Variante kommen nur die Unterschiede hinzu, sei es in der Struktur, den mechanischen Systemen, der Avionik oder der Missionsausrüstung.

Eine weitere harte Einschränkung ist der Speicherplatz. Behördenrechner sind oft älter, stark abgesichert und haben begrenzten Festplattenplatz, und doch können auf einem einzigen Schulungs-PC alle Kurse für eine Plattform installiert sein. Wären die Modelle in jeden Build eingebettet, kämen Hunderte Gigabyte nahezu identischer Geometrie zusammen. Unity Addressables löst dieses Problem: Die Modelle liegen in einem Katalog, werden bei Bedarf geladen und lokal zwischengespeichert, sodass ein Asset, das fünfzehn Anwendungen nutzen, nur einmal gespeichert wird. Eine Anwendung ändert sich nur, wenn sich ihr Code ändert, und Entwickler müssen nicht die gesamte Bibliothek lokal vorhalten, um eine Szene zusammenzustellen. Die Geheimhaltungsstufe bestimmt, wo ein Asset liegen darf: Als geheim eingestuftes Material gelangt nie in die Cloud, CUI dagegen schon, allerdings in einer geschützten Hülle, damit es nicht extrahiert werden kann. Ob ein Modell i3 oder dem Staat gehört, entscheidet darüber, ob es in künftigen Aufträgen wiederverwendet werden darf.

Kommerzielle Plattformen für das Asset-Management passten entweder nicht zu diesem Datenmodell oder wurden zu Lizenzbedingungen angeboten, die für öffentliche Aufträge unpraktikabel waren, und eine Option für die Government Cloud gab es überhaupt nicht. Ein selbst entwickeltes System, also Datenbank und Suche auf Basis der vorhandenen Versionskontrolle und Automatisierung, half zwar beim Auffinden von Assets, doch Engine-Integration, Pipeline-Automatisierung, Abhängigkeitsverfolgung und unbefristete Wartung ließen sich damit nicht mehr rechtfertigen. Deshalb hat das Unternehmen Unity Asset Manager in einer Government-Cloud-Umgebung bereitgestellt, sodass Artists und Entwickler Unity nicht verlassen müssen. Schon jetzt beantwortet der Katalog die Fragen: Was wurde modelliert, wo wird es verwendet, unterliegt es Zugriffsbeschränkungen und wem gehört es.

Ungelöst bleibt die Volatilität: Zehn Art-Teams ändern Assets jede Woche oder sogar täglich, und jede Änderung pflanzt sich durch lange Abhängigkeitsketten fort, auf denen komplexe Wartungsanimationen aufbauen. Ziel ist es, Artists genau mitzuteilen, was sich geändert hat, statt alles Nachgelagerte neu zu versionieren. Daran arbeitet i3 Corps gemeinsam mit Unity. Und es steht noch mehr auf dem Spiel: Der Staat verfügt über riesige Mengen an CAD- und parametrischen Daten, in denen praktisch nichts auffindbar ist, während sich die Nachfrage hin zu Simulation, Visualisierung und KI-gestützter Content-Generierung verschiebt. Dafür braucht es eine durchsuchbare Bibliothek, die auch Maschinen abfragen können.