10 equipes, 3 programas e 7 anos: Gerenciamento eficiente de ativos 3D em treinamento de defesa

Este post de convidado é de Daniel Starkey, Diretor de Marketing, e John Thornton, Arquiteto de Sistemas, da i3 Corps. Eles constroem ferramentas virtuais de treinamento e produtividade de engenharia para clientes do governo dos EUA, e aqui Daniel e John explicam o que uma década de Digital Twins militares faz em um pipeline de ativos 3D.

i3 Corps constrói ferramentas de treinamento virtual e produtividade de engenharia para clientes governamentais. Ao longo dos anos, desenvolvemos centenas de cenários de treinamento no Unity, cobrindo a maior parte do treinamento de aviação que apoiamos, juntamente com plataformas navais e veículos terrestres. Esses aplicativos chegam às salas de aula em instalações militares em todo o país através de uma plataforma de distribuição de propriedade do governo que construímos, rodando em uma nuvem governamental segura.

Os aplicativos são a parte visível. A parte difícil fica por baixo deles, na biblioteca 3D, e quase nenhum dos conselhos padrão sobre pipelines de ativos se aplica.

Um modelo que sobrevive ao programa que o comprou

Na maioria dos trabalhos 3D, um ativo está finalizado quando o produto é enviado.

Nossos modelos são Digital Twins de equipamentos físicos, e o equipamento físico continua mudando. Um novo componente entra em serviço. Um fabricante revisa uma peça. Um cliente envia um pacote CAD novo, e o modelo tem que absorvê-lo. Um dos nossos modelos de aeronave tem 80.000 componentes, até os parafusos e porcas. Adicionamos dez a quinze novos modelos por ano, e cada um inicia um relacionamento de manutenção que pode durar oito ou nove anos.

Isso cria um problema que a maioria dos pipelines nunca precisa resolver. Quando novos dados de engenharia chegam, alguém tem que descobrir o que eles mudam. Quais partes ele substitui? Qual modelo existente ele atualiza? Quais das aplicações já nas salas de aula dependem desse modelo e o que acontece com elas?

Os dados de referência se compõem da mesma maneira. Nossos modelos são construídos a partir de pacotes CAD de diferentes fontes e, a partir de fotogrametria, nós mesmos capturamos. Uma única viagem de captura pode produzir milhões de fotografias de um veículo. Anos depois, quando um novo CAD chegar para a mesma plataforma, você precisa saber de onde veio o modelo original, para que possa comparar os dois. Essa resposta é fácil de perder e cara de reconstruir.

Mesmo fuselagem, aeronaves diferentes

Pegue o UH-60 Black Hawk. O Exército dos EUA sozinho opera uma longa lista de versões: o UH-60A, L, M e V, o HH-60M MEDEVAC e aeronaves especializadas para operações especiais e outras missões. Adicionar a Marinha, a Força Aérea e operadores internacionais, e o número de configurações em que alguém precisa ser treinado cresce rapidamente.

Cada um deles é um alvo de treinamento legítimo, mas não são aeronaves separadas. A maioria compartilha o mesmo fuselagem, cauda, conjuntos de rotor e trem de pouso. O UH-60V mantém grande parte da fuselagem do L e adiciona uma cabine digital. O HH-60M MEDEVAC é construído sobre o UH-60M, com equipamentos médicos e sistemas de missão adicionados.

Modele cada um do zero e você está reconstruindo, revalidando e mantendo as mesmas partes repetidamente. A abordagem melhor é uma linha de base comum construída a partir de componentes reutilizáveis, onde cada variante adiciona apenas o que é realmente diferente: estrutura, sistemas mecânicos, aviônicos ou equipamento de missão.

A última milha é um computador de dez anos

Software de consumo lida com a pressão de armazenamento ignorando-a. Ele baixa dezenas de gigabytes e espera que você apague outra coisa para liberar espaço.

Nós não podemos fazer isso. Nossas aplicações chegam em máquinas governamentais que podem ser mais antigas, possuir controles de segurança significativos e ter limites firmes sobre quanto espaço qualquer pessoa pode usar. Uma máquina de sala de aula pode conter todos os cursos de treinamento que já construímos para essa plataforma. Compilado da maneira convencional, com modelos incorporados em cada aplicação, que são centenas de gigabytes de geometria em grande parte idêntica.

