MikuMikuEffect と AviUtl のモーションブラー…… orz


左手の FireParticleSystemEx.fx が機能しないっ! (>_<)/

FireParticleSystemEx.fxは、FireParticleSystem.fxを元に、火元を動かしたときに炎が揺らめくように改造したものです。
FireParticleSystemEx.fxを使用するには、頂点シェーダ3.0に対応したビデオカードが必要です。
README.txt

シェーダ3.0 には対応してると思うんだけどね。

MikuMikuEffect ver.0.10

Device: HAL: Mobile Intel(R) 4 Series Express Chipset Family (driver: 8.15.10.1872)
ShaderVersion: vs_3_0, ps_3_0


Loading effect file: I:\MMD\MikuMikuDance\MikuMikuDance_v708MME\UserFile\Accessory\FireParticleSystem.fx
Loading texture file: I:\MMD\MikuMikuDance\MikuMikuDance_v708MME\UserFile\Accessory\Flame.tga
done.

Loading effect file: I:\MMD\MikuMikuDance\MikuMikuDance_v708MME\UserFile\Accessory\FireParticleSystemEx.fx
Loading texture file: I:\MMD\MikuMikuDance\MikuMikuDance_v708MME\UserFile\Accessory\Flame.tga
done.

マシンの性能的には問題ないと思うし、付属の fire_sample.pmm 読み込んで AVI 出力しただけ*1だから設定違いということも無さそうだし。



それはさておき。

と同様に出力が一致するか確認してみましたが。これに関しては OK みたい。乱数使っていないだけ、という可能性もあるから予断を許せないですけれども、とりあえずこのエフェクトに関しては立体視で使えそう。

リリレインの背中のジェット噴射どう表現しようかと思ってたのですが、これで行けそうみたい。*2



それはさておき。

今さらですが AviUtl拡張編集のモーションブラーを試してみました。*3

……これ

で作ったやつと同様の擬似モーションブラー*4だ!!

……ううう。これ知ってたらわざわざ作らなかったのに……。

まあ、細かいパラメータは自作したものと違いコントロールできないし、MikuMikuDance でのカット割に対応させるのも出来なさそうだしだから、自作したのも全くの無駄だったわけではないからいいですけれど、ね。

……いいですけど、ね。



ついでに未解決の問題をメモ。

  • MikuMikuDance の物理演算部分が 60fps でしか動いてくれないので高 fps で出力して畳み込む時に不都合がある

具体的には

framemixer.py 掛けて 120→30fps してしまうとその 2フレーム毎にしか動かない物理演算部分の濃い方の 2フレームと薄い方の 2フレームがそれぞれ合成されるため、薄い方の組が余計目立たなくなってしまうという欠点が。

YouTube にも上げました - つちのこ、のこのこ。(はてな番外地)

みたいな状況で。

別に物理演算の単位が 60fps だからといって表示もそれに付き合わせる必要は無い――他の部分だって最大 30fps 単位でしか指定されないわけだから、それと同様に線形補間なりすることもできるはず――ですから、謎仕様。

これ考えると VMDView での物理演算Fix の出番も無くなってはいないわけですか……これ、かなりのモデルで使い物にならないんですよね。(例: レアさん)
とりあえずは、60fps で我慢しておくことにしましょうか。*5

*1:無論、MMD での表示でも同じ状態

*2:筒のポリゴン作って炎みたいなの貼りつけて……みたいなのを自作しないとダメかなと思ってた

*3:これの入っていなかった aviutl_plus というパッケージを使っていたから AviUtl 標準の拡張編集パッケージにこれ有るのに気付かなかった

*4:本当のモーションブラーは「動きの激しい所だけ処理」という動作をする。こちらのは動きの激しい部分は離散的に表示され、動きの少ない部分はブレるから、言わば「逆モーションブラー」でしかない

*5:framemixer.py での重ねあわせ順を (0, 1, 2, 3) → (0, 2, 1, 3) みたく入れ替えて、中間が濃くなるように、とかの手段も考えないでもないですが……いずれにしろ「物理演算の部分だけフレームレートが低い」という根本の問題がそのままでは、肝心の動きを見せたい部分が 60fps に制限されるわけですし……