【要約】BlenderでglTF エクスポートした際にボーンウェイトが変わってもエラーが出ない [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
LODツールを開発中のエンジニアが、BlenderでglTF書き出しを行う際に、ボーンウェイトが意図せず改ざんされる問題に直面した。
- ・1頂点あたりのボーン影響数が4本を超えると、エクスポータが上位4本のみを残して自動的に切り捨てる。
- ・切り捨て後にウェイトが再正規化されるため、合計値の検算では異常を検知できない。
- ・警告メッセージが標準出力（stdout）にのみ出力され、終了コードやAPIの戻り値には含まれない。
- ・自動化環境でstdoutを監視しない限り、データの変質を「無音」で受け入れることになる。
// Approach
エンジニアは、エクスポータの警告に依存せず、出力されたGLBファイルを直接解析してデータの整合性を検証する手法を採用した。
- ・出力されたGLBファイルを自前で読み込む。
- ・JOINTS_nおよびWEIGHTS_nの全セットを走査する。
- ・頂点ごとの非ゼロウェイト数をカウントし、ヒストグラムを作成する。
- ・入力データのウェイト分布と、出力データの分布を突き合わせて差異を検出する。
// Result
この検証手法により、エンジニアはデータの改ざんを確実に検知し、変形誤差の規模を定量的に把握することが可能となった。
- ・エクスポータの警告に頼らない、バイナリレベルでの検証フローを確立した。
- ・切り捨てによる変形誤差が、最大でbbox対角の6.5%に達することを実測した。
- ・stdoutの監視が、パイプの詰まりを引き起こすリスクがあることを明らかにした。
Senior Engineer Insight
> 3Dアセットの自動化パイプライン構築において、ツールの「正常終了」を盲信してはならない。本件のように、仕様に基づいた「親切な自動修正」が、データの整合性を破壊するリスクがある。特に、警告が構造化された戻り値ではなく、非構造的なstdoutにのみ流れる設計は、運用上の脆弱性となる。検知ロジックは、外部ツールの挙動に依存せず、出力された成果物を直接検証する「ゼロトラスト」な設計が不可欠である。