Usamos Unity Addressables para evitar isso. Os modelos vivem em um catálogo em vez de dentro da compilação, são puxados sob demanda e são armazenados em cache localmente. A desduplicação é o padrão em vez de uma otimização, porque um ativo referenciado por quinze aplicações é armazenado uma vez. As aplicações só precisam mudar quando o seu código muda. Também significa que um desenvolvedor não precisa da biblioteca inteira em uma máquina para montar uma cena.

Segurança também é um fator crítico. Material classificado nunca toca a nuvem, Informação Não Classificada Controlada (CUI) pode, mas precisa ser encapsulada para que ninguém possa abrir o modelo na máquina e sair com ele. Saber em qual categoria um ativo se enquadra, de forma confiável e de relance, não é um custo administrativo. Ele determina onde o ativo pode existir.

Uma pergunta relacionada surge constantemente e não tem nada a ver com segurança: quem é o dono disso? Alguns ativos são propriedade da i3, e outros são propriedade do governo, e a distinção determina se podemos reutilizar um ativo no próximo contrato ou referenciá-lo em uma proposta.

Por que paramos de construir nosso próprio catálogo

Nós começamos a construir um.

Por muito tempo não havia opção de nuvem governamental para esse tipo de ferramenta, então pesquisamos as plataformas comerciais de gerenciamento de ativos e continuamos encontrando os mesmos dois problemas: ou a ferramenta não se encaixava em como nossos dados realmente funcionavam, ou o modelo de licenciamento tornava-o impraticável para uso governamental . Então começamos a montar o nosso próprio, adicionando um banco de dados e busca sobre o nosso Version Control e automação existentes.

Funcionou, até certo ponto. Nós poderíamos encontrar ativos. O que não conseguimos justificar foi o resto: a integração do motor, a automação do pipeline, o rastreamento de dependências e, em seguida, mantê-los indefinidamente.

Isso não é nosso negócio. Nós fornecemos treinamento e soluções de engenharia para clientes governamentais, e uma cadeia de ferramentas que nossos artistas e desenvolvedores podem usar sem sair do Unity vale mais para nós do que um sistema personalizado que teríamos que manter vivos nós mesmos.

É por isso que implantamos Unity Asset Manager em um ambiente de nuvem governamental, e por isso estamos trabalhando com a Unity sobre o que ela precisa se tornar para pipelines como o nosso.

O que estamos resolvendo a seguir

Catalogar ativos finalizados é o primeiro passo e já responde a perguntas que costumávamos responder perguntando por aí. O que modelamos? Onde é usado? É controlado? Quem é o dono?

O problema mais difícil é a volatilidade. Nosso catálogo não é uma prateleira de trabalhos finalizados. Dez equipes de arte alteram ativos semanalmente, às vezes diariamente, por anos, e cada alteração repercute em longas cadeias de dependência construídas para animações de manutenção complexas. Gerenciar isso bem significa dizer aos artistas precisamente o que mudou, em vez de reverter tudo o que está abaixo disso.

Esse é o trabalho à nossa frente, e escreveremos sobre ele à medida que avançarmos, incluindo as partes que ainda não foram resolvidas.

Há uma razão maior para acertar. O governo possui enormes quantidades de dados CAD e de modelos paramétricos, grande parte deles entregue sob contrato anos atrás e efetivamente irrecuperável agora. Enquanto isso, a demanda está mudando do treinamento isolado para simulação, visualização e geração de conteúdo assistida por IA, todos os quais precisam de uma biblioteca pesquisável de dados 3D precisos por baixo. Um modelo só é útil se você puder encontrá-lo. Cada vez mais, só é útil se uma máquina também puder encontrá-lo.

Em um artigo futuro, detalharemos esse trabalho, incluindo onde o Unity Asset Manager ainda não se encaixa em um pipeline como o nosso e o que nós e a Unity estamos construindo juntos para fechar essa lacuna.

Também estaremos no I/ITSEC 2026 em Orlando, de 30 de novembro a 3 de dezembro, estande nº 1761. Venha nos encontrar.