10チーム、3つのプログラム、そして7年間：防衛訓練における3Dアセットの効率的な管理

このゲスト投稿は、i3 Corpsのマーケティングディレクターであるダニエル・スターキー氏と、システムアーキテクトのジョン・ソーントン氏によるものです。彼らは米国政府の顧客向けに仮想トレーニングツールやエンジニアリング生産性向上ツールをビルド、ここではダニエルとジョンが、10年にわたる軍事デジタルツインが3Dアセットパイプラインにどのような影響を与えるかを説明する。

i3 Corpsは、政府機関の顧客向けに仮想トレーニングツールとエンジニアリング生産性向上ツールを開発している。長年にわたり、私たちはUnityで数百もの訓練シナリオを開発してきました。これらは、私たちがサポート航空訓練のほとんどを網羅しており、海軍のプラットフォームや地上車両にも対応しています。これらのアプリケーションは、当社が構築した政府所有の分布プラットフォームを通じて、全国の軍事施設の教室にリーチ、安全な政府クラウド上で稼働しています。

アプリケーションは目に見える部分です。難しい部分はそれらの下、つまり3Dライブラリにあり、アセットパイプラインに関する一般的なアドバイスはほとんど当てはまらない。

購入したプログラムよりも長く存続するモデル

ほとんどの3D制作では、製品が出荷された時点でアセットは完成となります。

私たちのモデルは実物機器のデジタルツインであり、実物機器は常に変化し続けています。新しいコンポーネントが稼働を開始しました。メーカーが部品を改良する。顧客が新しいCADパッケージを送信すると、モデルはそのデータを吸収する必要がある。当社の航空機モデルの一つは、ナットやボルトに至るまで、8万個もの部品で構成されています。当社では年間10～15種類の新モデルを追加しており、それぞれのモデルごとに8～9年間のメンテナンス契約が締結されます。

それは、ほとんどのパイプラインが解決する必要のない問題を生み出す。新しい技術データが届いたら、誰かがそれが何を変えるのかを解明しなければならない。それはどの部品を置き換えるものですか？既存のどのモデルを更新のですか？既に教室で使用されているアプリケーションのうち、どれがそのモデルに依存しており、それらはどうなるのか？

リファレンスデータ同様の方法で合成されます。当社のモデルは、さまざまなソースからのCADパッケージと、当社自身でキャプチャフォトグラメトリに基づいて作成されています。一度のキャプチャ旅行で、一台の車両を何百万枚も撮影できる可能性がある。数年後、同じプラットフォーム向けに新しいCADが登場したとき、両者を比較できるように、元のモデルがどこから来たのかを知っておく必要があります。その答えは簡単に失われ、再構築するには費用がかかる。

同じ機体構造だが、異なる航空機

UH-60ブラックホークを例にとってみましょう。米陸軍だけでも、UH-60A、L、M、V、HH-60M医療搬送機、特殊作戦やその他の任務用の特殊機など、数多くの派生リストを運用している。海軍、空軍、そして国際的な運用者を加えると、訓練が必要な構成の数は急速に増加する。

それらはすべて正当な訓練ターゲットではあるが、それぞれ独立した航空機ではない。ほとんどの機種は、胴体、テールブーム、ローターアセンブリ、着陸装置を共有。UH-60Vは、L型の機体構造を大部分維持しつつ、デジタルコックピットを追加している。HH-60M MEDEVACは、UH-60Mをベースに、医療機器とミッションシステムを追加して開発されたヘリコプターである。

それぞれをゼロからモデリングすると、同じ部品を何度も再構築、再検証、保守することになります。より良いアプローチは、再利用可能なコンポーネントから構築された共通のベースラインであり、各バリアントは実際に異なる部分、つまり構造体、機械システム、航空電子機器、またはミッション機器のみを追加するというものである。

最後の区間は10年前のコンピューターです

コンシューマー向けソフトウェアは、ストレージ容量の制約を無視することで対処している。数十ギガバイトものデータをダウンロードし、空き容量を確保するために何か他のものを削除することを要求してくる。

それはできません。私たちのアプリケーションは、政府機関のコンピュータにインストールされますが、それらのコンピュータは古い場合があり、高度なセキュリティ対策が施されており、ユーザーが使用できるスペースに厳しい制限があります。教室用のマシンには、そのプラットフォーム向けにこれまで作成したすべてのトレーニングコースが保存されている可能性があります。従来の方法でコンパイルし、各アプリケーションにモデルを組み込むと、数百ギガバイトものほぼ同一のジオメトリデータが生成されます。

