10 equipos, 3 programas y 7 años: Gestión eficiente de activos 3D en entrenamiento de defensa

Esta publicación de invitado proviene de Daniel Starkey, Director de Marketing, y John Thornton, Arquitecto de Sistemas, de i3 Corps. Construyen herramientas virtuales de capacitación y productividad de ingeniería para clientes del gobierno de EE. UU., y aquí Daniel y John explican lo que una década de Digital Twins militares hace a una tubería de activos 3D.

i3 Corps desarrolla herramientas virtuales de capacitación y productividad de ingeniería para clientes gubernamentales. A lo largo de los años hemos desarrollado cientos de escenarios de entrenamiento en Unity, cubriendo la mayor parte de la formación de aviación que apoyamos, junto con plataformas de la Marina y vehículos terrestres. Esas aplicaciones llegan a las aulas en instalaciones militares de todo el país a través de una plataforma de distribución propiedad del gobierno que construimos, que se ejecuta en una nube gubernamental segura.

Las aplicaciones son la parte visible. La parte difícil está debajo de ellos, en la biblioteca 3D, y casi ninguno de los consejos estándar sobre tuberías de activos se aplica.

Un modelo que sobrevive al programa que lo compró

En la mayoría del trabajo 3D, un activo está terminado cuando el producto se envía.

Nuestros modelos son Digital Twins de equipos físicos, y el equipo físico sigue cambiando. Un nuevo componente entra en servicio. Un fabricante revisa una pieza. Un cliente envía un paquete CAD nuevo y el modelo tiene que absorberlo. Uno de nuestros modelos de aeronave funciona con 80,000 componentes, hasta los tornillos y tuercas. Añadimos diez a quince modelos nuevos al año, y cada uno inicia una relación de mantenimiento que puede durar ocho o nueve años.

Eso crea un problema que la mayoría de las tuberías nunca tienen que resolver. Cuando llega nuevo dato de ingeniería, alguien tiene que averiguar qué cambia. ¿Qué partes reemplaza? ¿Qué modelo existente actualiza? ¿Qué aplicaciones que ya están en las aulas dependen de ese modelo y qué les pasa?

Los datos de referencia se componen de la misma manera. Nuestros modelos se construyen a partir de paquetes CAD de diferentes fuentes y de la fotogrametría nos capturamos a nosotros mismos. Un solo viaje de captura puede producir millones de fotografías de un vehículo. Años más tarde, cuando llegue un nuevo CAD para la misma plataforma, necesitas saber de dónde vino el modelo original, para poder comparar los dos. Esa respuesta es fácil de perder y costosa de reconstruir.

Mismo fuselaje, avión diferente

Toma el UH-60 Black Hawk. El Ejército de EE. UU. solo vuela una larga lista de versiones: el UH-60A, L, M y V, el HH-60M MEDEVAC, y aeronaves especializadas para operaciones especiales y otras misiones. Añadir la Marina, la Fuerza Aérea y los operadores internacionales, y el número de configuraciones en las que alguien necesita entrenar crece rápido.

Cada uno de ellos es un objetivo de entrenamiento legítimo, pero no son aviones separados. La mayoría comparten el mismo fuselaje, estabilizador de cola, conjuntos de rotor y tren de aterrizaje. El UH-60V mantiene gran parte del fuselaje del L y añade una cabina digital. El HH-60M MEDEVAC se construye sobre el UH-60M, con equipo médico y sistemas de misión añadidos.

Modela cada uno desde cero y estás reconstruyendo, revalidando y manteniendo las mismas partes una y otra vez. El mejor enfoque es una línea base común construida a partir de componentes reutilizables, donde cada variante añade solo lo que es realmente diferente: estructura, sistemas mecánicos, aviónica o equipo de misión.

La última milla es una computadora de diez años

El software de consumo trata la presión de almacenamiento ignorándola. Descarga decenas de gigabytes y espera que borres otra cosa para hacer espacio.

No podemos hacer eso. Nuestras aplicaciones aterrizan en máquinas gubernamentales que pueden ser antiguas, tener controles de seguridad significativos y tener límites estrictos sobre cuánto espacio puede usar cualquiera. Una máquina de aula podría contener todos los cursos de capacitación que hayamos construido para esa plataforma. Compilado de la manera convencional, con modelos integrados en cada aplicación, que son cientos de gigabytes de geometría en gran parte idéntica.

