AIゲーム開発研究室
第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モデルをゲームで使用できる状態へ近づけるため、ポリゴン数の削減とモデルの最適化を検証する。
第3回 キャラクター公式4面図から3Dモデルを制作する
AIゲーム開発研究室
3Dモデル制作ドキュメント
第3回 キャラクター公式4面図から3Dモデルを制作する
研究代表 大川 博
主任研究員 Arc(ChatGPT)
はじめに
前回は、1枚のキャラクター画像からTripoを使って3Dモデルを生成し、生成後のモデルに対する各種処理を確認した。
そして、今後も本格的に3Dモデル制作を進めるため、最後にTripoを有料プランへ切り替えた。
今回は、その続きである。
これまで「おむすび山のなかまたち」のキャラクター制作では、ゲーム、絵本、イラストなどで共通して使用するためのキャラクター公式4面図を制作してきた。
そこで今回は、新たに3D専用の画像を作るのではなく、まず、このすでに完成しているパンタの公式4面図をそのままTripoへ入力して、3Dモデルを制作してみることにした。
ここから、実際のゲームで使用するパンタの3Dモデル制作を進めていく。
1 パンタのキャラクター公式4面図を使用する
今回使用したのは、パンタの
正面
右側面
背面
左側面
の4枚である。
これらは、もともと3Dモデル制作専用に制作した画像ではない。
パンタというキャラクターのデザインを確定し、さまざまな制作で共通して使用するために作った公式デザイン資料である。
そのため、3Dモデリングで使用される一般的な設計図のように、正面、側面、背面の形状が厳密に一致しているわけではない。
側面図を比較しても、身体の厚み、脚の位置、脚の角度などには多少の違いがある。
しかし前回、Tripoが1枚の正面画像だけから、画像には描かれていない側面や背面まで推測して3Dモデルを生成したことを確認している。
それならば、完全には一致していなくても、4方向の情報があれば、AIがそれぞれの画像を解釈して一つの立体としてまとめることができるのではないか。
今回は、そのまま制作を進めることにした。
2 4面図をTripoへ入力する
パンタの公式4面図をTripoへ入力し、マルチビューによる3Dモデル生成を行った。
ここで重要なのは、今回使用している4枚が、3D生成のために新しく描き直したものではないということである。
すでにキャラクター制作の工程で完成していた公式資料を、そのまま3Dモデル制作へ受け渡している。
つまり、
2Dキャラクターデザインで制作した公式資料を、そのままAIによる3D制作へ利用する
という工程になる。
AIを中心としたゲーム開発では、一つの工程のためだけに素材を作るのではなく、すでに制作した情報を次のAIへ受け渡していくことができる。
今回の4面図は、その実例となった。
3 公式4面図から3Dモデルが生成された
生成を実行すると、パンタの3Dモデルが完成した。
3Dモデル専用に厳密な4面図を作ったわけではない。
それでもTripoは、4枚の画像に含まれる情報を一つのキャラクターとして解釈し、立体としてまとめている。
正面だけでなく、頭部の厚み、胴体、手足、背中、リュックなども立体として構成された。
特に今回重要だったのは、
4枚の画像が製図のように完全一致していなくても、3Dモデルを生成できた
ということである。
もちろん、どの程度まで画像間の違いを許容できるのかは、今回だけで一般化することはできない。
しかし少なくともパンタについては、キャラクターデザイン用として制作した公式4面図から、実際に3Dモデルを制作することができた。
これは今後、ほかのキャラクターを3D化していくうえでも重要な結果である。
4 このモデルをゲームで使うにはどうするのか
3Dモデルそのものは生成できた。
しかし、ここで次の疑問が生まれた。
今回使用した公式4面図では、パンタは腕を曲げた通常の立ち姿をしている。
ゲームキャラクターとして使用するのであれば、今後、骨格を入れ、さまざまなアニメーションを行うことになる。
そこで、
現在の3Dモデルを、腕を開いたポーズへ変更できないのか。
という問題を検討することになった。
当初は、現在のモデルをそのまま利用してポーズだけを変更する方法が見つからず、
それならば、最初から腕を開いた画像を作り、その画像から3Dモデルを作り直した方がよいのではないか
と考えた。
そこで、新たな3Dモデル制作用画像の制作を始めることにした。
5 Aポーズのパンタを制作する
3Dモデル制作用の参照画像として、腕を真横に水平に伸ばすTポーズではなく、腕を斜め下へ開いたAポーズを採用することにした。
パンタは、人間型キャラクターではあるが、頭が大きく、胴体が丸く、手足が短いデフォルメされた動物キャラクターである。
そのため、腕を水平に伸ばした典型的なTポーズよりも、腕をやや下げて身体との間に空間を作るAポーズの方が、パンタ本来のプロポーションを保ちやすいと考えた。
そこで、既存の公式デザインを基準に、新たなAポーズ画像の制作を開始した。
(修正済み旧完成版)
6 腕を伸ばすと、腕が長くなった
ところが、ここで思わぬ問題が起きた。
元のパンタは腕を曲げている。
その腕を開いたポーズへ変更すると、生成されたパンタの腕が想定していたよりも長く見えたのである。
これは単純な画像生成AIの失敗として片づけることはできない。
ここで、2Dキャラクターそのものが持っている問題に気づいた。
平面イラストでは、「ウソ」を描くことができる。
これは悪い意味での「ウソ」ではない。
2Dイラストでは、そのポーズ、そのアングル、その画面で最も自然に見えるように、身体の形や長さを調整することができる。
腕を曲げているときには自然に見えていた長さが、そのまま腕を伸ばしたときにも正しいとは限らない。
一枚の平面イラストとして成立していた身体のバランスが、別のポーズに変更した瞬間に崩れることがある。
3Dモデル制作では、一つの身体をさまざまな方向から見て、さらにさまざまなポーズで動かすことになる。
そのため、2Dキャラクターを3D化するときには、単に元画像を忠実に立体化するだけではなく、
そのキャラクター本来のプロポーションとは何か
を改めて考える必要がある。
これは今回の制作で得られた重要な発見だった。
7 動いているパンタからプロポーションを確認する
そこで、新たな資料として使用したのが、すでに2Dゲーム素材として制作していた**「大喜びパンタ」**である。
この画像では、パンタが通常の立ち姿ではなく、身体を大きく動かしている。
ここで注意しておきたい。
大喜びパンタを参照したのは、生成された3Dモデルと比較するためではない。
あくまで、2D画像の中でパンタが大きく身体を動かしたときのプロポーションを確認するためである。
頭の大きさ。
丸い胴体。
腕の長さ。
脚の長さ。
手足の太さ。
これらを確認しながら、Aポーズになっても「パンタらしさ」が失われない身体バランスを検討した。
一枚の立ち絵だけをキャラクターの絶対的な設計図とするのではなく、すでに制作してきた複数のアクション画像も、3D化におけるプロポーション資料として利用できることが分かった。
8 Aポーズ4面図を制作する
プロポーションを確認しながら、
正面
背面
右側面
左側面
のAポーズ画像を制作した。
ここでも、すべてを完全に一致させることだけを目的にはしなかった。
正面図と背面図については、実際に画像を重ね合わせてシルエットを確認した。
多少の腕の角度の違いはあったものの、全体のシルエットはほぼ一致していた。
一方、左右側面の制作では、画像生成AIが腕の位置を正しく解釈できず、腕が3本になる、耳が増えて見えるなどの問題も発生した。
さらに修正を繰り返すにつれて、元の公式デザインにあった柔らかな水彩表現から離れ、輪郭線が強くなる傾向も見られた。
ここで、もう一つの判断が必要になった。
4面図の整合性を追求することと、キャラクターとして良い画像を作ることは、必ずしも同じではない。
Tripoは、先に使用した通常の公式4面図に多少の不一致があっても、一つの3Dモデルとしてまとめることができた。
そのため、製図のような完全一致を求めて画像そのものの品質を落とすよりも、一定の整合性を確保したうえで、パンタらしい良い画像を使用する方がよいのではないかと判断した。
最終的に、Aポーズの4方向画像を一組の資料として完成させた。
(プロポーションなどの問題により後日不採用となる)
9 ここで、もう一度Tripoを調べる
Aポーズ4面図は完成した。
この画像から新しい3Dモデルを生成することもできる。
しかし、その前にもう一度確認することにした。
本当に、すでに完成している3DモデルをTripo側でTポーズ化することはできないのか。
改めてTripoの機能を調べたところ、Tripoにはゲームキャラクター制作を想定したTポーズ化の工程が用意されていることが分かった。
つまり、
公式4面図からすでに制作したパンタ3Dモデルを利用したまま、Tripo側でTポーズ化できる可能性がある。
ここで制作方針を変更することにした。
せっかく完成したAポーズ4面図は、そのまま制作資料として保存する。
しかし、すぐにAポーズ4面図から新しい3Dモデルを生成するのではなく、まずはすでに完成しているパンタ3Dモデルへ戻る。
そして、そのモデルを残した状態で、TripoによるTポーズ化を試すことにした。
10 今回分かったこと
今回の制作では、パンタの公式4面図から実際に3Dモデルを制作することができた。
そして、その先へ進もうとしたことで、2Dキャラクターを3Dゲームキャラクターへ変換するときの新しい問題が見えてきた。
キャラクターデザイン用の4面図は、必ずしも3D用の厳密な設計図でなくても利用できる。
一方で、ポーズを変更すると、2Dイラストでは見えなかった身体比率の問題が表面化することがある。
そして、3D制作のために新しい画像を作り直す前に、使用する3D生成AIがどこまで後工程を行えるのかを確認することも重要である。
今回、Aポーズ4面図まで制作したあとで、Tripo側で既存モデルをTポーズ化できる可能性があることが分かった。
これは遠回りだったとも言える。
しかし、その過程があったからこそ、
「2Dで自然に見える身体」と「動かすことを前提とした身体」は、必ずしも同じではない
という問題を実制作の中で確認することができた。
AIを使った制作では、最初からすべての正解が分かっているわけではない。
作る。
結果を見る。
問題を見つける。
別の方法を試す。
そして、必要であれば前の工程へ戻る。
今回も、その繰り返しの中から次の制作方法が見えてきた。
次回
次回は、公式4面図からすでに制作したパンタ3Dモデルを残したまま、TripoでTポーズ化できるかを実際に確認する。
まず既存モデルを失わない方法を確認したうえで、Tポーズ化を行う。
さらに必要であれば、今回完成したAポーズ4面図から生成した3Dモデルとの比較も行いたい。
どちらの方法が、ゲームで実際に動かすパンタの3Dモデルとして適しているのか。
次の実制作で確認していく。















































































