10 équipes, 3 programmes et 7 ans : Gestion efficace des actifs 3D dans la formation de défense

Cet article invité provient de Daniel Starkey, Directeur Marketing, et de John Thornton, Architecte Systèmes, chez i3 Corps. Ils construisent des outils de formation virtuelle et de productivité d'ingénierie pour les clients du gouvernement américain, et ici Daniel et John expliquent ce qu'une décennie de Digital Twins militaires fait pour un pipeline d'actifs 3D.

i3 Corps développe des outils de formation virtuelle et de productivité d'ingénierie pour les clients gouvernementaux. Au fil des ans, nous avons développé des centaines de scénarios de formation dans Unity, couvrant la plupart des formations aéronautiques que nous soutenons, ainsi que les plateformes de la Marine et les véhicules terrestres. Ces applications atteignent les salles de classe sur les installations militaires à travers le pays grâce à une plateforme de distribution détenue par le gouvernement que nous avons construite, fonctionnant dans un cloud gouvernemental sécurisé.

Les applications sont la partie visible. La partie difficile se trouve en dessous, dans la bibliothèque 3D, et presque aucun des conseils standards sur les pipelines d'actifs ne s'applique.

Un modèle qui survit au programme qui l'a acheté

Dans la plupart des travaux en 3D, un actif est terminé lorsque le produit est expédié.

Nos modèles sont des Digital Twins des équipements physiques, et l'équipement physique continue de changer. Un nouveau composant entre en service. Un fabricant révise une pièce. Un client envoie un nouveau paquet CAD, et le modèle doit l'absorber. L'un de nos modèles d'avion comporte 80 000 composants, jusqu'aux écrous et boulons. Nous ajoutons dix à quinze nouveaux modèles par an, et chacun d'eux commence une relation de maintenance qui peut durer huit ou neuf ans.

Cela crée un problème que la plupart des pipelines n'ont jamais à résoudre. Quand de nouvelles données d'ingénierie arrivent, quelqu'un doit déterminer ce que cela change. Quelles parties remplace-t-il ? Quel modèle existant met-il à jour ? Quelles des applications déjà présentes dans les salles de classe dépendent de ce modèle, et qu'arrive-t-il à elles ?

Les données de référence se composent de la même manière. Nos modèles sont construits à partir de paquets CAO provenant de différentes sources et nous nous capturons par photogrammétrie. Un seul trajet de capture peut produire des millions de photographies d'un véhicule. Des années plus tard, lorsque de nouveaux CAO arrivent pour la même plateforme, vous devez savoir d'où vient le modèle original, afin de pouvoir comparer les deux. Cette réponse est facile à perdre et coûteuse à reconstruire.

Même cellule, différents avions

Prenez le UH-60 Black Hawk. L'armée américaine seule fait voler une longue liste de versions : le UH-60A, L, M et V, le HH-60M MEDEVAC, et des avions spécialisés pour les opérations spéciales et d'autres missions. Ajoutez la Marine, l'Armée de l'Air et les opérateurs internationaux, et le nombre de configurations sur lesquelles quelqu'un doit se former augmente rapidement.

Chacun d'eux est une cible d'entraînement légitime, mais ce ne sont pas des avions séparés. La plupart partagent le même fuselage, le même mât de queue, les mêmes ensembles de rotors et le même train d'atterrissage. Le UH-60V conserve la majeure partie du fuselage du L et ajoute un cockpit numérique. Le HH-60M MEDEVAC est construit sur le UH-60M, avec l'ajout d'équipement médical et de systèmes de mission.

Modéliser chacun à partir de zéro, c'est reconstruire, réévaluer et maintenir les mêmes parties encore et encore. La meilleure approche est une base commune construite à partir de composants réutilisables, où chaque variante n'ajoute que ce qui est réellement différent : structure, systèmes mécaniques, avionique ou équipement de mission.

Le dernier kilomètre est un ordinateur de dix ans

Les logiciels grand public gèrent la pression de stockage en l'ignorant. Il télécharge des dizaines de gigaoctets et vous demande de supprimer autre chose pour faire de la place.

Nous ne pouvons pas faire cela. Nos applications se retrouvent sur des machines gouvernementales qui peuvent être anciennes, comportent des contrôles de sécurité importants et ont des limites strictes sur l'espace que quiconque peut utiliser. Une machine de classe pourrait contenir tous les cours de formation que nous avons jamais créés pour cette plateforme. Compilé de la manière conventionnelle, avec des modèles intégrés dans chaque application, ce sont des centaines de gigaoctets de géométrie largement identique.

