10 команд, 3 программы и 7 лет: Эффективное управление 3D-ассетами в оборонном обучении

Этот гостевой пост от Дэниела Старки, директора по маркетингу, и Джона Торнтона, системного архитектора, из i3 Corps. Они создают инструменты для виртуального обучения и повышения инженерной продуктивности для государственных клиентов США, а здесь Дэниел и Джон объясняют, что десятилетие военных Digital Twins делает с конвейером 3D-активов.

i3 Corps создает инструменты виртуального обучения и повышения инженерной продуктивности для государственных заказчиков. За эти годы мы разработали сотни тренажерных сценариев в Unity, охватывающих большую часть авиационного обучения, которое мы поддерживаем, а также платформы ВМФ и наземные транспортные средства. Эти приложения доходят до классов на военных базах по всей стране через государственную дистрибутивную платформу, которую мы создали, работающую в защищенном государственном облаке.

Приложения — это видимая часть. Сложная часть находится под ними, в 3D библиотеке, и почти ни один из стандартных советов о конвейерах ассетов не применим.

Модель, которая переживает программу, купившую ее

В большинстве 3D-работ актив считается завершенным, когда продукт отправляется.

Наши модели — это digital twins физического оборудования, и физическое оборудование постоянно меняется. Новый компонент вводится в эксплуатацию. Производитель пересматривает деталь. Клиент присылает свежий пакет CAD, и модель должна его принять. Одна из наших авиационных моделей состоит из 80 000 компонентов, вплоть до гаек и болтов. Мы добавляем десять-пятнадцать новых моделей в год, и каждая из них начинает сервисное обслуживание, которое может длиться восемь или девять лет.

Это создает проблему, которую большинство конвейеров никогда не приходится решать. Когда поступают новые инженерные данные, кто-то должен выяснить, что они меняют. Какие части оно заменяет? Какую существующую модель оно обновляет? Какие из уже существующих в классах приложений зависят от этой модели, и что с ними происходит?

Справочные данные комбинируются так же. Наши модели построены из пакетов САПР из разных источников, а с помощью фотограмметрии мы захватываем их сами. Одна поездка по захвату может дать миллионы фотографий одного транспортного средства. Спустя годы, когда для той же платформы появится новая САПР, вам нужно знать, откуда взялась оригинальная модель, чтобы сравнить их. Этот ответ легко потерять и дорого восстановить.

Один и тот же фюзеляж, разные самолеты

Возьмите UH-60 Black Hawk. В одиночку Армия США эксплуатирует длинный список версий: UH-60A, L, M и V, HH-60M MEDEVAC, а также специализированные самолеты для специальных операций и других миссий. Добавьте ВМФ, ВВС и международных операторов, и количество конфигураций, на которых нужно проходить обучение, быстро растет.

Каждый из них является законной тренировочной целью, но это не отдельные самолеты. Большинство имеют одинаковый фюзеляж, хвостовую часть, роторные узлы и шасси. UH-60V сохраняет большую часть фюзеляжа L и добавляет цифровой кокпит. HH-60M MEDEVAC построен на базе UH-60M с добавлением медицинского оборудования и систем миссии.

Моделируйте каждую с нуля, и вы перестраиваете, повторно проверяете и поддерживаете одни и те же части снова и снова. Лучший подход — это общая базовая модель, построенная на переиспользуемых компонентах, где каждый вариант добавляет только то, что действительно отличается: структура, механические системы, авионика или оборудование миссии.

Последняя миля — это десятилетний компьютер

Потребительское программное обеспечение справляется с проблемой нехватки места, игнорируя ее. Он скачивает десятки гигабайт и ожидает, что вы удалите что-то другое, чтобы освободить место.

Мы не можем этого сделать. Наши приложения устанавливаются на государственные машины, которые могут быть старыми, иметь значительные меры безопасности и иметь строгие ограничения на объем используемого места. Классная машина может содержать все учебные курсы, которые мы когда-либо создавали для этой платформы. Скомпилировано традиционным способом, с моделями, встроенными в каждое приложение, что составляет сотни гигабайт в основном идентичной геометрии.

