Contact
AIゲーム開発研究室
第8回 TripoリグにMixamo Actionは使えるのか
AIゲーム開発研究室
3Dモデル制作ドキュメント
第8回
TripoリグにMixamo Actionは使えるのか
― 骨格構造の検証とリターゲット実験 ―
研究代表 大川 博
主任研究員 Arc（ChatGPT）
はじめに
前回までの検証によって、Tripoでは3Dモデルにリグを設定し、プリセットActionを適用できることを確認した。
また、AIアニメーション機能を使用して、テキストによる指示からオリジナルActionを生成する実験も行った。
しかし、実際に生成されたActionには問題があった。
「3回ジャンプして喜ぶ」と指示したActionでは、ジャンプしようとする動作は確認できたものの、足は地面から離れなかった。
「まっすぐ前に走る」と指示したActionでは、キャラクターは前進したものの、動作そのものは走行ではなく歩行に近いものとなった。
さらに、手の部分が最初から不自然にねじれたActionも確認された。
ゲーム制作では、キャラクターに多様なActionが必要になる。
Tripoに用意されたプリセットActionだけでは選択肢が限られ、AIによるオリジナルAction生成についても、前回の実験では要求した動作を安定して生成することができなかった。
そこで今回は、
Tripoで生成したリグをそのまま使用し、豊富なActionを持つMixamoからアニメーションだけを利用することができるのか
を検証することにした。
1 MixamoのActionをCモデルへ適用する
まず、本物のMixamoからダウンロードしたダンスActionを使用した。
これを、TripoでリギングしたCタイプのパンタへBlender上で適用する。
ボーン名には、
mixamorig:Hips
mixamorig:Spine
mixamorig:LeftArm
など、Mixamoと同じ形式の名称が使用されている。
そのため、当初はMixamo Actionをそのまま利用できる可能性があると考えた。
しかし、実際にActionを適用すると、パンタは正常な位置にとどまらず、空間内を大きく飛び回った。
2 Hipsの位置情報を調べる
Blenderのグラフエディターで mixamorig:Hips を確認すると、位置情報がXYZ各軸に記録されていた。
そこで、Hipsの位置XYZを一つずつ無効化して動作を確認した。
一軸だけを停止してもパンタは動き続け、動き方だけが変化した。
最終的にXYZすべての位置情報を無効化すると、パンタはその場に固定され、ダンスを行うようになった。
しかし、新たな問題が確認された。
パンタの身体が傾いている。
さらに、ダンス自体も完全に崩壊しているわけではないものの、Mixamo本来のダンスと比較すると不自然だった。
3 100倍のスケール差を疑う
Mixamo純正ArmatureとTripo CモデルのArmatureを比較すると、大きな違いがあった。
Mixamo側は、
Rotation X = 90°
Scale = 0.01
Tripo側は、
Rotation = 0°
Scale = 1.0
となっていた。
特に気になったのが、
Scale 0.01とScale 1.0という100倍の違い
である。
Mixamo ActionにはHipsの位置情報も記録されている。
そのため、Mixamo ActionをTripoのArmatureへ直接適用したことで、100倍のスケール差が位置移動に影響した可能性を考えた。
そこでMixamo純正Armatureに、
Ctrl+A → 回転とスケール
を適用すると、
Rotation = 0°
Scale = 1.0
となった。
しかし、変更したのはMixamo純正Armatureであり、Tripo Cモデルではない。
そのため、この実験だけでは、100倍のスケール差が異常な位置移動の原因だったのかを確認することはできなかった。
そこで、次に骨格そのものを比較することにした。
4 MixamoとTripoの骨格を比較する
Mixamo純正ArmatureとTripo CモデルのArmatureを比較した。
Actionによる変形の影響を受けず、骨格本来の状態を確認するため、Blenderの、
Rest Position（レスト位置）
で表示した。
Mixamo純正骨格はTポーズを基準としている。
一方、Tripo Cモデルは、パンタのAポーズをもとに生成された骨格である。
当然、両者の骨格配置には違いがある。
しかし調べてみると、違っていたのはポーズや体型だけではなかった。
5 Bone Rollが大きく違っていた
Blenderの編集モードで、それぞれのBone Rollを確認した。
結果は次のようになった。
| ボーン | Tripo Cモデル | Mixamo純正 |
|---|---|---|
| Hips | −90° | 0° |
| Spine | −99° | 0° |
| LeftArm | 29° | −180° |
Tripoのボーンには、
mixamorig:Hips
mixamorig:Spine
mixamorig:LeftArm
など、Mixamoと同じ形式の名前が付けられている。
しかし、
ボーン名が同じでも、骨格そのものが同じとは限らない。
Bone Rollが異なれば、ボーンが回転するときの基準となるローカル軸も異なる。
これが、Mixamo ActionをTripoリグへ直接適用したときに、身体が傾いたり、不自然な動きになったりする原因の一つではないかと考えた。
6 直接適用せず、動きを転送してみる
そこで、Mixamo ActionをTripoリグへ直接適用する方法をやめ、
正常に動いているMixamo純正骨格の動きを、Tripo骨格へ転送する
方法を試した。
Blenderの、
Copy Rotation
を使用する。
まず、Tripo側の mixamorig:LeftArm にCopy Rotationを設定し、Mixamo側の同名ボーンの回転を受け取るようにした。
すると、Tripo側のLeftArmもMixamo側の動きに追従した。
Copy Rotationの影響を0にすると停止し、1に戻すと再び動いた。
これによって、
Mixamo骨格からTripo骨格へ回転動作を転送できる
ことを確認した。
7 他のボーンでも確認する
同じ方法を、
RightArm
LeftForeArm
RightForeArm
Hips
にも設定した。
これらもMixamo側の動きに追従した。
つまり、
Mixamo Actionを直接Tripoリグへ入れる方法には問題があるが、Mixamo骨格の動きをTripo骨格へ転送することはできる
ことが分かった。
8 全身へ一括設定する
しかし、全身のボーンへ一つずつCopy Rotationを設定するのは現実的ではない。
そこでBlenderのPythonスクリプトを使用し、Mixamo側とTripo側に同じ名前のボーンが存在する場合、自動的にCopy Rotationを設定するようにした。
これによって、全身へのリターゲット設定を一括して行った。
9 全身は動いた。しかし傾きが残った
一括設定後、Cモデルの全身がMixamo Actionに追従するようになった。
直接Actionを適用した場合と比較すると、動作は大幅に改善した。
つまり、
TripoリグへMixamoの動作を転送すること自体は可能
である。
しかし、パンタの身体には依然として傾きが残った。
HipsやSpineのCopy Rotationを無効化してみたが、改善するどころか姿勢はさらに悪化した。
完全に一致させるためには、Bone Rollや基準姿勢など、両骨格の違いをさらに補正する必要があると考えられる。
10 技術的には可能だが、実制作には適さない
今回の実験で、
Mixamo骨格の動きをTripo骨格へリターゲットできる
ことは確認できた。
しかし、そのためには、
Mixamo純正骨格を用意し、
Tripo骨格との対応を設定し、
全身へリターゲットを行い、
さらに姿勢の違いを補正する必要がある。
ゲーム制作の実用工程として考えると、複雑すぎる。
11 TripoのActionにも問題が残る
Tripoだけで完結できるのであれば、Mixamoを使用する必要はない。
しかし、前回までの実験では、TripoのAIによるオリジナルActionにも問題があった。
「3回ジャンプして喜ぶ」では、ジャンプしようとするものの足が地面から離れなかった。
「まっすぐ前に走る」では、前進はしたものの、動作は走行ではなく歩行に近かった。
さらに、手が不自然にねじれたActionも生成された。
また、Tripoに用意されたプリセットActionだけでは、ゲーム制作に必要な多様な動作をまかなうことは難しい。
12 今回の結論
Tripoではリグを生成でき、キャラクターを動かすこともできる。
しかし、今回の検証では、
TripoのプリセットActionだけでは選択肢が不足する。
AIによるオリジナルActionも、要求した動作を安定して生成できない。
Mixamo ActionをTripoリグへ直接適用すると正常に動作しない。
リターゲットによる動作転送は可能だが、追加設定と補正が必要になる。
という結果になった。
そのため、本研究では一旦、
TripoによるリギングとAction制作を、ゲーム制作の本線から外す。
Tripoは、
3Dモデル生成・軽量化
までを担当し、
リギングとActionについては、
Mixamoを使用する
方向で検証を進めることにした。
13 次の検証へ
次は、リグを持たないパンタをMixamoへ直接アップロードし、
Mixamoでリギング → Action設定 → Blenderで編集 → Unityで確認
という制作工程を検証する。
ただし、この後の研究では、
「Tripoで作ったリグを、本当にMixamoで利用する方法はないのか」
という疑問が再び浮上することになる。
この問題については、改めて別の実験として検証する。
第7回 Tripoでリギングとアニメーションを検証する
AIゲーム開発研究室
3Dモデル制作ドキュメント
第7回 Tripoでリギングとアニメーションを検証する
研究代表 大川 博
主任研究員 Arc（ChatGPT）
はじめに
前回までの検証によって、パンタのAポーズ4面図から3Dモデルを生成し、さらにゲーム利用を想定した軽量モデルまで制作することができた。
今回は、この3Dパンタを実際に動かす段階へ進む。
使用するのは、Aポーズ4面図から生成したCタイプのパンタである。
今回検証するのは、
Tripoでリギングできるのか。
そのリグを使用してアニメーションできるのか。
アニメーションを含めてBlenderへ持ち出せるのか。
そして、
TripoのAIによってオリジナルアクションを制作できるのか。
という点である。
結果として、Tripoのリギングとプリセットアニメーションについては実用につながる成果を得ることができた。
一方、AIによるオリジナルアクション生成については、現段階ではゲーム制作に使用することが難しいという結果になった。
1 前回のAuto Rig実験
以前、パンタの公式4面図をTripoのMulti-viewへ入力し、3Dモデルを生成する実験を行った。
このときの目的は、
4方向から描いたキャラクター設定画を使用することで、パンタのデザインを維持した3Dモデルを生成できるのか
を確認することだった。
そのため、この4面図はリギングを目的として制作したものではない。
パンタは自然な立ち姿で、両腕を曲げ、リュックのベルトを持っていた。
3Dモデル生成後、TripoにAuto Rig機能があることから、このモデルにも試験的にリギングを行ってみた。
すると、リギング用に制作したモデルではないにもかかわらず、Humanoidの骨格そのものは生成された（ように見えた）。
そこでさらに、Tripoのプリセットアニメーション dance_02 を適用してみた。
しかし、このときはモデルが正常に動くことを確認できなかった。
つまり前回の段階では、
Auto Rigによって骨格を生成することはできた（ように見えた）。
しかし、
その骨格を使用してTripo上で実際にアニメーションできるかどうかは確認できなかった。
という状態で実験を終えていた。
2 今回はAポーズモデルを使用する
今回は、本格的にリギングとアニメーションを検証するため、Aポーズ4面図から生成したパンタを使用した。
TポーズやAポーズのように、腕と胴体を離した状態からリギングを行うことは、3Dキャラクター制作では基本的な方法である。
前回のような、腕を曲げてリュックのベルトを持ったモデルへAuto Rigを行うこと自体が、通常とは異なる追加実験だった。
今回は通常の制作工程へ戻り、腕と胴体の間に空間を持つAポーズモデルを使用する。
使用したのは、前回までの比較実験で制作したCタイプである。
3 TripoでAuto Rigを実行する
Tripoの「アニメイト」からAuto Rigを実行した。
リグには、
v1.0 ― Humanoid
を使用した。
処理が完了すると、パンタの内部に骨格が生成された。
胴体、腕、脚だけでなく、手の部分にも複数のボーンが配置されていることを確認できた。
パンタは人間とは大きく異なる体形をしている。
それでもTripoはHumanoidとして骨格を生成することができた。
ここでまず、
Tripoだけでパンタのリギングを行える
ことを確認できた。
4 前回動かなかったダンスが動いた
次に、Tripoのプリセットアニメーションを適用した。
ここで重要なのは、前回の実験で正常な動作を確認できなかった dance_02 である。
今回、同じ dance_02 をAポーズモデルへ適用した。
すると、パンタは正常にダンスを始めた。
さらに dance_04 など、複数のプリセットアニメーションを試したが、いずれもパンタへ反映された。
これによって、
Auto Rigで骨格を生成できるだけでなく、その骨格を使用してTripoのプリセットアニメーションを実際に再生できる
ことが確認できた。
一方、両腕を大きく上げた際には、脇部分が引っ張られて広がるような変形も見られた。
また、リュックはパンタの背中と一体化した形状として生成されているため、胴体を大きくねじるとリュックとの境界部分も一緒に変形する。
これらは今後、モデルのパーツ分割やウェイト調整を検討する必要がある部分である。
5 アニメーションをFBXへ書き出す
次に、Tripoで動かしたアニメーションをBlenderへ持ち出せるかを検証した。
最初のエクスポートでは、FBXにアーマチュアは含まれていたものの、BlenderのAction Editorにはアニメーションが存在しなかった。
ここで再度Tripoのエクスポート画面を確認した。
すると、
「アニメーションの数」
という項目が表示された。
この項目を開くと、それまでに使用したアニメーションが一覧表示された。
さらに、アニメーションは一つだけではなく、複数選択できることが分かった。
実験として、
dance_02
front_kick_02
flip
の3種類を選択した。
エクスポート画面には、
アニメーションの数 3
と表示された。
6 Blenderで3つのActionを確認する
出力したFBXをBlenderへ読み込んだ。
Action Editorを確認すると、
dance_02
flip
front_kick_02
の3つが、それぞれ独立したActionとして存在していた。
これによって、
Tripoでは複数のアニメーションを一つのFBXファイルへ格納し、Blenderへ受け渡せる
ことが実際に確認できた。
なお、Tripoを終了し、PCを再起動した後に再び確認したところ、生成・使用したアニメーション候補そのものは残っていた。
一方、FBXへ含めるためのアニメーション選択は解除されていた。
そのため、エクスポートする際には、必要なアニメーションをその都度選択する必要があると考えられる。
7 AIでオリジナルアクションを作る
次に、Tripoの、
「自分だけのアニメーションを作る」
機能を検証した。
これは、文章でキャラクターの動きを指示し、AIによって新しいアニメーションを生成する機能である。
画面には時計のアイコンと数値「5」が表示されていた。
当初、この「5」が何を意味するのか明確ではなかった。
そこで設定を変更せず、実際にアニメーションを生成して確認することにした。
8 最初の「喜び」アクション
最初は、パンタが両手を上げて喜ぶ動作を文章で指示した。
生成そのものには成功した。
しかし、実際の動作は腕を上げて下ろす程度の単純なものになった。
さらに、腕を動かした際に手の部分が不自然にねじれる現象も確認された。
パンタには人間のような明確な手首形状がないため、人型骨格の手首回転がそのまま適用されたことも原因の一つと考えられる。
9 「3回ジャンプ」を生成する
次に、より明確な動作としてジャンプを指定した。
最初は複数の動きを含む指示を与えたが、ジャンプそのものが正常に生成されなかった。
そこで指示を単純化し、
「その場で3回ジャンプする。」
とした。
するとAIは、膝を曲げ、腕を動かし、3回ジャンプしようとする動作を生成した。
しかし、
パンタの足は地面から離れなかった。
つまり、3回の「ジャンプ動作」は生成されたが、実際の跳躍にはなっていなかった。
10 5秒＝120フレーム＝24fpsを確認する
生成されたオリジナルアニメーションをFBXへ含め、Blenderで確認した。
Tripo上では、生成されたアニメーションの再生時間が約5秒となっていた。
Blenderでは、このアニメーションが、
1～120フレーム
として読み込まれた。
したがって、
120フレーム ÷ 5秒 ＝ 24fps
となる。
これによって、AIアニメーション生成画面に表示されていた「5」は、今回の実験では5秒のアニメーション時間を指定していることが確認できた。
11 AIアニメーションの内部データを確認する
Blenderでさらにアニメーション内部を調べた。
Tripoから出力されたアーマチュアには、
mixamorig:Hips
をはじめとする mixamorig: の名称を持つボーンが使用されていた。
各ボーンのアニメーションを見ると、ほぼすべてのフレームにキーフレームが記録されている。
つまり、Tripoで生成されたモーションは、各ボーンの動きとして細かくベイクされた状態でFBXへ出力されている。
「その場で3回ジャンプする」について mixamorig:Hips の位置も確認した。
Hipsには細かな位置変化が存在した。
しかし、その移動量はパンタを地面から明確に浮かせるほど大きなものではなかった。
Blender上で内部データを確認しても、
ジャンプの動作は作られているが、実際にはジャンプしていない
ことが確認できた。
12 「まっすぐ前に走る」を生成する
ジャンプでは十分な位置移動が生成されなかった。
そこで、AIがキャラクターそのものの移動を生成できるのかを確認するため、さらに単純な指示を与えた。
「まっすぐ前に走る。」
である。
生成結果を見ると、パンタは確かに前方へ移動した。
しかし、
走ってはいなかった。
動作は明らかに歩行だった。
これは重要な結果だった。
AIは「前へ移動する」という意味は反映している。
しかし、「走る」という運動そのものを正確に生成できていない。
13 前進移動はHipsに記録されていた
「まっすぐ前に走る」のFBXをBlenderへ読み込み、mixamorig:Hips の位置データを確認した。
すると、Hipsには明確な前進移動が記録されていた。
つまりTripoのAIアニメーションは、キャラクターの位置移動そのものを生成できないわけではない。
今回のデータでは、Graph Editor上で大きく変化している位置成分はXであった。
一方、Blenderの3Dビュー上ではパンタは−Y方向へ前進している。
この違いは、FBXの座標変換やボーンのローカル座標系との関係によるものと考えられる。
ただし今回の目的で重要なのは、
AIによって生成されたアニメーションに、実際の前進移動データが含まれている
という点である。
14 AIオリジナルアクションはゲーム制作に使えるのか
今回、複数の文章指示からオリジナルアニメーションを生成した。
その結果、
「喜ぶ」
動きが単純で、手部分に不自然なねじれが発生した。
「その場で3回ジャンプする」
3回ジャンプしようとする身体動作は生成したが、足は地面から離れなかった。
「まっすぐ前に走る」
前進移動は生成したが、実際の動作は歩行になった。
つまりAIは、文章の意味を完全に無視しているわけではない。
指示された動作の特徴をある程度捉え、身体運動や位置移動として反映している。
しかし、ゲームアニメーションでは、
走るなら走る。
ジャンプするなら地面から離れる。
という基本的な動作の正確さが必要になる。
今回の検証では、その精度を得ることができなかった。
したがって、
現時点のTripo AIアニメーションによるオリジナルアクション生成は、パンタのゲーム用アニメーション制作には実用できない
と判断した。
15 今回の検証で分かったこと
今回の実験によって、Tripoのリギングとアニメーションについて、できることとできないことがかなり明確になった。
まず、
Aポーズから生成したパンタへAuto Rigを行うことができた。
さらに、
生成したリグへTripoのプリセットアニメーションを適用し、実際にパンタを動かすことができた。
そして、
複数のプリセットアニメーションを一つのFBXへ格納し、Blenderで個別のActionとして使用できた。
ここまでは、実際のゲーム制作につながる機能として利用できる。
一方、AIによるオリジナルアクション生成については、
アニメーションデータそのものは生成できる。
位置移動も生成できる。
FBXへ書き出すこともできる。
しかし、
指示した動作をゲームで使用できる精度で再現できなかった。
まとめ
今回の検証によって、Tripoは単に3Dモデルを生成するだけのAIではなく、
3Dモデル生成
↓
Auto Rig
↓
プリセットアニメーション適用
↓
複数アニメーションの選択
↓
アニメーション付きFBX出力
↓
Blenderへの受け渡し
までを、一つの制作環境の中で行えることが確認できた。
特に、前回の実験ではAuto Rigによる骨格生成までしか確認できなかったが、今回は同じ dance_02 を実際にパンタへ適用し、正常に動作させることができた。
さらに複数のアニメーションを一つのFBXへ格納し、Blenderでそれぞれを独立したActionとして確認できたことは、ゲームキャラクター制作を考える上で大きな成果である。
一方、AIによるオリジナルアクション生成については異なる結果となった。
AIは「ジャンプ」「走る」といった言葉をある程度理解し、それに対応する身体運動を生成している。
しかし、
ジャンプしても地面から離れない。
走らせても歩く。
という結果では、ゲーム用アニメーションとしてそのまま採用することはできない。
今回の検証では、
TripoのAuto Rigとプリセットアニメーションは利用できる。
しかし、
AIによるオリジナルアクション生成は、現時点ではパンタのゲーム制作には実用できない。
という明確な違いが確認された。
次の段階では、Tripoだけですべてを完成させることにこだわる必要はない。
Tripoで生成したパンタモデルとリグを利用しながら、必要に応じてBlenderやMixamoなどを組み合わせ、
実際にゲームで使用できるアニメーション制作工程
を検討していく。
また今回、FBXでエクスポートしたモデルでは、以前のOBJによる検証とは異なるテクスチャ構成が確認された。
この問題については今回のリギング・アニメーション検証とは分け、改めて検証することとする。
第6回 AIが生成した3Dモデルの内部構造を調べる
AIゲーム開発研究室
3Dモデル制作ドキュメント
第6回 AIが生成した3Dモデルの内部構造を調べる
研究代表 大川 博
主任研究員 Arc（ChatGPT）
はじめに
前回は、パンタの3Dモデルをゲーム用に軽量化するため、3種類のモデルを制作した。
Aタイプは、最初から低ポリゴン設定で生成したモデル。
9,826 faces
Bタイプは、高密度設定で生成したオリジナルモデル。
1,965,676 faces
Cタイプは、BタイプをSmart Retopoによって軽量化したモデル。
14,204 faces
この3モデルをTripo Studio上で比較すると、興味深い違いが見つかった。
Aタイプは約1万facesという低ポリゴンでありながら、パンタの基本形状を十分に再現していた。
一方、約196万facesのBタイプでは、全身に細かな凹凸があり、毛並みの印象が強く表現されていた。
そして最も興味深かったのがCタイプである。
約196万facesから約1万4千facesまで大幅に削減されているにもかかわらず、Tripo Studio上では、AタイプよりもBタイプに近い毛並みを維持しているように見えた。
なぜなのか。
前回は、その疑問を残したところで終了した。
今回は、A・B・CのモデルをBlenderへ読み込み、実際の3Dデータを調べる。
約196万facesは、どこに使われているのか。
AタイプとCタイプでは、内部のメッシュ構造がどのように違うのか。
そして、Cタイプはなぜ高密度モデルに近く見えるのか。
Tripo Studio上の完成した外観を見るだけではなく、その内部へ入って検証することにした。
1 3DモデルをBlenderへ読み込む
まず、TripoからエクスポートしていたモデルをBlenderへ読み込んだ。
今回使用するのは、前回制作したA・B・Cの3モデルである。
Aタイプ
Panta_Apose_9826faces_Direct
Bタイプ
Panta_Apose_HD_1965676faces_original
Cタイプ
Panta_Apose_14204faces_SmartRetopo
Blenderへ読み込めば、Tripo Studio上では分からなかったメッシュそのものを直接確認できる。
そこで、まずワイヤーフレームを表示して、モデル表面がどのようなポリゴンで構成されているのかを調べることにした。
（なお、マテリアル、テクスチャ関連による問題は、第10回に詳しく検証します。）
2 Aタイプのメッシュを見る
最初に確認したのは、最初から低ポリゴン設定で生成したAタイプである。
Aタイプは、
9,826 faces
で構成されている。
ワイヤーフレームを表示すると、頭、顔、胴体、腕、リュックなどが比較的大きな三角形のポリゴンによって構成されていることが確認できた。
特に顔やリュック周辺を見ると、キャラクターの形状を維持するために必要な部分へポリゴンが配置されていることが分かる。
Tripo Studio上では十分に滑らかなモデルに見えていたが、メッシュそのものを見ると、約1万facesという限られたポリゴン数の中で立体形状が作られていることがよく分かる。
つまりAタイプでは、
約1万facesを使って、パンタそのものの立体形状を構成している
と考えることができる。
3 Cタイプのメッシュを見る
次に、Smart Retopoによって生成されたCタイプを確認した。
Cタイプは、
14,204 faces
である。
Aタイプの9,826 facesよりは多いが、どちらも1万faces台のモデルである。
しかしワイヤーフレームを比較すると、AタイプとCタイプは単純に同じモデルのポリゴン数だけを変えたものではないことが分かる。
特に腕、脇、肩、リュック周辺を拡大して確認した。
Aタイプでは、最初から低ポリゴンモデルとして3D形状が構成されている。
一方Cタイプは、約196万facesの高密度モデルを一度生成し、それをSmart Retopoによって再構成したモデルである。
実際に腕と胴体の間を確認すると、どちらも腕は胴体から独立しており、リギングを行うために必要となる空間も維持されている。
Smart Retopoによる大幅なポリゴン削減を行っても、今回のモデルでは、Aポーズ4面図によって作られた腕と胴体の基本的な位置関係は失われていなかった。
これは、今後リギングとアニメーションへ進むうえでも重要な結果である。
4 では、毛並みの違いはどこから来るのか
ここで問題になるのが、前回から残っていた疑問である。
AタイプとCタイプは、どちらも1万faces台である。
それにもかかわらず、Tripo Studio上ではCタイプの方が、高密度のBタイプに近い毛並みを持っているように見えた。
当初は、
Smart Retopoによって、高密度モデルの細かな凹凸が効率よく低ポリゴンへ置き換えられたのではないか
とも考えた。
しかしBlenderでモデルを調べていくと、それだけでは説明できないことが分かってきた。
3Dモデルの見た目を作っているのは、ポリゴンだけではなかった。
Tripoからエクスポートされたモデルには、3Dメッシュとともに複数のテクスチャ画像が含まれていたのである。
5 Tripoから出力されていた4種類のテクスチャ
エクスポートされたデータを確認すると、モデル本体とは別に、
Base Color
Normal
Metallic
Roughness
に相当する情報が含まれていた。
Base Colorは、パンタの白黒の毛、青いリュック、緑のスカーフなど、基本的な色を表現する。
Normal Mapは、実際のポリゴンを増やさなくても、表面に細かな凹凸があるように見せるための情報として利用できる。
Metallicは、表面がどの程度金属的に振る舞うかを制御する。
Roughnessは、表面の粗さ、つまり光の反射の広がり方を制御する。
ここで、Cタイプが高密度モデルに近く見えていた理由を調べるための重要な手掛かりが見つかった。
6 Blenderへ読み込んだ直後のパンタが「飴細工」に見えた
Blenderへ最初にモデルを読み込んだとき、一つ気になることがあった。
パンタの表面が非常にテカテカして見えたのである。
毛で覆われたキャラクターというより、
飴細工のような質感
に見えた。
当初は、
「なぜTripoはこんな質感にしているのだろう」
と思った。
しかしマテリアルノードを確認すると、Blender上ではBase Colorだけが接続された状態になっており、Tripoから出力されていたほかのテクスチャ情報が、すべて同じように再現されているわけではなかった。
つまり、Blenderへモデルを読み込んだだけでは、Tripo Studio上で見ていたマテリアル表現がそのまま完成した状態で再現されるとは限らない。
そこで、テクスチャを一つずつ確認しながら、BlenderのPrincipled BSDFへ接続していくことにした。
7 Normal Mapを接続する
まずNormal Mapを接続した。
Normal用の画像テクスチャをNormal Mapノードへ接続し、その出力をPrincipled BSDFのNormalへ入力した。
最初に強さを大きく設定すると、パンタの表面に非常に激しい凹凸が現れた。
まるで全身が鋭く隆起したような状態になった。
これは、Normal Mapの効果そのものを確認するには非常に分かりやすい結果だった。
そこで強さを下げ、
0.25
と
0.5
でも比較した。
強さを弱めることで極端な凹凸は抑えられ、毛並みとして自然に感じられる範囲へ近づいていった。
ここで重要なのは、ポリゴンそのものを増やしたわけではないということである。
同じCタイプのメッシュでも、Normal Mapを使用することで、表面に細かな凹凸が存在するような見え方を作ることができた。
低ポリゴンモデルの外観は、ポリゴン数だけでは決まらない。
このことを、実際のモデル上で確認することができた。
8 RMテクスチャを調べる
次に、もう一つのテクスチャを調べた。
この画像は、そのまま一つの色画像として使用するものではなく、複数の情報をRGBチャンネルへ格納している可能性がある。
そこでBlenderの**「カラー分離」**ノードを使用し、RGBの各チャンネルを分離した。
そして、それぞれをPrincipled BSDFの
Metallic
Roughness
へ接続して、モデルの変化を確認した。
接続すると、それまで不自然にテカテカしていたパンタの表面が大きく変化した。
黒い毛、白い毛、リュックなどの表面反射が抑えられ、最初に見えていた「飴細工」のような印象が弱くなった。
Normal Mapだけではなく、表面の反射を制御する情報も、Tripo Studio上のパンタの見え方を構成していたのである。
9 テクスチャを接続するとパンタが戻ってきた
Base Color。
Normal Map。
MetallicとRoughnessに使用される情報。
これらを組み合わせると、Blender上のパンタは、最初に読み込んだときとは大きく異なる外観になった。
特にリュックを拡大すると、その違いが分かりやすい。
青い色が付いているだけではない。
縫い目、表面の細かな凹凸、光沢の違いなどによって、リュックという素材の質感が作られている。
同じことがパンタの毛にも起きている。
ここで、3Dモデルを見るときに、
「ポリゴン数が多いから高品質」
「ポリゴン数が少ないから低品質」
と単純には判断できない理由が見えてきた。
モデルの外観は、
メッシュ形状とテクスチャ情報の組み合わせ
によって作られている。
10 AタイプとCタイプの腕・脇を比較する
次に、ゲームキャラクターとして重要になる部分を確認した。
AタイプとCタイプについて、腕、肩、脇の内部構造をワイヤーフレームで比較した。
Aタイプは、最初から9,826 facesで生成されたモデルである。
Cタイプは、高密度モデルからSmart Retopoによって14,204 facesへ軽量化されたモデルである。
どちらも腕は胴体から分離しており、脇には空間が確保されている。
これは、以前制作した通常ポーズの3Dパンタとは大きく異なる。
今回使用したAポーズ4面図によって、腕を動かすための空間を2D資料の段階から用意したことが、低ポリゴン化した後のモデルにも反映されている。
もちろん、実際にアーマチュアを入れて腕を動かしたときに、どのように変形するかはまだ分からない。
しかし少なくとも静止状態のメッシュを見る限り、
Aポーズ4面図 → 3D生成 → Smart Retopo
という工程を経ても、腕と胴体を分離した基本構造は維持されていた。
11 約196万facesは何をしていたのか
今回の確認によって、前回生まれた疑問にも少しずつ答えが見えてきた。
Bタイプの約196万facesは、パンタの基本的なシルエットだけを作るために使われているわけではない。
高密度モデルでは、毛並みなどの細かな表面形状までメッシュとして表現されている。
一方Cタイプでは、その高密度モデルをSmart Retopoによって14,204 facesまで削減している。
それでも外観が大きく失われなかった背景には、低密度化されたメッシュだけではなく、Normal Mapなどのテクスチャ情報が見た目に寄与していることが、今回のBlender上の確認から見えてきた。
ただし、
高密度モデルのどの情報をSmart Retopoがどのように低密度メッシュや各テクスチャへ受け渡しているのか
という内部処理そのものまでは、今回の観察だけから断定することはできない。
ここは重要なので、AI内部の処理を推測だけで結論づけないことにする。
今回確認できたのは、生成された結果である。
12 AI3Dモデル制作からAI3Dモデル制作研究へ
今回の作業を始めた目的は、もっと単純だった。
パンタの3Dモデルをゲームで使えるようにしたい。
そのためにポリゴン数を減らしたい。
それだけだった。
ところが、
高密度モデルを作る。
低ポリゴンモデルを作る。
Smart Retopoを行う。
3モデルを比較する。
Blenderへ読み込む。
メッシュを見る。
テクスチャを見る。
Normal Mapを接続する。
MetallicとRoughnessを確認する。
という工程を進めるうちに、調べている対象そのものが変わってきた。
単に、
「AIを使って3Dモデルを作る」
だけではなく、
「AIは3Dモデルをどのようなデータとして生成しているのか」
を調べ始めている。
これは、当初考えていた「AI3Dモデル制作ドキュメント」から、少しずつ、
AI3Dモデル制作研究
へ近づいているのかもしれない。
まとめ
今回、A・B・Cの3モデルをBlenderへ読み込み、Tripo Studio上の外観だけでは分からなかった内部構造を調べた。
そこで最も重要だったのは、
3Dモデルの見た目は、ポリゴン数だけで決まっているのではない
ということである。
高密度モデルでは、細かな毛並みまで実際の形状として作られている。
しかし、それをSmart Retopoによって大幅に軽量化したCタイプでも、Normal Mapなどの情報を利用することで、細かな表面表現を視覚的に維持できることが確認できた。
さらに、MetallicやRoughnessに関係する情報を適切に使用すると、Blenderへ読み込んだ直後に感じた不自然な光沢も大きく変化した。
そしてAタイプとCタイプのメッシュを比較すると、どちらも腕と胴体の間に空間が確保されていた。
これまで制作してきた、
Aポーズ4面図
が、単に3Dモデルを生成するためだけではなく、その後の低ポリゴン化を経ても、動かすことを想定した身体構造を維持するための資料として機能していることも確認できた。
今回の実験によって、
2Dキャラクター画像
↓
Aポーズ4面図
↓
高密度3Dモデル
↓
AIによるリトポロジー
↓
低ポリゴンメッシュ
↓
テクスチャによる表面情報の再現
という、一連の制作工程が見えてきた。
ただし、まだパンタは動いていない。
ゲームキャラクターとして本当に使えるかどうかを判断するためには、次の工程が必要である。
次回へ
次に確認するのは、いよいよリギングとアニメーションである。
約1万faces台まで軽量化したパンタへ骨格を入れ、実際に腕や脚を動かす。
そこで初めて、
Aポーズによって確保した脇の空間は正しく機能するのか。
Smart Retopoされたメッシュは、アニメーションによる変形に耐えられるのか。
テクスチャは、モデルが動いても自然に維持されるのか。
という問題を確認できる。
パンタは、2Dイラストから3Dモデルになった。
そして今回、その3Dモデルの内部まで見ることができた。
次に必要なのは、
そのパンタを、本当に動かすことである。
第5回 3Dゲームモデルのポリゴン数を削減する
AIゲーム開発研究室
3Dモデル制作ドキュメント
第5回 3Dゲームモデルのポリゴン数を削減する
研究代表 大川 博
主任研究員 Arc（ChatGPT）
はじめに
前回は、3Dモデル制作を目的としたパンタのAポーズ4面図を新たに制作し、TripoのMulti-viewへ入力した。
その結果、両腕が胴体から独立し、リュックやしっぽなども立体形状として成立した3Dモデルを生成することができた。
しかし、生成されたモデルには新たな問題があった。
約196万faces
という非常に高密度なモデルになったことである。
高品質な3Dモデルとしては良好な結果だったが、ゲームキャラクターとして使用することを考えると、そのまま使用するにはポリゴン数が多い。
そこで今回は、パンタの外観をできるだけ維持しながら、ゲームで使用できる程度までポリゴン数を削減できるかを検証する。
その過程で、
最初から低ポリゴンで生成したモデル
と、
高密度モデルを生成してからAIで軽量化したモデル
では何が違うのか、という新たな比較実験を行うことにした。
1 最初から約1万facesでパンタを生成する
まず、高密度モデルを軽量化する前に比較対象を作ることにした。
前回使用したものと同じパンタのAポーズ4方向画像をTripoのMulti-viewへ入力する。
基本的な生成条件は高密度モデルを制作したときと同じにし、ポリゴンカウントだけを10,000に設定した。
生成されたパンタは、
9,826 faces
6,843 vertices
となった。
設定値10,000に対して、実際には9,826 facesのモデルが生成されたことになる。
モデルを正面、側面、背面、上面、下面から確認した。
顔、耳、腕、脚、リュック、しっぽなど、パンタを構成する主要な形状は良好に生成されている。
約1万facesというポリゴン数でありながら、キャラクターモデルとして十分に成立しているように見える。
Aタイプ
Direct生成モデル
9,826 faces / 6,843 vertices
この段階で、パンタのような比較的単純な形状のキャラクターであれば、最初から約1万faces程度でもかなり良好なモデルを生成できる可能性が確認できた。
2 約196万facesの高密度モデルを比較基準とする
次に、前回制作した高密度モデルを比較基準とした。
このモデルは、
1,965,676 faces
1,021,933 vertices
という非常に高密度なモデルである。
Bタイプ
高密度オリジナルモデル
1,965,676 faces / 1,021,933 vertices
Aタイプと比較すると、キャラクター全体の基本形状については大きな違いを感じない。
一方、頭部、耳、腕、腹部、脚などを見ると、高密度モデルでは表面に細かな凹凸が見られ、毛並みの印象が強くなっている。
ここで一つの疑問が生まれた。
約196万facesという膨大なポリゴンは、パンタの基本形状を作るためではなく、毛並みなどの細かな表面形状を表現するために多く使われているのではないか。
ただし、Tripo Studio上で外観を観察しただけでは、その内部構造までは分からない。
この点については、後にBlenderで実際のメッシュを確認することにする。
3 高密度モデルを保存する
高密度モデルへリトポロジーを行う前に、元のモデルを失わないよう保存することにした。
まずTripoから高密度モデルをOBJ形式でエクスポートした。
エクスポートされたZIPには、OBJモデル本体のほか、
Base Color
Metallic
Normal
Roughness
などのテクスチャデータも含まれていた。
さらにTripo Studio内でも「Save a Copy」を使用し、高密度モデルを複製した。
これにより、
保存用の高密度オリジナル
と、
リトポロジー実験用のコピー
を分けることができた。
これ以降の軽量化実験は、複製したモデルを使用して行う。
4 Smart Retopoで約1万facesへ軽量化する
複製した高密度モデルに対して、Tripoのリトポロジー機能を使用した。
今回は単純にポリゴンを削減するのではなく、
Smart Low Poly v2
を使用した。
設定は、
Topology：Triangle
Smart Low Poly v2：ON
Polygon Count：10,000
とした。
約196万facesの高密度モデルを、約1万facesまで一気に軽量化する実験である。
処理後に生成されたモデルは、
14,204 faces
16,687 vertices
となった。
10,000を指定したが、実際に生成されたモデルは14,204 facesとなった。
したがって、今回の記録では設定値ではなく、実測値14,204 facesとして扱う。
5 約196万facesから約1万4千facesへ
Smart Retopoによって生成されたモデルを、正面、左右側面、背面、上面、下面から確認した。
Cタイプ
Smart Retopoモデル
14,204 faces / 16,687 vertices
結果は予想以上に良好だった。
約196万facesから約1万4千facesまで大幅に削減されているにもかかわらず、パンタの顔、体形、腕、脚、リュック、しっぽなどの主要形状はかなり良好に維持されている。
Tripo Studio上で見る限り、高密度モデルとの外観上の差は、ポリゴン数の違いから想像していたほど大きくなかった。
約196万facesから約1万4千facesへの削減である。
ポリゴン数は元モデルの1％にも満たない。
それでも、キャラクターとしてのパンタの印象はほとんど失われていない。
6 A・B・Cの3タイプを比較する
今回、比較のために3種類のパンタが完成した。
Aタイプ
最初から低ポリゴン設定で生成
9,826 faces
Bタイプ
高密度設定で生成
1,965,676 faces
Cタイプ
BタイプをSmart Retopoで軽量化
14,204 faces
3タイプを同じ6方向から観察した。
ここで興味深い違いが確認できた。
Aタイプは約1万facesしかないにもかかわらず、顔、体形、リュックなどの形状は良好に生成されている。
しかし、高密度のBタイプと比較すると、毛並みの印象が異なる。
Aタイプでは表面が比較的滑らかに見える。
一方、Bタイプでは細かな表面の凹凸によって、毛並みのモフモフした印象が強く感じられる。
さらに興味深いのがCタイプである。
Cタイプも約1万4千facesまで削減されているにもかかわらず、Tripo Studio上で見ると、AタイプよりBタイプに近い毛並みの印象を維持しているように見える。
つまり、
最初から約1万facesで生成したモデル
と、
約196万facesの高密度モデルから約1万4千facesへ軽量化したモデル
は、単純にポリゴン数が近いからといって、同じ外観になるわけではなかった。
これは今回の実験で得られた最も興味深い結果の一つである。
7 なぜCタイプは高密度モデルに近く見えるのか
ここで新しい疑問が生まれた。
なぜ約1万4千facesしかないCタイプが、約196万facesのBタイプに近い毛並みを維持しているように見えるのか。
高密度モデルが持っていた細かな形状を、Smart Retopoが効率的に低密度メッシュへ再構築している可能性もある。
一方で、Normal Mapなどのテクスチャ情報が見た目に大きく寄与している可能性もある。
あるいは、その両方かもしれない。
現段階ではTripo Studio上の表示だけを観察しているため、原因を断定することはできない。
そこで、この疑問そのものを次の実験課題とすることにした。
8 3タイプをエクスポートする
A・B・Cの3モデルを、比較実験用としてすべてTripoからエクスポートした。
ファイル名は、それぞれの生成方法と実測faces数が分かるようにした。
Aタイプ
Panta_Apose_9826faces_Direct
Bタイプ
Panta_Apose_HD_1965676faces_original
Cタイプ
Panta_Apose_14204faces_SmartRetopo
これにより、Tripo Studio上の外観比較だけではなく、3モデルをBlenderへ読み込み、実際の3Dデータそのものを比較できる準備が整った。
まとめ
今回の実験では、パンタの3Dモデルをゲーム用に軽量化するため、3種類のモデルを制作した。
最初から約1万facesで生成したAタイプは、低ポリゴンでありながら、パンタの基本形状を十分に再現することができた。
高密度のBタイプでは、約196万facesを使用することで、特に毛並みなどの細かな表面表現が強く現れた。
そしてBタイプをSmart Retopoで軽量化したCタイプは、14,204 facesまで削減されたにもかかわらず、高密度モデルに近い外観をかなり維持した。
ここから、単純に、
「ゲーム用だから最初から低ポリゴンで生成すればよい」
とも、
「高密度モデルを作る必要がある」
とも、まだ結論づけることはできない。
むしろ今回の結果によって、
最初から低ポリゴンで生成する方法と、高密度モデルを生成してからAIで軽量化する方法では何が違うのか
という、より重要な研究課題が生まれた。
見た目だけでは、その答えは分からない。
次に確認する必要があるのは、モデルの内部構造である。
次回へ
次回は、今回エクスポートしたA・B・Cの3モデルをBlenderへ読み込む。
ワイヤーフレーム表示などを使用し、
約196万facesは実際にどこに使われているのか。
AタイプとCタイプでは、ポリゴンがどのように配置されているのか。
Cタイプの毛並みが高密度モデルに近く見える理由は何なのか。
メッシュ、マテリアル、Normal Mapを含むテクスチャ情報などを実際の3Dデータから比較する。
今回、約196万facesから約1万4千facesへ削減しても、外観上は大きな違いを感じないモデルが生成された。
では、その内部では何が起きているのか。
次回はBlenderを使用して、その違いを検証する。
第4回 Aポーズ4面図から3Dモデルを生成する
AIゲーム開発研究室
3Dモデル制作ドキュメント
第4回 Aポーズ4面図から3Dモデルを生成する
研究代表 大川 博
主任研究員 Arc（ChatGPT）
はじめに
前回は、パンタのキャラクター公式4面図をTripoのMulti-viewへ入力し、3Dモデルを生成した。
その結果、1枚の画像から生成した場合に比べて、正面・側面・背面の情報を反映した3Dモデルを制作できることを確認した。
一方で、新たな問題も明らかになった。
従来の公式4面図では、パンタの両腕が胴体の前方に配置されている。
そのため生成された3Dモデルでも腕が胴体に近接し、リギングやアニメーションを行うゲームキャラクターとして考えた場合、この形状のまま進めてよいのかという疑問が生じた。
そこで今回は、Tripo側でTポーズ化できる可能性を調査するとともに、別の方法として、3Dモデルを生成する前の2D画像そのものをAポーズにすることを試みた。
そのために新たなAポーズ4面図を制作し、それをTripoへ入力して3Dモデルを生成した。
結果として、今後の3Dゲームキャラクター制作につながる重要な成果を得ることができた。
1 従来の公式4面図で生じた問題
これまで「おむすび山のなかまたち」では、ゲーム、絵本、イラストなどで共通して使用するため、パンタのキャラクター公式4面図を制作していた。
この4面図は、
正面
右側面
背面
左側面
からキャラクターデザインを確認するための公式資料である。
しかし、もともと3Dモデルのリギング専用資料として制作したものではない。
そのため、パンタの腕は自然な立ち姿として胴体の前方に配置されていた。
前回、この4面図をTripoのMulti-viewへ入力して3Dモデルを生成した。
3Dモデルそのものは良好に生成されたが、2D画像のポーズを反映して、腕が胴体に近接した状態になった。
ここで、
3Dモデルを生成した後でポーズを変更するのか。
それとも、
3Dモデルを生成する前に、リギングに適したポーズの2D資料を作るべきなのか。
という新しい問題が生まれた。
2 TripoでTポーズ化できるのか
まず、すでに生成した3DパンタをTripo側でTポーズ化できる可能性を調べることにした。
Tripo Studioのモデル生成画面を調べると、実際に**「Tポーズ」**という項目が存在した。
ところが、実際に操作してみると、このTポーズ項目は4方向の画像を入力するMulti-view画面には表示されなかった。
Multi-view側の設定項目を最下部まで確認したが、今回使用した画面ではTポーズを指定する項目を確認できなかった。
Tripoの公式情報についても調査した。
Tポーズは、キャラクターをリギングやアニメーションに適した標準ポーズへ変換するための機能として用意されている。
一方、Multi-viewでは複数方向の画像を入力して3Dモデルを生成する仕様となっており、今回確認したStudio上では、
4面図をMulti-viewへ入力しながら、同時にTポーズを指定する
という操作方法は確認できなかった。
ここで、別の方法を検討することにした。
3 既存3DモデルにAuto Rigを実行する
すでに完成している従来の3Dパンタについても実験を行った。
Tripoの「アニメイト」を開き、二足歩行キャラクター用として、
v1.0 ― Humanoid
を選択した。
その状態でAuto Rigを実行した。
すると、パンタの3Dモデルには実際にアーマチュアが生成された。
骨格表示をONにすると、胴体、腕、脚などに骨格が配置されていることも確認できた。
ここで重要なことが分かった。
Auto Rigを実行しても、パンタ自身のポーズがTポーズへ変化することはなかった。
腕を前方に置いた元の姿勢のまま、その形状に合わせて骨格が配置されたのである。
つまり今回の実験では、
Auto Rigを実行することと、3DモデルをTポーズ化することは別の処理である
ことが確認できた。
さらにプリセットアニメーション dance_02 の適用処理も試したが、今回の環境では正常なアニメーションを画面上で確認するところまでは至らなかった。
この結果だけから原因を断定することはできない。
しかし、今後リギングやアニメーションを行うゲームキャラクターとして考えるなら、腕と胴体が十分に分離したモデルを最初から制作する方が適していると考えた。
4 新しいAポーズ正面画像を制作する
そこで発想を変更した。
3Dモデルを生成した後で腕を動かすのではなく、
3Dモデル生成へ渡す2D画像の段階で、腕を胴体から離しておく。
そのため、新たにパンタのAポーズ正面画像を制作した。
従来のキャラクターデザインや体形は維持しながら、両腕を自然に左右へ広げ、胴体との間に明確な空間を設けた。
この画像を、新しい3Dモデル制作のキャラクター基準画像とした。
5 画像生成AIでAポーズ4面図を制作する
次に、このAポーズ正面画像から4面図を制作した。
ここでも一つの試行錯誤があった。
当初は、
「90度回転」
「正投影」
「形状を完全に一致させる」
など、3D設計図に近い指示を画像生成AIへ与える方法を試した。
しかし、指示を厳密にするほど、生成を繰り返す中で輪郭や体形が変化し、パンタ本来のデザインから離れていく傾向が見られた。
そこで指示方法を変更した。
厳密な3D設計図として描かせるのではなく、キャラクターデザインシートとして4方向を描かせることにした。
その際、新しいAポーズ正面画像をキャラクターデザインと体形の基準とし、従来の公式4面図については、4方向を一枚に配置するための構成資料として使用した。
また、「90度回転」「正投影」「機械的な完全一致」といった指示は使用しなかった。
その結果、
正面・右側面・背面・左側面を配置したAポーズ4面図を、最初の生成で採用可能な状態まで制作することができた。
今回、この画像生成が成功したこと自体も重要な実験結果となった。
画像生成AIに3D設計図のような厳密な回転を要求するのではなく、キャラクターデザイン資料として複数方向を描かせることで、キャラクター性を維持した4面図を得られる可能性が示された。
6 4方向画像をTripoへ入力する
完成したAポーズ4面図を、TripoのMulti-viewで使用するため、
正面
右側面
背面
左側面
の4枚の画像として準備した。
【画像⑦配置 Aポーズの正面・右側面・背面・左側面4枚】
画像説明：Tripo Multi-viewへ入力するために用意したパンタAポーズ4方向画像
これらをTripoの各方向へ配置した。
今回はまず3D形状そのものを十分に確認するため、高品質設定で生成することにした。
Ultra mesh qualityを有効にし、テクスチャ4K、PBRなどを使用して3Dモデルを生成した。
7 Aポーズ3Dパンタの生成に成功する
生成されたモデルを正面から確認した。
結果は非常に良好だった。
特に重要なのは両腕である。
従来モデルでは腕が胴体に近接していたのに対し、今回のモデルでは、
左右の腕が肩から手先まで独立した立体形状として生成され、胴体との間に明確な空間が形成された。
さらにモデルを回転させ、背面を確認した。
青いリュックについても立体的に生成され、前面ポケット、側面ポケット、肩ベルト、上部ハンドルなどが再現されている。
しっぽも独立した形状として生成された。
側面や斜め方向から確認すると、今回の目的がさらに明確に確認できた。
腕と胴体の間には空間があり、腕とリュックも大きく融合していない。
Aポーズ4面図で設計した腕の位置関係が、3Dモデルにも反映されたのである。
8 テクスチャには一部問題が残った
3D形状については良好な結果が得られたが、テクスチャには一部不自然な部分も確認された。
特に腹部と脚の境界付近などに、元画像にはない黒いにじみのような部分が発生している。
目などについても、元の2Dイラストより立体的な表現になっている。
ただし、今回の段階で最も重要なのは、ゲームキャラクターとして必要になる3D形状が成立するかどうかである。
その点では、頭部、胴体、脚、腕、リュックなどが立体として成立し、特に両腕が胴体から独立したことは大きな成果である。
したがって、今回はテクスチャ上の問題を理由としてモデルを作り直すことはしない。
9 残る大きな課題はポリゴン数
今回生成された3Dモデルは、
約196万フェイス
約102万頂点
という非常に高密度なモデルになった。
高品質な3Dモデルとして外観を確認するには十分であるが、そのままゲームへ使用するにはポリゴン数が多い。
逆に考えれば、今回生成したモデルについて、
外観を維持したままポリゴン数をゲーム用まで削減できれば、そのままゲームキャラクターとして使用できる可能性がある。
ここまで来ると、次の課題はかなり明確である。
新しいキャラクターを作り直すことではない。
現在のパンタを、ゲームで動かせるモデルへ最適化すること
である。
まとめ
今回の実験では、3Dモデル生成AIそのものだけではなく、3D生成AIへ渡す2D資料の作り方が重要であることが分かった。
従来の公式4面図は、ゲーム、絵本、イラストなどで共通するキャラクターデザイン資料として制作したものであり、その目的には十分機能している。
しかし、動かすことを前提とした3Dゲームキャラクターを制作する場合には、腕と胴体の位置関係など、3D化後のリギングを考慮した資料が必要になる。
そこで今回は、画像生成AIを使用して新たなAポーズ4面図を制作した。
さらに、その画像をTripo Multi-viewへ入力した結果、両腕が胴体から独立した3Dモデルを生成することができた。
今回の実験から、次の制作工程が見えてきた。
キャラクター基準画像
↓
画像生成AIによるAポーズ基準画像の制作
↓
画像生成AIによるAポーズ4面図の制作
↓
人間による生成結果の確認・採択
↓
4方向画像の準備
↓
Tripo Multi-viewによる3Dモデル生成
↓
3D形状の確認
↓
ポリゴン削減
↓
リギング・アニメーション
↓
ゲームエンジンへの実装
今回制作したAポーズ4面図は、単なるキャラクター設定資料ではない。
2Dキャラクターデザインと、動かすことを前提とした3Dゲームキャラクターとの間をつなぐ中間設計資料
として機能した。
そしてもう一つ重要なのは、画像生成AIと3D生成AIの関係である。
画像生成AIで完成画像を作り、3D生成AIで別のものを作るのではない。
次のAI工程が必要とする入力資料を、前のAI工程で制作する。
今回、
画像生成AI → Tripo
というAI間の受け渡しによって、2Dキャラクターからゲーム利用を想定できる3Dモデルまで進むことができた。
次回は、今回生成した高密度3Dモデルをゲームで使用できる状態へ近づけるため、ポリゴン数の削減とモデルの最適化を検証する。
