AllRight Rig 2.0の動作確認
「AllRightRigがマーケットプレイスにでないな……と思ってたら出たので、買ってきた」
妹「これは結局骨入れられるの？」
「いや結局骨は入れられない。けど、骨入れるのと動かすのと、両方ともややこしい問題で、どちらかというと動かす方がネックだった。UE4の中でまともにポーズとらせたりアニメーションさせる方法がなかったから」
妹「すばやく動かして録画するやつね」
「あれはつらいので兄としてはやりたくないし、それにBlenderで作ったのも問題があった」
妹「なつかしいものがでてきた」
「この時はBlenderでアニメーションも作ったんだよ。で、エビフライの動きはテキトーで、ピチピチさせとけばいいんだけど、猫の方は問題で、ちゃんと当たるように手を出さないといけないといけないのが難点で。微調整のたびにBlenderで動かして、UE4に入れて、やっぱりなんかズレてるというのを繰り返して」
妹「それで当たるようになったんだ」
「いやそれでも当たらなかったというか、見た目と当たり判定の両立が上手くいかなくて、UE4側で猫本体ごと移動させる処理を入れたりしたんだけど。UE4で調整すればその問題は発生しない」
「まずはインストール。プロジェクトじゃなくエンジン本体にインストールするタイプのやつだった。プラグインを有効にすれば使えるようになる。要らない時は無効にする」
http://alexallright.com/allrightrig/doc/
「あとは説明書をみながらやる。基本的にはアニメーションブループリントを作って、リグを設定して、動かす」
妹「リグというのは？」
「骨を動かす仕組みというか。手首を動かすと肘も曲がるとか、そういう骨同士の連動の仕方みたいな？ 自分で設定してもいいんだけど、サンプルデータにも色々入ってて、グレーマン用のもある」
アニメーションブループリントはよくわからないのでドキュメント通りに作る
レベル上にスケルタルメッシュを置いて、選択した状態にして、RigToolsの画面を開く
アニメーションブループリントとリグを設定してからRigボタンを押せばいいけど
設定するのが面倒なのでサンプルから流用する
RigのデータはSaveGamesフォルダの中にできる
なので、サンプルのSaveGamesから丁度いいリグを持ってくることが出来る
自分が作った場合も同じ用に流用可能
グレーマン用はManRig.savなので、これを自分のプロジェクトのSaveGamesにコピーした
ManRigをLoadしてからRigボタンを押す
適当に動かす
「一応ここまではできた。ちゃんとUE4の中でグレーマンを動かせてる。各関節を普通のアクターと同じ用に動かすことで動く」
妹「アニメーションも作れるの？ 飛んだり歩いたり」
ボクセルでキャラクターをモデリング
「ボクセルの背景はなんとかなりそうだから、キャラクターも作ってみた。MagicaVoxelで、関節部分はわざとつなげてない」
妹「関節ないの？」
「ない。ボクセルでそこくっつけると、どうやってもヒビ入っちゃうから。ない方がよさそうな気がする。あんまりリアルに作ると気になるけど、デフォルメすればそんなもんだという気持ちになるんじゃないかな。ファミコンのドット絵と同じで。あとは足や手は左右同じのを反転させてる。リファレンスのコピーという機能で、中身が同じオブジェクトをたくさん作れるから」
妹「中身が同じだったら左右で同じになっちゃうのでは」
「そのオブジェクトの中身は一緒だけど、オブジェクトを回転させるというのはそれとは別だから。UE4のアクターとかと一緒だね」
妹「これどうやって動かすの？」
「そこが問題で。UE4用のAllRightRigはまだマーケットプレイスにでてこないし……それがあったとしても骨自体は先に入れとかないといけないのかもしれないけど。どういう方法があるか今から考える……」
ブロック積み上げ実験(3) 先に積み上げてからインポートする
「前回までのやり方で、なんで隣のブロックとの間に隙間ができるかという、根本的な原因はポリゴンがつながってないから」
妹「そうだね」
「なので今回はQubicleの段階で、ブロックをたくさんコピーして、Unionボタンんで結合。その後でfbxエクスポートしてみることにした」
妹「それだとどうなるの？」
「隣のボクセルとはポリゴンをつなげてくれるから、継ぎ目自体ができない。MagicaVoxelの0.99以降でも複数オブジェクトに対応してるから、そっちでブロックを積み上げてからQubicleにもってきてもいい」
「そうすると、無事に継ぎ目なく表示することができた」
妹「うん？ これは継ぎ目ない状態なの？ というか、なんかブロックの色が変な気が」
「ライトマップが小さすぎた……デフォルトの64x64のままだから。ブロック1個ずつの時は64でも継ぎ目以外は問題なかったけど、ブロックがたくさん増えてるのにライトマップの大きさがそのままだと、必然的にかなり荒くなる」
「ライトマップを大きくすれば陰影の表示も問題ない。よく覚えてないんだけど、たしか256x256にしてから撮影した時のだったと思う」
妹「やっぱりライトマップは大きくしないと駄目なんだ」
「まあでもブロック1個に256使ってたのが、今回はブロックが7つでそれだから。その点はあんまり問題じゃない。ただこれだとコリジョンもでこぼこにしないといけないのが面倒なのと、ブロックを部分的に壊すといったことはできなくなる」
妹「壊すの？」
「マインクラフト的なのとか、パズルゲームみたいなのだとそういうこともあるかも。まあ壊すとなったらその部分をムーバブルにしないといけないから、結局ライトをムーバブルにするのと一緒なんだけど。壊せる部分だけ光の当たり方がへんになっちゃうはず。だけど背景をなるべく綺麗に表示したいって時は、こういう風に全体を1つのメッシュとしてインポートして、ライトマップ大きめにすれば綺麗に表示できそう」