Usamos Unity Addressables para evitar eso. Los modelos viven en un catálogo en lugar de dentro de la compilación, se extraen bajo demanda y se almacenan en caché localmente. La deduplicación es el valor predeterminado en lugar de una optimización, porque un activo referenciado por quince aplicaciones se almacena una sola vez. Las aplicaciones solo necesitan cambiar cuando su código cambia. También significa que un desarrollador no necesita la biblioteca completa en una sola máquina para ensamblar una escena.

La seguridad también es un factor crítico. El material clasificado nunca toca la nube, la Información No Clasificada Controlada (CUI) sí puede, pero necesita estar envuelta para que nadie pueda abrir el modelo en la máquina y llevárselo. Saber en qué categoría se clasifica un activo, de manera fiable y de un vistazo, no es una carga administrativa. Determina dónde se permite que exista el activo.

Surge una pregunta relacionada constantemente y no tiene nada que ver con la seguridad: ¿quién es el dueño de esto? Algunos activos son propiedad de i3 y otros son propiedad del gobierno, y la distinción determina si podemos reutilizar un activo en el próximo contrato o referenciarlo en una propuesta.

Por qué dejamos de construir nuestro propio catálogo

Habíamos empezado a construir uno.

Durante mucho tiempo no hubo una opción de nube gubernamental para este tipo de herramientas, así que encuestamos las plataformas comerciales de gestión de activos y seguimos encontrando los mismos dos problemas: o la herramienta no se adaptaba a cómo funcionaban nuestros datos, o el modelo de licencia lo hacía poco práctico para el uso gubernamental . Así que comenzamos a ensamblar el nuestro, añadiendo una base de datos y búsqueda sobre nuestro Version Control y automatización existentes.

Funcionó, hasta cierto punto. Podríamos encontrar activos. Lo que no pudimos justificar fue el resto: la integración del motor, la automatización de la tubería, el seguimiento de dependencias y luego mantenerlo todo indefinidamente.

Eso no es nuestro negocio. Ofrecemos soluciones de capacitación e ingeniería a clientes gubernamentales, y una cadena de herramientas que nuestros artistas y desarrolladores puedan usar sin salir de Unity nos vale más que un sistema personalizado que tendríamos que mantener nosotros mismos.

Por eso implementamos Unity Asset Manager en un entorno de nube gubernamental, y por eso ahora estamos trabajando con Unity en lo que necesita llegar a ser para pipelines como las nuestras.

Lo que resolveremos a continuación

Catalogar los activos terminados es el primer paso, y ya responde a preguntas que solíamos responder preguntando a la gente. ¿Qué hemos modelado? ¿Dónde se usa? ¿Está controlado? ¿Quién lo posee?

El problema más difícil es la volatilidad. Nuestro catálogo no es un estante de obras terminadas. Diez equipos de arte cambian activos semanalmente, a veces diariamente, durante años, y cada cambio se propaga a través de largas cadenas de dependencia construidas para animaciones de mantenimiento complejas. Gestionar eso bien significa decirle a los artistas exactamente qué cambió, en lugar de revertir todo lo que está aguas abajo.

Ese es el trabajo que tenemos por delante, y escribiremos sobre él a medida que avancemos, incluyendo las partes que aún no están resueltas.

Hay una razón más grande para hacerlo bien. El gobierno posee enormes cantidades de datos CAD y de modelos paramétricos, gran parte de ellos entregados bajo contrato hace años y ahora efectivamente irrecuperables. Mientras tanto, la demanda está cambiando de solo entrenamiento hacia simulación, visualización y generación de contenido asistida por IA, todo lo cual necesita una biblioteca de datos 3D precisos y buscables en su base. Un modelo solo es útil si puedes encontrarlo. Cada vez más, solo es útil si una máquina también puede encontrarlo.

En un próximo artículo seremos específicos sobre ese trabajo, incluyendo dónde Unity Asset Manager aún no encaja en un flujo de trabajo como el nuestro y lo que nosotros y Unity estamos construyendo juntos para cerrar la brecha.

También estaremos en I/ITSEC 2026 en Orlando, del 30 de noviembre al 3 de diciembre, stand #1761. Ven a encontrarnos.