【ITニュース解説】CAD to glTF - the manufacturer file pipeline nobody warns you about

ウェブサイト上で3Dモデルをインタラクティブに表示する「3Dコンフィギュレータ」のようなシステムは、近年のIT技術の進化により注目を集めている。ユーザーが製品の色やパーツをリアルタイムで変更し、様々な角度から確認できるデモンストレーションを見ると、いかにも簡単に実現できるように感じるかもしれない。しかし、実際に製品を製造するメーカーから提供されるデータを使ってこれを実現しようとすると、想像以上に複雑で困難な課題に直面する。この課題の核心は、Webブラウザで高速に動作する形式へ、メーカーの設計データを変換する「パイプライン」の構築にある。

メーカーが製品を設計する際には、「CAD（Computer Aided Design）」と呼ばれる専用のソフトウェアが使われる。SolidWorks、Inventor、Rhinoといったツールや、「STEPファイル」という汎用的な形式で設計データが作成されるのが一般的だ。これらのCADデータは、製品の正確な形状や寸法を定義するために最適化されており、部品点数や詳細な構造が非常に緻密に表現されている。しかし、このCADデータをそのままウェブ上で表示するための「glTF」という形式に変換すると、ファイルサイズが40MBから120MBにもなることが珍しくない。これほど大きなファイルは、ウェブブラウザで読み込むのに時間がかかり、スムーズなユーザー体験を損ねてしまう。

問題はファイルサイズだけではない。CADの世界とリアルタイムウェブレンダリングの世界では、いくつかの基本的な前提が異なるため、変換されたglTFデータには様々な「癖」が現れる。まず、多くのCADソフトウェアではZ軸を上方向として扱う「Z-up」という座標系が使われるが、ウェブブラウザで3Dモデルを表示するThree.jsのようなライブラリではY軸を上方向とする「Y-up」が一般的だ。この違いにより、CADから変換されたモデルはウェブ上で横倒しになってしまう。

次に、モデルの「スケール」も問題となる。CADデータは通常、ミリメートルやインチといった実世界の単位で非常に精密にモデリングされているため、これをそのままウェブ上に持ち込むと、極端に小さすぎて見えなかったり、逆に巨大すぎて画面に収まらなかったりする。また、「マテリアル」、つまりモデルの質感や色を定義する情報もCADとウェブレンダリングでは異なる。CADデータに含まれるマテリアル情報は、ウェブのリアルタイムレンダリングで一般的に使われる「PBR（物理ベースレンダリング）」という方式では意味をなさないことが多く、結果としてモデルは質感のない単色で表示されてしまうか、マテリアル情報自体が失われている場合もある。

さらに、CADデータは製品の設計を正確に再現するため、ネジ一本、ワッシャー一枚に至るまで、数千もの独立したパーツとして構成されていることが多い。これら一つ一つのパーツがそれぞれ描画されると、ウェブブラウザにかかる処理負荷が非常に高くなり、動作が重くなる原因となる。これらの問題は、メーカーが間違ったデータを提供しているわけではなく、単にCADの目的が「精密な設計」であるのに対し、ウェブのリアルタイムレンダリングの目的が「高速でインタラクティブな表示」であるという根本的な違いから生じるものだ。

これらの課題を解決し、メーカーから届くCADデータをウェブ上で利用可能なglTF形式へ効率的に変換するための「パイプライン」が必要となる。このパイプラインは、いくつかの段階を経てデータを処理していく。

まず、「デシメートとマージ」の段階だ。ここでは、Blenderのような3Dモデリングソフトウェアを使用して、モデルのパーツ数を削減し、結合する。例えば、顧客からは見えない内部の形状を削除したり、多くのネジやボルトをそれらが取り付けられている親パーツに溶接して一体化させたりする。これにより、数千もの独立したパーツで構成されていたモデルが、わずか数個のメッシュ（立体を構成する基本単位）にまで減り、描画負荷を大幅に軽減できる。

次に、「向きとスケールの修正」を行う。これは、モデルを読み込む際に一度だけ行えばよい作業だ。CADのZ-up座標系をウェブのY-up座標系に合うようにモデルを回転させ、ミリメートルやインチでモデリングされたスケールを、ウェブで扱いやすい「1単位＝1メートル」といった一般的なスケールに調整する。この修正は一度焼き付ければ、その後のアプリケーション開発で座標系やスケールを気にする必要がなくなる。

三つ目の段階は、「PBRマテリアルの再割り当て」だ。CADデータから引き継いだ意味のないマテリアルや失われたマテリアル情報に対し、ウェブのPBRレンダリングに適したマテリアルを再定義する。この際、各パーツごとにマテリアルを設定するのではなく、「フレーム」「ガラス」「金具」といったように、表面のグループごとにマテリアルスロットを割り当てる。これにより、例えば製品の色を変更する際に、多数のパーツにそれぞれ色を設定するのではなく、特定のグループのマテリアルを変更するだけで済み、効率的なカスタマイズが可能になる。

最後に、「圧縮」の段階がある。これは、処理されたglTFファイルのサイズをさらに削減するための重要なステップだ。gltf-transformやgltf-pipelineといったツールを使用し、モデルの形状データには「Draco」という技術を適用して圧縮する。また、モデルに使われている画像テクスチャは「KTX2」という形式で圧縮することで、ファイルサイズを小さくするだけでなく、グラフィックカード（GPU）が画像をより効率的に、圧縮された状態で扱えるようになる。この一連の圧縮処理によって、例えば90MBあったファイルが、見た目の品質を損なうことなく2MBから5MB程度にまで大幅に小さくなる。

このようにして構築されたパイプラインは、一度作成すれば終わりというものではない。これは、「製品ラインごと」に必要であり、そして「継続的に」運用されるべきプロセスだ。新製品が発表されたり、既存製品の新しいバリアント（派生モデル）が追加されたり、あるいはメーカーがモデルを更新したりするたびに、このパイプラインを通してデータを再処理する必要がある。

このような継続的な作業を効率的に進めるためには、パイプラインの自動化が不可欠だ。手作業で一つ一つクリックして処理するのではなく、BlenderスクリプトやLaravelキューといった技術を活用し、ワンコマンドで再処理が完了するようにシステムを構築することが推奨される。3Dコンフィギュレータの開発において、このアセットパイプラインの構築と運用は、デモ画面の作成とは別に、独立した重要な費用項目として予算に計上すべきだ。適切に設計され、自動化されたパイプラインを持つことは、メーカー向けの3Dコンフィギュレータ開発を成功させる上で、極めて重要な要素となる。