Nous utilisons Unity Addressables pour éviter cela. Les modèles vivent dans un catalogue plutôt que dans la construction, ils sont tirés à la demande et sont mis en cache localement. La déduplication est par défaut plutôt qu'une optimisation, car un actif référencé par quinze applications est stocké une seule fois. Les applications n'ont besoin de changer que lorsque leur code change. Cela signifie également qu'un développeur n'a pas besoin de la bibliothèque entière sur une seule machine pour assembler une scène.

La sécurité est également un facteur critique. Le matériel classifié ne touche jamais le cloud, les informations non classifiées contrôlées (CUI) le peuvent, mais il doit être emballé pour que personne ne puisse ouvrir le modèle sur la machine et le emporter. Savoir dans quelle catégorie un actif se classe, de manière fiable et en un coup d'œil, n'est pas une charge administrative. Il détermine où l'actif est autorisé à exister.

Une question connexe surgit constamment et n'a rien à voir avec la sécurité : à qui cela appartient-il ? Certains actifs sont une propriété i3, et d'autres sont une propriété gouvernementale, et la distinction détermine si nous pouvons réutiliser un actif dans le contrat suivant, ou le référencer dans une proposition.

Pourquoi nous avons arrêté de construire notre propre catalogue

Nous avions commencé à en construire un.

Pendant longtemps, il n'y a pas eu d'option de cloud gouvernemental pour ce type d'outillage, nous avons donc sondé les plateformes de gestion d'actifs commerciales et nous sommes tombés sur les mêmes deux problèmes : soit l'outil ne correspondait pas à la manière dont nos données fonctionnent, soit le modèle de licence le rendait impraticable pour l'utilisation gouvernementale . Nous avons donc commencé à assembler le nôtre, en superposant une base de données et une recherche sur notre Version Control et notre automatisation existantes.

Ça a marché, jusqu'à un certain point. Nous pourrions trouver des actifs. Ce que nous n'avons pas pu justifier, c'était le reste : l'intégration du moteur, l'automatisation du pipeline, le suivi des dépendances, et ensuite maintenir tout cela indéfiniment.

Ce n'est pas notre affaire. Nous fournissons des formations et des solutions d'ingénierie aux clients gouvernementaux, et une chaîne d'outils que nos artistes et développeurs peuvent utiliser sans quitter Unity nous vaut plus que un système sur mesure que nous devrions maintenir nous-mêmes.

C'est pourquoi nous avons déployé Unity Asset Manager dans un environnement cloud gouvernemental, et pourquoi nous travaillons maintenant avec Unity sur ce qu'il doit devenir pour des pipelines comme le nôtre.

Ce que nous résolvons ensuite

Cataloguer les actifs terminés est la première étape, et cela répond déjà aux questions que nous avions l'habitude de poser en demandant autour de nous. Qu'avons-nous modélisé ? Où est-ce que c'est utilisé ? Est-ce contrôlé ? À qui appartient-il ?

Le problème le plus difficile est la volatilité. Notre catalogue n'est pas une étagère de travaux finis. Dix équipes artistiques changent des actifs chaque semaine, parfois quotidiennement, pendant des années, et chaque changement se répercute sur de longues chaînes de dépendances construites pour des animations de maintenance complexes. Gérer cela correctement signifie dire aux artistes précisément ce qui a changé, plutôt que de tout annuler en aval.

C'est le travail qui nous attend, et nous en parlerons au fur et à mesure, y compris les parties qui ne sont pas encore résolues.

Il y a une raison plus importante de le faire correctement. Le gouvernement possède d'énormes quantités de données CAD et de modèles paramétriques, dont beaucoup ont été livrées sous contrat il y a des années et sont désormais pratiquement introuvables. Pendant ce temps, la demande passe de la formation seule à la simulation, à la visualisation et à la génération de contenu assistée par IA, le tout nécessitant une bibliothèque consultable de données 3D précises en arrière-plan. Un modèle n'est utile que si vous pouvez le trouver. De plus en plus, ce n'est utile que si une machine peut le trouver aussi.

Dans un prochain article, nous détaillerons ce travail, y compris les domaines où Unity Asset Manager ne s'intègre pas encore à un pipeline comme le nôtre et ce que nous et Unity construisons ensemble pour combler cette lacune.

Nous serons également à I/ITSEC 2026 in Orlando, du 30 novembre au 3 décembre, stand n°1761. Venez nous trouver.