おひさしぶりです。らりおです。
進捗報告です。

ゲーム作っているはずが、補助ツール作っていました。
まあ、いつもの病気です。

ツール作った

FBXファイルは、jsonやXMLのように木構造を表現できる汎用的な文法を持っていて、その上に約束ごと(スキーマ)として、「こういう木構造があったらこう解釈するよ」という解釈が定められています。 (この解釈は正式に公開されているわけではなく、FBX SDKなどのインターフェースを見たり、実際にファイルを直接読んだりして推測しなければなりません。)

しかし、実はそのファイル上での木構造と、ファイル中に格納されたオブジェクト群の上下関係は必ずしも一致しているわけではありません。
大雑把に言うと、ファイル上では、「ノードの配列」と「エッジ(ノード同士の親子関係)の配列」だけ与えられるので、そこから自力で意味上のノードの木構造を読み取る必要があります。

そのノードの配列とエッジの配列の一部が、こちら。

vim-nodes
vim-edges

稀に例外はありますが、だいたいずっとこんな感じです。

FBX読み込みでここから進捗を出すためには、この10進数にして12桁のノードidを、エッジ・ノード間で縦横無尽に駆け巡り、目的のノードを得るまでのルートを探す必要があります。
(具体的には、現在メッシュが読めているので、それに対応するマテリアルとテクスチャを取得する処理をどう実装すればよいか調べる必要がありました。)

結果:

まあ、そりゃそうだ。

どんなツール?

実は可視化自体はすぐにできました。 以前のrogyブログでも書いた fbx_direct ライブラリのおかげです。

とはいえ、今回はテクスチャとマテリアルでしたが、これからアニメーションするなら他のノード間の関係も見たくなるはずだと考え、外部の設定ファイルを指定すると自動で可視化するノードやスタイル等を決定してくれるツールを作ることにしました。

ちなみに、可視化にかけた時間が2時間、目的のノードを絞り込んで実用的な図を出すのにそこから5時間、設定ファイル読み込みを実装するのにそこから休みをはさみつつ4日くらいです。
若干目的を見失った感はありました。 (設定ファイル書くより、可視化コードを直接弄る方が早いから……)

成果物

結局、昨日やっと完成しました。
出力例はこんな感じです。

texture-and-mesh
models

かっこいーー!!

所感

  • READMEに画像とかスクショを付けると、良さげな感じになる。

  • 少しでも面倒だと思った作業は自動化すべき。ただし、汎用化しようとするのは危険

  • 進捗がつらくなったからといって小説を書いても、特に捗ったりはしない。

  • Unityは神