それを避けるために、 Unity Addressablesを使用します。モデルはビルド内ではなくカタログに格納され、必要に応じて取得され、ローカルにキャッシュされます。重複排除は最適化というよりはデフォルトです。なぜなら、15個のアプリケーションから参照されるアセットは一度だけ保存されるからです。アプリケーションは、コードが変更された場合にのみ変更する必要がある。これはまた、開発者がシーンを組み立てるために、ライブラリ全体を1台のマシンにインストールする必要がないことも意味します。

セキュリティも重要な要素です。機密マテリアルは決してクラウドにアクセスしてはならないが、管理対象非機密情報（CUI）はアクセス可能であり、ただし、誰もマシン上でモデルを開いて持ち出すことができないように保護する必要がある。アセットがどのカテゴリに属するかを、確実かつ一目で把握することは、管理上のオーバーヘッドにはならない。それは、そのアセットがどこに存在できるかを決定するものです。

セキュリティとは全く関係のない、関連する質問が頻繁に出てきます。それは、「これは誰の所有物なのか？」というものです。一部の資産はi3のプロパティであり、一部は政府のプロパティです。この区別によって、次の契約でアセットを再利用できるか、提案書でリファレンスかが決まります。

なぜ私たちは自社カタログの作成をやめたのか

私たちは建設に着手した。

長らく、このようなツールを政府機関向けにクラウドで提供するオプションがなかったため、私たちは市販のアセット管理プラットフォームを調査しましたが、常に同じ2つの問題に直面しました。それは、ツールが私たちのデータの実際の仕組みに合わないか、ライセンスモデルが政府機関での利用には非現実的であるかのどちらかでした。そこで私たちは、既存のバージョン管理と自動化の上にデータベースと検索を重ね合わせることで、独自のシステムを構築し始めました。

ある程度まではうまくいった。資産を見つけることができた。正当化できなかったのは残りの部分、つまりエンジンのインテグレーション、パイプラインの自動化、依存関係の追跡、そしてそれらすべてを無期限に維持することだった。

それは我々の管轄外だ。私たちは政府機関のお客様にトレーニングとエンジニアリングソリューションを提供しており、アーティストや開発者がUnityから離れることなく使用できるツールチェーンは、私たちが独自に維持管理しなければならないシステムよりも価値があります。

だからこそ私たちはUnity Asset Managerを政府機関のクラウド環境に導入し、現在Unityと協力して、私たちのようなパイプラインにとってUnityがどのような存在になるべきかを検討しているのです。

次に解決する課題

完成した資産をカタログ化することは最初のステップであり、これまで周囲に尋ねて解決していた疑問に既に答えることができる。私たちは何をモデル化したのか？どこで使われていますか？それは制御されているのか？誰が所有しているのか？

より難しい問題は変動性だ。私たちのカタログは、完成作品の棚ではありません。10のアートチームが、何年もの間、毎週、時には毎日アセットを変更しており、その変更はすべて、複雑なメンテナンスアニメーションのために構築された長い依存関係チェーン全体に波及する。それをうまく管理するには、変更後のすべてを元に戻すのではなく、何が変わったのかをアーティストに正確に伝える必要がある。

それが私たちの目の正面の課題であり、未解決の部分も含め、その進捗状況について随時記事を書いていく予定です。

それを正しく行うべき、より大きな理由がある。政府は膨大な量のCADデータとパラメトリックモデルデータを保有しているが、その多くは数年前に契約に基づいて納入されたものであり、現在では事実上入手不可能となっている。一方、需要は単なるトレーニングから、シミュレーション、可視化、AI支援によるコンテンツ生成へと移行しつつあり、これらすべてには、正確な3Dデータを検索可能なライブラリとして活用することが不可欠である。モデルは、見つけることができなければ役に立たない。ますます、機械がそれを見つけられる場合にのみ有用となる。

今後の記事では、その取り組みについて具体的に説明します。具体的には、 Unity Asset Managerがまだ私たちのパイプラインに適合していない点や、そのギャップを埋めるために私たちとUnityが共同で開発しているものなどについて触れていきます。

また、11月30日から12月3日までオーランドで開催されるI/ITSEC 2026にも出展いたします。ブース番号は1761です。私たちを探しに来てください。