Contact
AIゲーム開発研究室
第12回 Tripo Auto Rigの再検証 ― 手首の捻れと5本指リグの問題 ―
AIゲーム開発研究室
3Dモデル制作ドキュメント
第12回 Tripo Auto Rigの再検証
― 手首の捻れと5本指リグの問題 ―
研究代表 大川 博
主任研究員 Arc（ChatGPT）
はじめに
前回までの検証によって、Tripoで生成したパンタをMixamoへ送り、Mixamoのアニメーションを適用し、Blender、さらにUnityまで持ち込む一連の工程は成立した。
しかし、その過程で新たな問題が見つかった。
Mixamoのアニメーションを適用すると、パンタの手首が不自然に捻れる。
ゲーム用キャラクターとして使用する以上、この問題を放置することはできない。
そこで今回は、TripoのAuto Rigによって生成されたアーマチュアをBlender上で詳しく確認し、手首の捻れがどこから生じているのかを検証した。
さらにTripoの「再挑戦」を使用してAuto Rigをやり直し、同じモデルでもリグ生成結果が変化するのか、そしてMixamoでの手首の捻れが改善するのかを確認した。
結論を先に述べれば、再リグによって手首の大きな捻れは改善した。
しかし、別の問題が明らかになった。
パンタには存在しない5本指用のボーンが生成され、それが手のメッシュを変形させていたのである。
今回は、この問題について現時点で完全な解決方法を得ることができなかった。
そのため、本研究ではTripo Auto Rigをゲーム用パンタのリギング工程として採用することをいったん保留し、実制作ではMixamoによるリギングを使用することとした。
1 Mixamoアニメーションで発生した手首の捻れ
TripoのAuto Rigを使用したパンタにMixamoのアニメーションを適用したところ、手首が大きく捻れる現象が発生した。
そこでBlender上で、Tripoによって生成されたアーマチュアを詳しく確認した。
まず分かったのは、左右の腕から手にかけてのボーンが、単純な鏡像になっていないことである。
前腕と手のBone Rollを確認すると、次のような値になっていた。
LeftForeArm 約56°
LeftHand 約－2.1°
RightForeArm 約－123°
RightHand 約－130°
左右で大きく異なる値となっている。
さらに手を拡大して確認すると、パンタには人間のような独立した5本の指が存在しないにもかかわらず、人間型の指ボーンが生成されていた。
しかも左右の指ボーンの配置も、完全な鏡像にはなっていなかった。
2 指ボーンを削除して検証する
そこで、手首の捻れに指ボーンが関係している可能性を考え、Blender上で指ボーンを削除して検証した。
しかし、
指ボーンを削除しただけでは、手首の捻れは解消しなかった。
次に、手のメッシュのウェイトを調整しながらHandボーンについても検証した。
その結果、Handボーンを削除し、手のメッシュをForeArm側へ持たせることで、初めて大きな手首の捻れが解消した。
この実験から、少なくとも、
5本指のボーンだけが手首の大きな捻れを発生させていたわけではない
ことが分かった。
一方で、Handボーンそのもの、Bone Roll、ボーンの方向、Mixamoアニメーションとの回転軸の対応など、どの要素が直接の原因なのかまでは特定できなかった。
ここでは原因を断定せず、実験結果として記録することとした。
3 Tripoの「再挑戦」でAuto Rigをやり直す
TripoのAuto Rig画面には「再挑戦」という機能が用意されている。
そこで元のモデルを残すため複製を作成し、同じパンタに対して再度Auto Rigを実行した。
設定は前回と同じ、
Rigging Type：Humanoid
Skeleton Preset：Mixamo
とした。
再生成されたアーマチュアを確認すると、前回とは異なるリグが生成されていた。
しかし、左右の指ボーンは今回も完全な鏡像にはなっていなかった。
さらにBlenderへエクスポートして全身のアーマチュアを確認すると、左右の腕や脚、手だけでなく、頭部を含めた骨格全体が完全な左右対称として配置されているわけではないことが確認できた。
したがって今回のパンタでは、Tripo Auto Rigによって生成された骨格は、左右完全対称の骨格にはなっていなかった。
ただし、Tripo内部でどのようなアルゴリズムによって骨格が生成されているのかについては、今回の実験から判断することはできない。
4 非対称なリグでもTripoでは正常に動く
興味深い結果も得られた。
左右非対称な部分を含むアーマチュアであるにもかかわらず、Tripo内蔵のアニメーションを適用すると、パンタは正常に動作した。
前回Mixamoのアニメーションで発生していたような、大きな手首の捻れも見られなかった。
さらに、このモデルをFBXとしてエクスポートし、Blender上でTripoのアクションを再生した。
ここでも手首は正常に動いた。
つまり、
Tripo → FBX → Blender
というエクスポート工程そのものによって手首の捻れが発生しているわけではないことが確認できた。
5 5本指ボーンによる別の問題
ところが、Blender上でアニメーション中の手を拡大すると、別の問題が見つかった。
パンタの手の中に生成された5本指用のボーンが動き、それによって手のメッシュが局所的に変形していた。
ここで、二つの現象を分けて考える必要がある。
一つは、
Mixamoアニメーション使用時に発生した、手首全体の大きな捻れ。
もう一つは、
パンタには必要のない5本指ボーンによって発生する、手先の局所的なメッシュ変形。
前者は指ボーンを削除しただけでは解消しなかった。
一方、後者は5本指ボーンそのものがパンタの手形状に適していないことによって生じている。
この二つは、同じ問題として扱うべきではない。
6 再リグしたパンタを再びMixamoへ
次に、「再挑戦」で生成した新しいリグを持つパンタをMixamoへ送り、再びMixamoのアニメーションを適用した。
その結果、前回とは明らかな違いが現れた。
前回発生していた大きな手首の捻れが大幅に改善した。
同じパンタであっても、Auto Rigをやり直すことで、その後のMixamoアニメーション適用時の結果が変化したのである。
これは今回の検証で得られた重要な結果の一つである。
しかし、問題が完全に解決したわけではない。
手首の大きな捻れは改善したものの、5本指用ボーンによる手先の変形は残った。
Tripoのアニメーションでも、Mixamoのアニメーションでも、パンタには必要のない指ボーンが動くことで手の形状が変化する。
したがって、再リグによってすべての問題が解決したとは判断できない。
7 パンタに5本指のリグは必要なのか
パンタの手は、人間の手とは異なる。
ゲーム内で一本一本の指を動かす予定もなく、モデルそのものにも独立した5本の指は存在しない。
したがって、パンタのゲーム用リグとして考えれば、5本指用のボーンは必須ではない。
理想的には、
ForeArm → Hand
という単純な構造で手を動かすことができればよい。
しかし今回確認したTripoのAuto Rigでは、Humanoid／Mixamoプリセットを使用するとパンタにも指ボーンが生成された。
現時点では、
Tripo Auto Rigで5本指ボーンを生成せず、パンタのような手に適した簡略なリグを生成する方法
を確認できていない。
これは今後の検討課題として残すことにした。
8 Blenderで修正することは可能だが
もちろん、Blender上で不要な指ボーンを削除し、ウェイトを再設定してパンタ用の骨格へ修正することは可能である。
実際、今回の検証でもボーン削除とウェイト変更を行った。
しかし、それには手作業による修正が必要になる。
本研究の目的は、単に一体のモデルを完成させることではない。
生成AIやAIサービスを活用し、できるだけ効率よくゲーム用3Dモデルを制作できるワークフローを構築すること
である。
すでにこれまでの検証で、パンタのメッシュをMixamoへ直接アップロードし、Mixamo側で新しくAuto Rigする方法は問題なく使用できることを確認している。
それならば、Tripoで生成されたリグをBlenderで修正してウェイトまで調整するより、Mixamoで最初からリギングした方が工程は単純であり、結果も確実である。
9 今回の結論 ― Tripo Auto Rigの採用は保留
今回の検証によって、Tripo Auto Rigについていくつかの重要なことが分かった。
Tripoで生成されたパンタのアーマチュアは完全な左右対称ではなかった。
それでもTripo内部ではアニメーションが正常に動作し、FBXとしてBlenderへ持ち込んでもTripoのアクションは正常に再生できた。
また、Auto Rigを「再挑戦」することで、Mixamoアニメーション適用時に発生していた大きな手首の捻れは大幅に改善した。
一方で、パンタには存在しない5本指用のボーンが生成され、それによる手のメッシュ変形という問題は残った。
そして現時点では、Tripo Auto Rigでこの指ボーンを生成せず、パンタに適した簡略な手のリグを作る方法を確認できていない。
したがって今回の結論は、
Tripo Auto Rigをゲーム用パンタの最終リギング工程として採用するかどうかは保留する。
とする。
これはTripo Auto Rigそのものが使用できないという意味ではない。
実際、Tripo内部のアニメーションではパンタは動作している。
しかし、今回の目的であるMixamoの豊富なアニメーションを利用し、最終的にUnityでゲームキャラクターとして使用するというワークフローを考えた場合、現時点では別の方法の方が実用的であると判断した。
10 ゲーム制作ではMixamoリギングを採用する
研究上の結論は保留する。
しかし、ゲーム制作を止める必要はない。
パンタについては、すでにMixamoへモデルを直接アップロードし、Mixamo側でAuto Rigできることを確認している。
そこで今後の実制作では、
Tripoで3Dモデルを生成
↓
必要なモデルデータを準備
↓
MixamoでAuto Rig
↓
Mixamoでアニメーションを適用
↓
Blenderで確認・調整
↓
Unityへ
という工程を基本とする。
Tripo Auto Rigについては、パンタのような人間とは異なる手形状を持つキャラクターに対して、より適切な簡略リグを生成する方法が確認できた段階で、改めて検証する。
まとめ
今回の検証は、問題を完全に解決して終わる実験にはならなかった。
しかし、それも研究結果の一つである。
最初に問題となったMixamoアニメーションによる手首の捻れを調べる過程で、Tripo Auto Rigによって生成された骨格が完全な左右対称ではないこと、パンタには必要のない5本指用ボーンが生成されていることが分かった。
さらに、指ボーンを削除しただけでは手首の大きな捻れは解消せず、Handボーンまで含めた構造が関係している可能性が示された。
Auto Rigを再実行すると手首の大きな捻れは改善したが、不要な指ボーンによるメッシュ変形は残った。
したがって、
「Tripo Auto Rigをどのように修正すれば使えるか」
を追い続けるよりも、現時点ではすでに安定して利用できるMixamoで新しくリギングする方が、ゲーム制作のワークフローとして合理的である。
一方、
「パンタのような5本指を必要としないキャラクターに対して、Tripoで簡略なリグを生成できるのか」
という問いには、まだ答えが出ていない。
この問題については結論を保留する。
使える方法は採用する。
問題が残る方法は、その事実を記録したうえで保留する。
それもまた、AIを実制作に導入するための検証工程の一部である。
第12回 完
第11回 TripoからMixamo、そしてUnityへ
AIゲーム開発研究室
3Dモデル制作ドキュメント
第11回 TripoからMixamo、そしてUnityへ
― これまで接続できなかったAI生成3Dモデルをゲームエンジンまでつなぐ ―
研究代表 大川 博
主任研究員 Arc（ChatGPT）
はじめに
これまでの3Dモデル制作では、Tripoで生成したパンタをゲームキャラクターとして使用するため、さまざまな検証を行ってきた。
3Dモデルの生成。
ゲーム利用を想定した軽量化。
Auto Rigによる骨格生成。
TripoのプリセットAction。
AIによるオリジナルAction生成。
Blenderへの受け渡し。
さらに、豊富なActionを持つMixamoとの連携についても検証してきた。
しかし、第8回と第9回では大きな問題が残った。
第8回では、MixamoのActionをTripoのリグへBlender上で直接適用した。
Tripoのボーンには、
mixamorig:Hips
mixamorig:Spine
mixamorig:LeftArm
など、Mixamoと同じ形式の名称が使用されていた。
しかし、実際にActionを適用すると、キャラクターが大きく移動したり、身体が傾いたりして正常には動作しなかった。
調査すると、同じボーン名であってもBone Rollなどに違いがあり、Mixamo純正骨格からTripo骨格へCopy Rotationによって動作を転送するリターゲット実験まで行った。
動作を転送すること自体はできたが、姿勢の補正が必要となり、ゲーム制作の実用工程としては複雑すぎるという結果になった。
そこで第9回では、別の方法を試した。
Tripoには、
スケルトンプリセット：ミクサモ
さらにFBXエクスポートにも、
FBXプリセット：ミクサモ
が用意されている。
それならば、TripoでMixamo用としてAuto RigしたパンタそのものをMixamoへアップロードできるのではないかと考えたのである。
しかし、結果は失敗だった。
Mixamoには、
Sorry, unable to map your existing skeleton.
と表示され、Tripoの既存スケルトンをMixamo側で正常にマッピングすることができなかった。
さらに、Tripoから出力したFBXを一度Blenderへ読み込み、Blenderから改めてFBXとしてエクスポートする方法も試した。
それでも結果は変わらなかった。
そのため第9回では、
TripoリグとMixamoの互換性については、結論を保留する。
そして、
この問題は後日、継続研究として改めて検証する。
として実験を終了した。
今回は、その続きである。
そして今回、
これまで一度も成功しなかった、TripoでAuto RigしたパンタのMixamoへのアップロードに初めて成功した。
そこから、
MixamoでのAction設定
Blenderへの帰還
マテリアルの復元
Animation OnlyによるAction追加
さらに、
Unityへの受け渡し
までを一つの工程として確認することができた。
1 BlenderタイプとMixamoタイプを比較する
最初に、TripoのFBXエクスポートに用意されている、
Blenderタイプ
と、
Mixamoタイプ
の違いを確認した。
AタイプのパンタをBlenderタイプでエクスポートし、Blenderへ読み込んだ。
アーマチュアは正常に含まれていた。オブジェクトのTransformは、
X軸回転0°
となっている。
次に、CタイプをMixamoタイプでエクスポートし、Blenderへ読み込んだ。
こちらにもアーマチュアが含まれていた。
骨格そのものは基本的に同じだったが、MixamoタイプではオブジェクトのTransformに、
X軸回転90°
が入っていた。
以後の検証では、このCタイプのMixamoタイプ出力を使用することにした。
2 Mixamoへアップロードできなかった原因を探る
第9回では、TripoでMixamoプリセットを使用して出力しても、パンタをMixamoへ正常に読み込ませることができなかった。
Blenderを経由してFBXを再出力しても結果は同じだった。
そこで今回は、骨格だけではなく、
モデルやマテリアルなど、骨格以外の構造
にも原因がある可能性を考えた。
実際、第9回の段階でも、今後検証すべき項目の一つとして、
「モデルやマテリアルなど、骨格以外の構造が影響しているのか」
という可能性を残していた。
そこで、Blender上でマテリアルを削除した状態のパンタをFBXとしてエクスポートし、Mixamoへアップロードした。
すると、
Mixamoへのアップロードに成功した。
これまで何度試しても読み込ませることのできなかったTripoのパンタが、初めてMixamo上に表示された。
これは、第9回から保留されていた問題を大きく進展させる結果となった。
3 マテリアルを削除しなくてもアップロードできる
次に、さらに条件を調べた。
マテリアルそのものを完全に削除する必要があるのかを確認するため、元のCタイプをBlenderへ読み込んだ。
パンタにはTripoで生成されたマテリアルとテクスチャが設定されている。
今回はマテリアル自体は残した。
その代わり、Shader Editorでテクスチャ等とPrincipled BSDFを結んでいるノードの接続を切断した。
これによってパンタは白い状態になった。
この状態でFBXとして書き出した。
今回使用したMixamoタイプでは追加の軸変換を行わず、そのままエクスポートした。
そしてMixamoへアップロードした。
結果は、
成功した。
つまり今回のパンタでは、
マテリアルそのものを削除する
だけでなく、
マテリアルを残したままノード接続を切る
方法でもMixamoへアップロードできることが確認できた。
ただし、今回の実験だけから、Mixamoで読み込めなかった原因そのものをマテリアルだと断定することはしない。
今回確認できた事実は、
マテリアルを削除、またはノード接続を切断したFBXでは、それまで失敗していたMixamoへのアップロードに成功した
ということである。
4 Mixamoでパンタ自身にActionを設定する
Mixamoへのアップロードに成功したことで、これまでできなかった実験が可能になった。
Mixamo上で、パンタ自身にActionを設定する。
今回はダンスなどのActionを選択した。
すると、
パンタがMixamo上で実際にアニメーションした。
第8回では、Mixamo ActionをBlender上でTripoリグへ直接適用しようとして正常に動作しなかった。
しかし今回は方法が違う。
TripoでAuto RigしたパンタそのものをMixamoへアップロードし、Mixamo上でパンタ自身にActionを設定している。
これによって、Tripoで生成したパンタとMixamoのActionを直接つなぐことができた。
5 パンタ付きのアニメーションFBXを書き出す
Mixamoからアニメーションをダウンロードした。
設定は、
Format：FBX Binary
Skin：With Skin
とした。
つまり今回は、Actionだけではなくパンタ本体も含めて書き出した。
このFBXをBlenderへ読み込んだ。
Action Editorにはアニメーションデータが存在し、パンタはBlender上でも正常に動いた。
これによって、
Tripo
↓
Blender
↓
Mixamo
↓
Blender
という往復が初めて成立した。
6 Mixamoから戻すとテクスチャ設定が失われていた
Mixamoから戻したパンタには、マテリアルのデータそのものは残っていた。
しかし、元のTripoモデルに存在していたテクスチャ等のノード構成は保持されていなかった。
Shader Editorを確認すると、基本的なシェーダー構成だけとなり、パンタは白く表示された。
そこで、元のCタイプのBlenderファイルからマテリアルを復元することにした。
7 元のパンタからマテリアルをAppendする
Blenderの、
File → Append
を使用した。
元のCタイプのBlenderファイルを開き、
Material
フォルダから、
tripo_mat_cb2b275b
をAppendした。
読み込んだマテリアルをMixamoから戻したパンタへ割り当てた。
すると、
パンタ本来のテクスチャが復元された。
白黒の毛並み。
青いリュック。
首元の色。
その他のテクスチャも元の状態へ戻った。
そして、マテリアルを復元した状態でもMixamoのActionは正常に動作した。
これによって、
Mixamoへ渡すために一時的にマテリアル表示を外しても、Blenderへ戻した後に元のマテリアルを再利用できる
ことが確認できた。
また、今回とは別にマテリアルそのものを削除してMixamoへ渡した場合についても、元のBlenderファイルからマテリアルをAppendして再設定することで、同様に復元できる可能性が高い。
8 別のActionでも確認する
Mixamoで別のActionをパンタへ適用した。
このActionについてもパンタ本体を含めてFBXとして書き出し、Blenderへ読み込んだ。
正常にアニメーションすることを確認できた。
これによって、特定の一つのActionだけが偶然動作したのではなく、複数のMixamo Actionをパンタへ適用できることが確認できた。
9 別キャラクターのAnimation Onlyをパンタへ使えるか
ここで、さらに効率的な方法を考えた。
Actionを追加するたびに、パンタ本体を含むFBXをダウンロードする必要があるのか。
Mixamoには、
Without Skin
でActionだけを書き出す方法がある。
そこで最初に、Mixamoの別キャラクターを使用して、
Joyful Jump
のActionを設定した。
これをモデルなしのAnimation OnlyとしてFBXで出力し、Blenderへ読み込んだ。
読み込まれたArmatureには、
X軸回転90°
Scale 0.01
が確認された。
このActionをパンタへAppendして適用してみた。
しかし、
パンタでは正常に再現されなかった。
この時点では、
別キャラクターを基準として書き出したAnimation Onlyを、そのままパンタへAppendする方法では正常に動作しない
という結果になった。
なお、Scale 0.01や座標変換などが確認されたが、それらが失敗の直接的な原因であるとは、この実験だけでは断定できない。
10 同じパンタからAnimation Onlyを書き出す
そこで条件を変えた。
別キャラクターではなく、
パンタ自身をMixamoへアップロードした状態で、新しいActionを設定する。
今回は、マテリアル自体を削除したパンタFBXをMixamoへアップロードした。
次に、
Run
のActionをパンタへ設定した。
今度はダウンロード設定で、
Skin：Without Skin
を選択した。
つまり、
モデルを含めず、Actionだけをエクスポート
した。
11 Animation OnlyをBlenderへ追加する
ダウンロードしたRunのFBXをBlenderへインポートした。
モデルは含まれておらず、ArmatureとActionデータが読み込まれた。
このファイルをBlenderファイルとして保存した。
次に、すでに2種類のMixamo Actionが設定されているパンタ本体のBlenderファイルを開いた。
File → Appendから、先ほど保存したRunのBlenderファイルを開き、
Action
からRunのActionをAppendした。
Action Editorを確認すると、
3つ目のAction
として新しいアニメーションが追加されていた。
実際に選択すると、パンタは新しいActionで動作した。
これによって、先ほどの失敗との違いが明確になった。
別キャラクターを基準として出力したAnimation Onlyでは正常に適用できなかった。
しかし、
パンタ自身をMixamoへアップロードした状態で作成したAnimation Onlyは、Blender上のパンタへ追加ActionとしてAppendできた。
この方法を使用すれば、Actionを追加するたびにパンタ本体を含めて書き出す必要はない。
パンタ本体を一つ維持したまま、
MixamoからAnimation Onlyを追加していく
という制作方法が可能になった。
12 Unityへ持ち込む
最後に、複数のActionと復元したマテリアルを持つパンタをUnityへ持ち込んだ。
Unity上ではパンタのモデルが読み込まれ、Animation Clipも認識された。
Animation Clipのプレビューでは、
パンタ本来のテクスチャを表示した状態で、Mixamoから追加したActionが再生される
ことを確認できた。
今回の検証では、Animatorによる複数Actionの切り替えやゲーム操作との接続までは行わない。
今回の目的は、
Tripoで生成したパンタをMixamoへ渡し、Actionを追加し、Blenderで管理し、Unityまで受け渡す
という制作工程が成立するかを確認することである。
その工程については、ここまでで確認することができた。
13 残った問題 ― 手の捻れ
今回、MixamoのActionそのものはパンタへ適用できた。
しかし、一部のActionでは、
手や手首付近が不自然に捻れる
現象が残っている。
この問題は、以前TripoのActionを検証した際にも確認されていた。第7回でも、腕を動かした際に手の部分が不自然にねじれる現象が記録されている。
今回MixamoのActionでも同様の現象が見られたことから、
TripoのAuto Rigによって生成された手周辺の骨格、
ボーンの向き、
ウェイト、
パンタの人間とは異なる手の形状、
Mixamo側が想定する人型骨格との違い、
などが関係している可能性がある。
ただし、現時点では原因を特定していない。
この問題は、
TripoとMixamoを接続できるかどうか
という今回の検証とは分け、今後のモデル品質・リグ品質の改善課題として扱う。
14 第9回で保留した問題はどうなったのか
第9回では、
Tripoの「ミクサモ」スケルトンプリセットでAuto Rigしたパンタを、「ミクサモ」FBXプリセットで出力しても、Mixamoへ既存リグ付きキャラクターとして読み込ませることができなかった。
そのため、
TripoリグとMixamoの互換性については、結論を保留する。
として実験を終了した。
今回、その状況が変わった。
Blender上で、
マテリアルを削除する
または、
マテリアルを残したままノード接続を切断する
という処理を行ったFBXでは、
TripoでAuto RigしたパンタをMixamoへアップロードすることができた。
さらに、
Mixamo上でパンタ自身にActionを設定できた。
Blenderへ戻してActionを再生できた。
元のマテリアルを復元できた。
同じパンタを基準としたAnimation Onlyを追加できた。
そして、
Unityまで受け渡すことができた。
第9回で「保留――つづく。」とした問題に対して、今回ようやく実制作による一つの答えを出すことができた。
15 今回の結論
今回の検証によって、Tripoで生成したパンタをゲーム用3Dキャラクターとして利用するための工程が、大きく前進した。
これまでMixamoへ正常に読み込ませることのできなかったTripoのAuto Rigモデルは、
Blenderでマテリアルを削除する
または、
マテリアルのノード接続を切断する
ことで、今回のパンタではMixamoへアップロードできた。
これによって、
Tripo
↓
Blender
↓
Mixamo
↓
Blender
↓
Unity
という一連の工程が初めてつながった。
さらに、Actionの追加についても重要な結果が得られた。
別キャラクターを基準として出力したAnimation Onlyをパンタへ適用する方法では正常に動作しなかった。
しかし、
パンタ自身をMixamoへアップロードした状態でActionを設定し、Without Skinで書き出したAnimation Onlyは、Blender上のパンタへ追加ActionとしてAppendできた。
これによって、一つのパンタ本体へMixamoのActionを追加していく制作方法も確認できた。
まとめ
第8回では、
Mixamo ActionをTripoリグへ直接適用する
ことを試した。
正常には動かなかった。
第9回では、
TripoのMixamoプリセットを使用したパンタそのものをMixamoへ渡す
ことを試した。
これも成功しなかった。
そして問題を、
「保留――つづく。」
とした。
今回、第11回。
その保留していた問題へ再び戻った。
マテリアルを削除する。
あるいは、マテリアルを残したままノード接続を切る。
それによって、
これまで一度も成功しなかったTripoモデルのMixamoへのアップロードが、初めて成功した。
そこから、
MixamoでActionを与える。
Blenderへ戻す。
元のマテリアルを復元する。
Animation Onlyで新しいActionを追加する。
そして、
Unityへ持っていく。
ここまでを、一つの制作工程として実際に確認することができた。
まだ手の捻れなど、モデル品質を高めるための課題は残っている。
しかし、それはもう、
Tripoで作ったパンタをMixamoへ渡せるのか。
MixamoのActionを利用できるのか。
ゲームエンジンまで持っていけるのか。
という問題とは別の段階の課題である。
第9回以前から残っていた大きな問題の一つに、ここで実制作による答えを出すことができた。
Tripoで生まれたパンタは、Mixamoで動きを与えられ、Blenderで再び制作素材となり、Unityまで到達した。
これによって、AIによる3Dキャラクター制作は、モデルを「作る」段階から、
ゲームで「使う」ための工程へ進んだ。
第10回 TripoモデルをBlenderからUnityへ受け渡す
AIゲーム開発研究室
3Dモデル制作ドキュメント
第10回 TripoモデルをBlenderからUnityへ受け渡す
研究代表 大川 博
主任研究員 Arc（ChatGPT）
はじめに
前回までの検証では、Tripoで生成したパンタの3Dモデルについて、高精細モデルと軽量モデルを比較し、ゲームで使用するモデルデータの検討を進めてきた。
今回は、新たなモデルを生成するのではなく、これまで制作したモデルを実際のゲーム開発環境へ受け渡すための確認を行った。
対象としたのは、主にCタイプのモデルである。
Cタイプは、高精細なBタイプをTripo上で軽量化したモデルであり、約1万フェイスまで削減しながら、元の外観を比較的よく維持している。
今回は、このモデルを
Tripo → Blender → Unity
と受け渡しながら、モデル形式、座標軸、テクスチャ、Normal Map、UV展開について確認した。
1．OBJとFBXを改めて比較する
前回の検証では、OBJ形式で読み込んだモデルのテクスチャ表示に問題が発生していた。
そこで今回は、BタイプとCタイプのモデルデータを、それぞれ改めて
OBJ形式
FBX形式
でTripoからエクスポートした。
どちらもBlender用の設定を使用し、アーマチュアは含めていない。
Blenderへ読み込み、シェーダーエディターを確認した。
FBX形式では、
Base Color
Roughness
Metallic
Normal
などのテクスチャが読み込まれ、それぞれPrincipled BSDFへ接続されていた。
Normalについても、Normal Mapノードを経由して接続されている。
モデルの表示も正常である。
「BタイプをFBX形式で読み込んだ状態。複数のテクスチャがPrincipled BSDFへ接続されている。」
「同じBタイプをOBJ形式で読み込んだ状態。FBXとはマテリアル構成と表示結果に違いが見られる。」
一方、OBJ形式ではFBXとはマテリアルの構成が異なり、モデルの質感にも違いが発生した。
この結果から、今回のモデルをBlenderからUnityへ受け渡す形式として、以後はFBXを使用することにした。
2．TripoのFBXをそのままUnityへ読み込む
次に、TripoからエクスポートしたCタイプのFBXを、そのままUnityへインポートした。
シーンビューでは正常に立っているが、Transform回転 ｘ＝-90に設定されているからである。
UnityのプロジェクトAssets内へ読み込んだモデルは横倒しになっている。
「TripoからBlender用設定で出力したFBXを、そのままUnityへインポートした状態。」
同じFBXをBlenderで確認すると、モデルは正常に立っている。
「同じFBXをBlenderで確認すると、モデルは正常な向きで表示されている。」
今回Tripoからエクスポートする際には「Blender」用の設定を使用している。
そのため、Blenderでは正常に扱える座標軸になっているが、そのデータをそのままUnityへ持ち込むと、座標系の違いによる回転が発生することが確認できた。
3．BlenderからFBXを再エクスポートする
そこで、Tripoから読み込んだCタイプをBlenderから改めてFBX形式でエクスポートした。
今回はFBXエクスポート設定にある、
「トランスフォームを適用」
の設定を変更し、その有無による違いをUnityで比較した。
「BlenderのFBXエクスポート設定。『トランスフォームを適用』の設定を変更して比較した。」
適切な設定でエクスポートしたFBXをUnityへ読み込むことで、モデルを正常な向きで扱えることを確認した。
Unity側のTransformについても、
Rotation X = 0°
Scale = 1
という扱いやすい状態にすることができた。
「Blenderから再出力したFBXをUnityへ読み込んだ状態。モデルの向きとTransformが正常になった。」
今回の結果から、TripoでBlender用として書き出したモデルをUnityで使用する場合、
一度Blenderを経由してFBXを再出力する
という方法が有効であることが確認できた。
4．Unityでテクスチャ表示が崩れる
座標軸の問題を解決したあと、もう一つ問題が発生した。
Blenderでは正常に表示されていたモデルが、Unityではテクスチャや表面の陰影が大きく崩れて表示された。
「Normal Mapを含むFBXをUnityへ読み込んだ際に発生した表示異常。」
そこで、Blenderのシェーダーエディターに戻り、どのテクスチャが原因なのかを調べることにした。
Base Color、Roughness、Metallic、Normalなどの接続を一つずつ外し、その都度FBXを書き出してUnityで確認した。
その結果、
Normal Mapを外した場合には正常に表示される
ことが判明した。
「BlenderでNormal Mapの接続を外して再出力したモデル。表示異常が解消された。」
これまでは、このような問題を避けるため、カラーマップ以外のテクスチャを外して使用していた。
しかし今回は一つずつ検証したことで、少なくとも今回のモデルでは、Normal Mapが表示異常に関係していることまで絞り込むことができた。
5．Normal MapはUnityでも使用できる
しかし、Normal MapそのものがUnityで使用できないわけではない。
そこで、Normal Mapを接続した元のFBXを使用して、Unity側の設定を確認した。
Normal用テクスチャを選択し、
Texture Typeを「法線マップ」に設定
して再度確認した。
「Normal用テクスチャのTexture Typeを『法線マップ』に設定。Normal Mapを使用したまま正常表示することができた。」
すると、モデルは正常に表示された。
今回のモデルでは、
「緑のチャンネルを反転」
を使用する必要もなかった。
つまり、問題はNormal Mapそのものではなく、Unity側でNormal用テクスチャを法線マップとして正しく設定する必要があったことになる。
これにより、Normal Mapを削除することなく、Unityでも利用できることが確認できた。
6．カラーマップを拡大して確認する
次に、モデルを大きく拡大してカラーマップの状態を確認した。
通常の表示では非常にきれいに見えるが、クローズアップすると、白い毛と黒い毛の境界など、部分的に粗い箇所が確認できる。
「モデルを拡大すると、毛の境界などにカラーマップの粗い部分が確認できる。」
AIによって生成された3Dモデルをそのまま使用する場合、このような細部の修正が必要になることも考えられる。
そこでUV展開を確認した。
7．AI生成モデルのUV展開
CタイプのUVをBlenderで表示すると、一般的なキャラクターモデルのように、顔、胴体、腕、リュックなどが分かりやすいパーツ単位で配置されているわけではなかった。
非常に多くの細かなUVアイランドに分割され、それらがテクスチャ全体へ高密度に配置されている。
「CタイプのUV展開。多数の細かなUVアイランドがテクスチャ全体へ高密度に配置されている。」
この状態では、カラーマップ画像を画像編集ソフトで開き、
「顔のこの部分を修正する」
「腹部のこの色を直す」
といった方法で直接編集することは難しい。
ただし、修正そのものができないわけではない。
Blenderには、3Dモデルの表面へ直接描画するTexture Paintの機能がある。
これを利用すれば、モデルを見ながら必要な部分へ直接修正を加えることができる。
ただし、その具体的な操作方法やテクニックについては、今回の検証では扱わない。
8．TripoからUnityまでの受け渡し工程
今回の検証によって、Tripoで生成・軽量化したモデルをUnityへ持ち込むまでの実際の工程が見えてきた。
今回採用した流れは、
Tripo
↓
FBXでエクスポート
↓
Blenderでモデル・マテリアルを確認
↓
必要な調整を行う
↓
BlenderからFBXで再エクスポート
↓
Unityへインポート
↓
Normal MapなどUnity側のマテリアル設定を確認
というものである。
TripoからFBXを書き出し、そのままUnityへ読み込むこともできる。
しかし、実際のゲーム制作で使用することを考えると、Blenderを中継することで、座標軸、マテリアル、テクスチャ、UVなどを確認しながらデータを整えることができる。
今回のまとめ
今回の検証では、Tripoで制作したモデルを実際のゲーム開発環境であるUnityへ受け渡す工程を確認した。
その過程で、
OBJとFBXではマテリアル情報の受け渡し方が異なること。
TripoのBlender用FBXをUnityへ直接読み込むと、座標軸の違いによる回転が発生すること。
Blenderを経由してFBXを書き出すことで、Unityで扱いやすい状態に調整できること。
Normal MapはUnityでも使用できるが、Unity側で法線マップとして正しく設定する必要があること。
AI生成モデルのUVは非常に細かく分割されており、必要なテクスチャ修正にはTexture Paintが有効であること。
を実際のモデルデータによって確認することができた。
AIによって3Dモデルを生成することと、そのモデルをゲームで使用できる状態にすることは、同じではない。
しかし、生成されたデータの問題点を一つずつ確認し、BlenderとUnityで必要な調整を行うことで、AI生成モデルを実際のゲーム制作へつなげることができる。
今回の検証によって、
Tripo → Blender → Unity
という3Dモデル制作からゲーム実装へ向かう実用的なワークフローが、さらに具体的になった。
第9回 TripoのMixamoプリセットはMixamoで使えるのか
AIゲーム開発研究室
3Dモデル制作ドキュメント
第9回 TripoのMixamoプリセットはMixamoで使えるのか
研究代表 大川 博
主任研究員 Arc（ChatGPT）
はじめに
前回の実験では、Tripoで生成したリグにMixamoのActionを直接適用できるかを検証した。
Tripoのリグには、
mixamorig:Hips
mixamorig:Spine
mixamorig:LeftArm
など、Mixamoと同じ形式のボーン名が使用されている。
しかし、実際にMixamoのActionを適用すると、キャラクターが空間を大きく移動したり、身体が傾いたりするなど、正常な動作にはならなかった。
Blender上でTripoとMixamoの骨格を比較すると、同じボーン名であってもBone Rollなどに大きな違いがあることが確認された。
さらに、Mixamo純正骨格を中継し、Copy RotationによってTripo骨格へ動作を転送するリターゲット実験も行った。
動作を転送すること自体は可能だった。
しかし、全身へ設定しても身体の傾きが残り、さらに補正が必要となった。
そのため前回は、
Tripoによるリギングをゲーム制作工程から外し、Mixamoで直接リギングする
という方針を立てた。
ところが、その後Tripoの設定画面を確認していると、重要な項目があることに気づいた。
「ミクサモ」
である。
1 Tripoには「ミクサモ」プリセットが存在する
TripoのAuto Rig画面には、
リギングの種類：ヒューマノイド
に加えて、
スケルトンプリセット：ミクサモ
という設定が用意されている。
さらにFBXのエクスポート画面にも、
FBXプリセット：ミクサモ
が存在する。
ここで新たな疑問が生まれた。
前回は、Tripoで生成したリグへBlender上でMixamo Actionを適用しようとしていた。
しかし、
Tripo自身がMixamo用のスケルトンプリセットとFBXプリセットを用意しているのであれば、その設定を使用して生成したリグ付きFBXを、直接Mixamoへ渡すことができるのではないか。
もしそれが可能なら、前回行った複雑なリターゲット処理は必要なくなる。
そこで、この可能性を改めて検証することにした。
2 まずCタイプをMixamoへ直接アップロードする
最初に、すでにTripoでリグが設定されているCタイプのパンタを使用した。
Tripoのエクスポート設定を、
フォーマット：FBX
FBXプリセット：ミクサモ
エクスポートスケルトン：ON
とした。
TripoのActionは使用しないため、アニメーションは含めない。
テクスチャについても、今回の目的はモデルの外観ではなく、
「TripoのリグをMixamoが既存スケルトンとして認識できるか」
を確認することであるため、検証には使用しなかった。
3 MixamoはTripoのスケルトンを認識できなかった
エクスポートしたFBXを、そのままMixamoの、
UPLOAD CHARACTER
からアップロードした。
しかし、Mixamoには次のエラーが表示された。
Sorry, unable to map your existing skeleton.
FBXそのものをアップロードできないというエラーではない。
既存スケルトンをMixamo側の骨格としてマッピングできない
という内容だった。
つまり今回のCタイプでは、
Tripoからリグ付きFBXを書き出す
ところまでは成功したが、
そのリグをMixamoが既存スケルトンとして認識する
ところで失敗した。
4 本当にMixamo用のリグだったのか
ここで一つ問題が残った。
CタイプをAuto Rigしたとき、どのスケルトンプリセットを選択していたのかを、今回の実験時点では確実に確認できなかった。
Cタイプのボーンには mixamorig: という名称が使用されているため、Mixamoプリセットで生成していた可能性は高い。
しかし、
「おそらくそうだった」
では検証にならない。
そこで、リグが設定されていないAタイプのパンタを使用して、最初から条件を明示した実験を行うことにした。
5 Aタイプを「ミクサモ」プリセットでAuto Rigする
リグが設定されていないAタイプを選択した。
TripoのAuto Rig画面で、
リギングの種類：ヒューマノイド
スケルトンプリセット：ミクサモ
を明示的に指定した。
その状態でAuto Rigを実行した。
リギングは正常に完了し、Aタイプのパンタに骨格が生成された。
これによって今回は、
「Tripoのミクサモ・スケルトンプリセットを使用して生成したリグ」
であることを明確にした。
6 エクスポート側も「ミクサモ」を指定する
次に、Auto RigしたAタイプをFBXでエクスポートした。
設定は、
フォーマット：FBX
FBXプリセット：ミクサモ
エクスポートスケルトン：ON
とした。
つまり今回は、
リグ生成時：ミクサモ
FBXエクスポート時：ミクサモ
という条件を明確にそろえた。
Tripo側で指定できるMixamo関連設定を使用した状態である。
7 再びMixamoへアップロードする
エクスポートしたAタイプのFBXをMixamoへ直接アップロードした。
今回使用したモデルは、
Tripoで「ミクサモ」スケルトンプリセットを明示的に指定してAuto Rigしたモデル
である。
さらに、
「ミクサモ」FBXプリセット
を使用してエクスポートしている。
そのため、このFBXであればMixamoが既存スケルトンを認識する可能性があると考えた。
しかし結果は同じだった。
Mixamoには再び、
Sorry, unable to map your existing skeleton.
と表示された。
8 Blenderを経由して再エクスポートする
まだ原因がTripoのFBX出力方法にある可能性も考えられた。
そこで、Tripoからエクスポートしたリグ付きFBXを一度Blenderへインポートした。
その後、Blenderから改めてFBXとしてエクスポートし、そのFBXをMixamoへアップロードした。
しかし、この方法でも結果は変わらなかった。
Mixamoは既存スケルトンをマッピングできなかった。
したがって今回の結果は、
Tripoから直接出力されたFBXだけで発生する単純な書き出し上の問題とは断定できない。
9 今回確認できたこと
今回の実験によって、少なくともパンタでは次のことが確認された。
Tripoには、
「ミクサモ」スケルトンプリセット
が存在する。
さらにFBXエクスポートにも、
「ミクサモ」プリセット
が存在する。
しかし、
Tripoで「ミクサモ」スケルトンプリセットを指定してAuto Rig
し、
「ミクサモ」FBXプリセットでリグ付きFBXをエクスポート
しても、
今回のパンタではMixamoがその既存スケルトンを正常にマッピングすることはできなかった。
さらに、
Blenderを経由してFBXを再エクスポートしても結果は変わらなかった。
10 それでも、まだ結論にはしない
今回の結果だけから、
「TripoのリグはMixamoでは使用できない」
と一般化することはしない。
Mixamoが表示したエラーは、
unable to map your existing skeleton
である。
つまり、今後調べるべき対象はまだ残っている。
骨格階層の違いなのか。
Bind Poseの問題なのか。
FBX内部のスケルトン情報なのか。
モデルやマテリアルなど、骨格以外の構造が影響しているのか。
あるいはMixamo側の自動マッピングが想定するHumanIK互換骨格との違いなのか。
さらに検証できる項目はある。
したがって、この問題については、
失敗したから終了
とはしない。
ただし、この問題だけを追い続ければ、パンタのゲーム制作そのものが進まなくなる。
そこで今回は、ここで一度検証を止める。
11 今回の結論
今回の実験では、
Tripoの「ミクサモ」スケルトンプリセットでAuto Rigしたパンタを、「ミクサモ」FBXプリセットでエクスポートしても、Mixamoへ既存リグ付きキャラクターとして読み込ませることはできなかった。
Blenderを経由してFBXを再エクスポートする方法も試したが、結果は同じだった。
しかし、原因についてはまだ十分に解明できていない。
そのため、
TripoリグとMixamoの互換性については、結論を保留する。
そして、
この問題は後日、継続研究として改めて検証する。
制作本線では、いったんTripoリグの使用から離れる。
次の段階では、
リグなしのパンタをMixamoへ直接アップロード
し、
Mixamoでリギング
MixamoでAction設定
Blenderで編集
Unityで動作確認
までを行う。
まずゲーム制作に使用できる実用的なワークフローを完成させる。
そのうえで、
「なぜTripoには『ミクサモ』プリセットが存在するのに、今回のパンタはMixamoでマッピングできなかったのか」
について、改めて追究する。
保留――つづく。
第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で利用する方法はないのか」
という疑問が再び浮上することになる。
この問題については、改めて別の実験として検証する。
