プラットホームは何を使う Part 2

前回の続きにしては間が空きすぎているんだけど、備忘録としての役目もあるので現状について書き記しておきたい。

現状は、モーションエディターとして MMD、それを FBX化するのに Blenderを使っている。

Unreal Engine 5 、Unity、をプラットホームとして使っている。ステージを用意したり撮影をしたりという場所になる。

Unityについて言えば、MMDMecanim を使っているが、FBX化したリグをインポートして動かすこともできる。

Unreal Engine は、FBX化しなければ、インポート出来ないが、だからと言って使うのを躊躇う程のことは現状無い。

問題なのは、MMD と、Blender、そして MMDMecamin の物理などが微妙に違うことである。

MMD で問題なく動いたとしても、他で動きに不都合が生じることが間々ある。

リグを動かすのに、

素材(Mesh)、ボーン(Bone)、剛体(RigdBody)、ジョイント(コンストレイント)の組み合わせによるのだが、各ソフトの動きは完全に一致することない。

これは、物理の動作を委ねる仕掛けの違いが大きいのだと思うが、それぞれの物理の実装の詳細は分からない。

大体、定番と言えるようなものはあるのだけど、それでもパラメーターの設定の違いなどよくある。

MMDでは、丁度よく髪の毛がヒラヒラト舞うのだけど、Blender になるとどうも動きが少し重くなる。

このあたりは、Blender 向けに、剛体やジョイントを調整しないと似たような動きにならない。

また、Unityのプラグインである、MMDMecanim も独自の動きをする。但し、Unity 内でMMD と同じ物理エンジンを動作させることができる。

それでも、同じ動きにならない場合がある。

ここで確認しておくが、ボーンによる動きは、IKなどやや解釈が違う場合があるけど、問題になることはあまりない。(偶にはあるが)

あくまで問題が顕著に顕れるのは、物理の動作、もっと具体的に書けば、髪の毛とスカートである。ネクタイや小物も含まれる時もあるが、所謂、「揺れもの」と呼ばれるやつである。

MMD を使うのが、MMD 由来のリグやモーションを使うに当たっては一番リスクが少ない。

ただ、気になるのは、MMD を使う人が圧倒的に多くて、そんな中で少々頑張ってみても、見栄えが違い、優れた作品を作るのは自分にとっては、至難の業なのである。

そこで、MMD 以外のプラットホームを使うと言う選択肢をあえてとっている処もある。

プラットホームが違えば、自ずと見栄えは違ってくる。才能のある人なら何を使っても良いかもしれないが、そうでない人間にとってはささやか抵抗なのである。

とはいっても、ゲームエンジン自体に興味を持っているのも事実である。

MMD では、極めて困難な表現を、簡単に行ってしまうこともある。

背景などは、有料のアセットにはとんでもないものもあるし、MME を使って実現しようすれば、相当に難易度が高くなる効果も、案外簡単に出来たりする。

MMD はツールとしては優れていると思うし、今までの功績は大きいものだと思う。

だか、さすがに、DirectX9 では辛くなってきていると思う。(ちなみに、Windows 11 でも、無事に動いた)

とはいえ、それに纏わる資産は膨大な物があり、それを使わない手はないのも事実だと思う。

何を使うかより、何を作るがの方が大事ではあるとは思うけど、やはり何を使うかは悩みの種になるものだろう。

特に、Unreal Engine などはマシンスペックも高いものが必要だ。

それでも、Unreal Engine でなければ表現が難しいこともあるのだ。

Unity もハイスペックな表現(HDRP)を使えるが、総合的にみれば、物理ベースのレンダリングに関しては、Unreal Engine の方があきらかに上のようだ。

ただし、Unity の良さは入門のハードルの低さと柔軟性にあると思う。

両方使ってみて思うのは、使いどころがかなり違うと言うことだ。

スクリプトを使ってボカロのデータを読み込ませてそれにリンクした自動カメラワークみたいな仕掛けを実装するなら、Unity の C# の方が断然に扱い易い。

同じことを、Unreal engine で ブループリントや、Python でやるのは相当に難しくなると思う。

この辺の柔軟性が違うのだ。

今回配信した、「CH4NGE」の、Unityでのカメラワークはスクリプトで作らている。

カメラワークを何パターンか用意して、それをレンダリングして、編集ソフト(Davinci Resolve Pro)でマルチトラック編集をする。

以前、完全手作業でカメラワークを作成し、編集していた頃に比べると、作業時間は、三分の一位に激減した。

おかげで、配信の頻度が保てるというメリットがあった。

それが、Unreal Engine になるとそうは簡単にいかない。

外部ファイルを読み込んで、それを元にして何かやろうとするれば、Pythonが必要になる。

Editor でできることは、Python で大概できるのだが、Unity の C# のようにはいかない。

それでも、かなり頑張って、Python のスクリプトを書いて、作業を自動化できるとこと自動化した。

が、Unity には及ばない。

従って、手作業自体は、Unity より多くなり、制作にそれなりに、時間がかかる。

しかし、動画の画質としては、Unreal Engine の方が上なのである。

結論として、一方を使うより、作りたい作品に応じて、使い分けした方が寧ろ効率が良いことがようやく最近分かってきた。

どちらかのスキルを極めると言う選択肢もあるが、大谷翔平ではないが敢えて、二刀使いをすることにした。

考えてみれば、ゲームエンジンであるが故に、共通することもある。インターフェイスは違っていても、実現できる機能にはあまり差がない。

むしろ、こちらで使った機能はあちらではどうすれば実現できるのかと、問答することもあるのだ。

それによって、今まで使わなかった新たな機能に気が付くこともある。

二つを使うことによる、ロスもあるが(有料のアセットなど)、メリットも相当あると思う。

それに、飽きが来なくてよいのかもしれない。

どちらかに慣れてきて飽きがきたら、エンジンを変えてみるのは中々刺激的で面白いと思うように最近はなってきたようだ。

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です