Мы используем Unity Addressables, чтобы этого избежать. Модели находятся в каталоге, а не внутри сборки, они подтягиваются по требованию и кэшируются локально. Дедупликация является настройкой по умолчанию, а не оптимизацией, потому что актив, на который ссылаются пятнадцать приложений, хранится один раз. Приложения нужно изменять только тогда, когда меняется их код. Это также означает, что разработчику не нужно иметь всю библиотеку на одной машине для сборки сцены.

Безопасность также является критически важным фактором. Секретная информация никогда не попадает в облако, но Контролируемая несекретная информация (CUI) может, но ее нужно упаковать так, чтобы никто не смог открыть модель на машине и унести ее. Знание того, к какой категории относится актив, надежно и с первого взгляда, — это не административные издержки. Определяет, где разрешено существование актива.

Постоянно возникает связанный вопрос, который не имеет никакого отношения к безопасности: кому это принадлежит? Некоторые активы являются собственностью i3, а некоторые — государственной собственностью, и это различие определяет, можем ли мы повторно использовать актив в следующем контракте или сослаться на него в предложении.

Почему мы перестали создавать собственный каталог

Мы начали строить один.

Долгое время не было варианта с облаком для государственных нужд для такого рода инструментов, поэтому мы изучили коммерческие платформы управления активами и постоянно сталкивались с одной и той же проблемой: либо инструмент не соответствовал тому, как на самом деле работают наши данные, либо модель лицензирования делала его непрактичным для государственного использования. Итак, мы начали собирать свой собственный, накладывая базу данных и поиск поверх нашего существующего Version Control и автоматизации.

Это сработало, до определенной степени. Мы могли бы найти активы. Что мы не смогли обосновать, так это остальное: интеграция двигателя, автоматизация конвейера, отслеживание зависимостей, а затем поддержание всего этого бесконечно.

Это не наше дело. Мы предоставляем обучение и инженерные решения государственным клиентам, и инструментарий, который наши художники и разработчики могут использовать, не покидая Unity, для нас ценнее, чем индивидуальная система, которую нам пришлось бы поддерживать самостоятельно.

Вот почему мы развернули Unity Asset Manager в облачной среде правительства и почему мы теперь работаем с Unity над тем, чем он должен стать для таких конвейеров, как у нас.

Что мы решаем дальше

Каталогизация готовых активов — это первый шаг, и это уже отвечает на вопросы, на которые мы раньше отвечали, расспрашивая. Что мы смоделировали? Где это используется? Это контролируется? Кому это принадлежит?

Более сложная проблема — волатильность. Наш каталог — это не полка готовых работ. Десять художественных команд еженедельно, а иногда и ежедневно, меняют ассеты в течение многих лет, и каждое изменение отражается на длинных цепочках зависимостей, созданных для сложной технической анимации. Хорошее управление этим означает точно сообщать художникам, что изменилось, а не откатывать всё, что находится ниже по течению.

Это работа, которая перед нами, и мы будем писать о ней по ходу, включая те части, которые еще не решены.

Есть более веская причина сделать это правильно. Правительство владеет огромными объемами данных CAD и параметрических моделей, большая часть которых была предоставлена по контракту много лет назад и теперь фактически недоступна. Тем временем спрос смещается от простого обучения к симуляции, визуализации и генерации контента с помощью ИИ, и все это требует наличия поисковой библиотеки точных 3D. Модель полезна, только если вы можете ее найти. Все чаще это полезно, только если машина может это найти.

В предстоящей статье мы более подробно рассмотрим эту работу, включая то, где Unity Asset Manager еще не соответствует нашему конвейеру, и что мы с Unity создаем вместе, чтобы устранить этот пробел.

Мы также будем на I/ITSEC 2026 в Орландо с 30 ноября по 3 декабря, стенд №1761. Приходите к нам.