v0.8テスト版  ボーン減りました_01

はい、髪の剛体ばっかりいじってて他をする余裕がなかったのですが一通り落ち着いてきたので
進捗動画をアップしました



今回はモデルの更新報告ではなくて動画を作ったときの話と
MikuMikuMoving(以下MMM)どうなのって話、あとPmxEditorの話、の2+1構成です
長いですのでMMD始めたばっかだけどMMMどうなのって人は先に中盤から書いてあるそっちを
先に見ていいと思います、前半のエンコとかははそれが終わってからの話なので

実は動画をアップするのは二回目で、前は元々動作確認用として作ってたのを上げたんですが
お借りした物の表記を動画内部に入れてなかったので (アップする気なく作ってたので)
今はもうないです、消したのではなくて一応非表示状態です

前回は黒背景にテストモデル(自分の中ではv0.1と呼んでた物)を躍らせてるだけの物だったの
ですが、画質が非常に残念な事になっていて、次アップするときはもう少し練ろうと考えたのです

まず前回の動画の作成手順ですが、MikuMikuDance(以下MMD)で出力したあとAviutlを使って
拡張h264出力で動画だけの音声なしmp4を作ります、次に音源からYambを使って抜いた
aacとこれまたYambを使って合成、これで完成です

多分今同じ工程をしたら10分ぐらいで同じ動画が作れます(MMDでの出力時間を含めても)
それぐらいお手軽な方法です、ただこれだと画質が良くないんですね、何も設定していないので
当然といえば当然なのですがそれにしてもかなりひどい画質になってしまいます
わたしは一般登録なのでファイルサイズもビットレートも限界が低いのでなおさらです


で、ここからが本題の「どうしたらもうちょっと画質の良い動画が作れるか」です
一つは「h264のエンコード設定を練る」ですがこれは作る動画によって多様になるので
ここでは割愛して、作る上での大雑把な考え方をまとめてます

(これはニコの一般会員前提で書いてますがプレミアム会員にも少し関係のある話です)

まず動画(avi)を作成します、これがないともろもろの計算が出来ないので一番最初はこれです
このときは特に何も気にしなくていいです、
ただ出来れば動画の長さは8分ぐらいまでに収めた方がいいです(画質を求めるなら)

ニコニコ動画の仕様を確認します、一般会員は動画のファイルサイズは40MB以内
平均ビットレートは600kbps以内、と表記されています
調べればわかるのですがビットレート限界は実際には640kbpsぐらいらしいです
今回はそれを信じつつマージンをとって630kbpsぐらいを狙いました

次に自分の動画の長さを確認します
今回わたしが作った動画で言うと6508フレームです、これは30fpsなので216秒ぐらいです
そこで目指すべきビットレート限界をもう一度思い出します
630kbpsですね、計算がめんどくさいので以後632kbpsとします
 (8bit=1BYTEと知らない人がいると思いますがこれはそういうものだと覚えて下さい
 BYTEというのはWindowsで40MBとか表記されるときの40M"B"←これです)

つまりビットレートを8で割るとバイトレートになる、ということです、632/8=79
79kBpsですね、こんな表記をするのか知りませんがbitはb、BYTEはBと表記する事が多いです
これを動画時間にかけると狙うべきファイルサイズが見えてきます
 79x216=17064(kBps)
このままだとわかりにくいのでkを外します、パソコン界ではkは1000ではなく1024なので
 17064x1024=17,473,536BYTE
はい、これが6508フレームの動画で実現できる動画のファイルサイズ限界(マージンあるけど)です

次にこの許されたファイルサイズをどう使うかを考えます、音質重視なのか画質重視なのか
動画内に一部だけ画質が欲しい、という事もあるかもしれないです
今回わたしがアップした動画は「メイン動画=画質が欲しい」「エンドロール=それなりでいい」
「音質=それなりでいい」という考えで進めました

mp4というのは音声のaacと動画のavcを入れる箱のような物で、動画の長さと音声の長さは一致
させる必要がありません、同時に0から始まり最後まで先に到達した方はもう片方が終わるまで
停止しています、これを頭にまず中身を揃えます

まず作りやすい音声部分です、neroAacEnc.exeを使ってAACを作ります
音質はそれなりでいいので64kbpsに設定して出力(後にこれは失敗だと知る)
これによって得られたファイルサイズは1,667,197 バイト17,473,536バイトと差を取ると
15,806,339バイトとなりこれが動画に使える最大容量となります(箱のmp4でも少し使うけど)
(わたしは単体での使い方を知らないのでAviutlでmp4作ってYambでaac抜いてます
このときmp4にした動画の長さがいくつでも音源が一緒なら抜けるaacは完全同一になります)


次にエンドロール部分です、わたしは本編と別ファイルとして作りましたが、一本無圧縮aviで作って
Aviutlの機能で分割してもいいと思います
ここは画質がそれなりでいいので50kbpsに設定してエンコードします、これにより
329フレーム73,310 バイトのエンドロールが完成しました、一応画質に問題がないか確認します

ここでまた15,806,339バイトと差を取ります、15,733,029バイト、これが本編に使える容量です
本編は6508-3296179フレームなので約205秒15,733,029バイトをこれで割ると
77,104バイト、これに8をかけると616,832ビットとなり狙うビットレートが602kbpsだとわかります
単純に「全部で632kbps、音声を64kbpsで作ってるから568kbpsの動画を作ればいいんだな」
というわけではないんですね

こうして本編を602kbpsで作り、エンドロールとAviutlMP4 Exportプラグインなど使って繋げ
Yambで動画と音声を結合すればやっと一本のmp4が完成します
あとはこれをニコ動に上げて本当に仕様を満たしているのか確認します
結果ですが音声64kbpsは低すぎました、保存してWMPで聞く分にはまだいいですが
ニコ動のプレイヤーで聞くと結構ひどいです、どっちが悪いのか、良いのかはわからないですが

ここまでで今回の動画作成のまとめは終わりです


ここからはホントに画質を求めたい場合の方法です
基本的には上記手法がすべてです、これ以外の技術は必要としません、何が違うかというと
動画の最後、エンドロール後に「およそ0バイトの長い動画をくっつける」です
上の説明で動画に使えるファイルサイズを計算しましたが
あれはあくまで6508フレームの場合の話で、ニコ動の一般会員限界サイズは40MBです
632kbps40MB使うには何秒の動画にすればいいかというとおよそ518秒です
これは632/8(バイトに戻す)=79kBps 40x1024=40960kB 40960/79=518.481s
という式から求められます、簡単な算数です、めんどくさいですが

これはおよそ8分28秒となり、動画本編が216秒ならのこり292秒を黒の余白にしてしまえば
容量限界の40MBをほぼフルで使える、という事になります、これを前者動画に当てはめると
40MB=41,943,040バイトなので 音声15,806,339とエンドロール73,310で差を取ると
26,063,391バイトとなり、216秒で割りbitに戻すと965,310となり
本編に940kbpsもの画質を割り当てられる事がわかります
これだけあればかなりの画質になります、動画だけでなく音に振ってあげてもいいですね

だったらみんなこの方法で作れば一般会員でも高画質動画を上げれるじゃないか、と思います
実際には落とし穴があり、ニコ動はファイルの転送速度を制限している、という事です
当然ですよね、
600kbpsを上限と設定してるんですからそれ以上の転送速度は必要ないはずなんです

実際それに近い速度に絞っていて、2分の動画を上記手法で高画質にしても
動画読み込みから8分待って再生しないと途中で止まってしまうんです(プレミアムは別)

つまり何が言いたいかと言うと
それほど画質を求めたいのならyoutubeにアップした方が楽です

ちなみにこの知識があっても良い動画が作れるかは別の話です
良い動画というのはこの程度の知識のほかにモデルのモーション、カメラモーション
エフェクトやそもそもの話の構成などが組み合わさって始めて出来る物だと思うので
まずは色々手探りで作ってみた方がいいと思います、ニコはアドバイスくれる人が多いです
他にもMMDMMM以外のソフトを使ってみたり、いろいろ試すのも大切でしょう
アルファ付きでレイヤーごとに出力して加工などぱっと考えても色々出来ます

あとモデル、モーション、ステージ、エフェクトを読み込んで音声を合わせた「だけ」の動画は
何本アップしても上達はしないと思ってます、自分で楽しむ分には全然良いのですが
上達するには触って動かして何ぼです、ニコは良いアドバイスも多いですがなんにでも
賛美する人も同様に多いのでそんな動画でもタグさえ良ければアクセスは増えます
ここが良い、とか具体的に書いてくれる人はまた違いますが良いコメントしかないので
自分の動画は良いものなのだと自惚れてしまいがちなのでどうなのかな、と思ってます
またなんにでも否定的なコメントをする人がいます、そういう否定は的外れが多いのですが
見ていて良い物ではないです、自身が付けられた事もないですが良い気がするはずないです
そういう人にわたしはかなり否定的です

同じ流し込みでもモデルに合わせてスカートや関節、歩幅が破綻しないように調整
カメラもモデルやステージに合わせてアレンジ、エフェクトもそのままでなく動画になじませる
みたいな試行錯誤をしていくうちにMMDの扱いやエフェクトの知識も増えていくと思います
ドラマ作る場合もとりあえず歩かせたりジャンプさせたり色々自分でやってみてから他の人の
動画をみると以前は気づかなかった、ここはこうした方がいいのか、という物が見えてくると
思います、数こなさないとわからないこともあるでしょう


ここからやっとMMMの話です
技術的な話はあまりないのですがモデル配布のときにいつもMMM推奨と書いてるので
少しは説明もしといた方がいいのかな、と思ったためです、あと少しコメント返しも兼ねます
今回1.1.8.4を使用しました、今書いてる時点で1.1.8.6まで出ています
更新のペースが速すぎるのでここに書いてることが合わない場合もあるかもしれないです

まずこれからMMDを始めたいという場合に「今ならMMM」という推進派がいますが
これはかなりお勧めしないです、例えるならペイントフォトショップというものがありますが
フォトショップを覚えればペイントも使える、ペイントを使える人がフォトショップを使えるとは
限らない、機能も多いフォトショップを使うべきだ!」って言ってるようなもので
ソフトとしては多機能が上でしょうが初心者への使い勝手はどうなのってのは別の話です
子供にお絵かきソフトを使わせるときにフォトショ使わせますか?ペイントでしょう

実際MMMは不具合も多く、verによって挙動も違ったりするので始めたばかりの人は
MMDで操作に慣れつつMMMが落ち着いてくるのを待つのもありと思います
ただMMDを使うのは子供ではないのでいきなりMMMでも馴染める人はいると思います
初めに触ってみてちんぷんかんぷんならMMDにしておく、という方が良いかもしれないです

ここまでコメ返し、あと実際に使って思ってることです(用語が多いです)

MMD
もなんですがスクリーンの解像度がスクリーンサイズなので出力解像度が低くても
ディスプレイのサイズが大きくてかつスクリーンを大きくしてると基本的に重いです
(MMDMMMも出力時は出力解像度で描画されています)
出力解像度以上にする意味が良くわからないのですがなぜなんでしょう
追記(130215):編集画面であってプレビュー画面ではないという事だと思います
MMMは文字の表示が出来るのですがそのときの座標指定がスクリーン座標です
つまりウィンドウのサイズを変えるたびに指定座標が変わってしまうんです
しかも出力時のサイズとスクリーンのサイズが違うと意図せず文字がずれたりします
これを防ぐにはスクリーンを別窓にして(わたしはいつも別窓ですが)
DockLayout.xml
からスクリーンサイズを出力サイズに合わせ調整、と言う事をしないと使い物になりません
(別窓にしないとキーフレームウィンドウ広げただけでサイズが変わってしまいます)

追記(130215):スクリーンのサイズを変えると明らかに計算してるラグがあり文字の絶対座標を
スクリーンにあわせて再計算してるのだと思い込んでいましたが文字座標の『管理』
「画面の中心位置からの相対位置」で行っているため編集画面に表示される数値
再計算しているだけで大本(↑これ)の数値は変わっていないようです
つまり前後の編集でスクリーンサイズを変えていても、文字の編集を行うときだけ
DockLayout.xmlからスクリーンのサイズを出力サイズに合わせることで
出力時の文字が変にならないよう確認しながら編集できます
あと文字編集で選択したまま出力するとそのまま選択状態で出力されます
これは
Moggさんに伝えれば直りそうだけどどうなのかな
(1.1.8.8で修正されました)

また、わたしは頂点数、物理演算のON/OFFに関わらずMMDよりMMMの方が重いです
ただこれは人によってMMMの方が軽い場合もある(物理オフなら)らしいです
IKの計算も遅いらしく、にがもんさんのさとりはIKループ1200回という部分があって
MMMに持っていくとちゃんと動かない、という事がありました(今は対策版が出てます)
(追記:これはMMDの計算が異常に速い、と考えた方が正しいかもしれないです
1200回というのはかなり多い上にIK対象ボーンも相当な数なので)
なおこれはセットアップのしえらさんが悪いという話ではなくむしろしえらさんは良い人です
なにしろいつもわたしの静画を公開クリップに止めてくれます
ゴリアテさんの多段ギミックが有名ですよね、さとりさんのひもIKなどもですが
有効なボーン構造を積極的に導入する人はいますが自分で考えてしまうのがすごいです

補間曲線編集機能はかなり使いやすいです、これがあるとモーションのつなぎや
タイミングのコントロールが容易くなるのでキーフレームを減らしやすくなって
モーションの作成スピードや変更するときの時間的ロスが激減すると思います
それと表情を今どのぐらい振ってあるのかがキーフレーム画面で一目瞭然です
これによって今どの表情がどのぐらいという事だけでなくキーフレームの打ち忘れで
開始フレームから徐々に変化していってる、などの間違いを発見しやすいです

物理は誰が使っても重いです、モンテコアさんの華扇ぐらいになるとうちでは無理です
あと、これは出力時レンダリングじゃなくて編集中の物理ONの話です
出力時の物理演算はMMMの方がかなり良いです、これは圧倒的で
使用したいエフェクトの制限がない場合は出力だけMMMを強く推奨します
どう違うのかはうちの萃香に20yenさんのサイバーサンダーサイダーモーションを入れて
MMDで出力、上記動画と見比べればすぐわかると思います(手の鎖は物理設定一緒です)
わたしの動画はモーションを結構な箇所調整してますがそれでも見比べればすぐわかります
そして同時に貫通対策しまくったわたしのひそかな努力に気づいてもらえるとうれしいです

あとグラボの負荷が半端無いですね、同等エフェクトであって同じエフェクトではないので
厳密には言えないのですがそれでもちょっと重すぎな気がします、こういうのはたぶん
実装方法の改良などで良く出来ると思うので今後に期待したいです

そして致命的なバグがあります、再現方法不明です
動画を作ってると一本5GBくらいなのですが、たまに50GBぐらいのものが出来てます
Windowsの機能で再生時間とビットレート見ると5GBのと一緒、もうMMMWindows
どっちがおかしいのかわからない状況ですがプロパティ見てもやっぱりでかいです
ゴミ箱入れようとするとサイズがでかいから消すって出るのでやっぱでかいのかな

追記:解像度を大きくして出力したりして一度サイズが大きいデータを作ると
上書きで保存した場合ファイルサイズが大きいサイズのままになっているようです
破棄したりしないで同じデータ領域に上書きしてるんじゃないかな、と推測

DirectShow(動画関連APIのような物)の仕様だったようです、1.1.8.8で対策されました

そんなわけなので何が何でもMMM!って言う人もいますが、考えて使用した方がいいです
MMDと比べて長所は抜群に良かったりしますが、残念ながら今のところデメリットも多いです
得意分野が違うのでどちらかでなく併用も良いと思います


あとはPmxEditorの話かな
動画を作るうえでもPmxEditorはとても便利で、使いこなすと動画の作成が楽になります
スカートの動きを重くするも軽くするも自由自在、足の貫通がどうにもならないシーンは
モーフを追加して足を透明にしてしまうのもありだと思います
ただ慣れるまではモーションで直した方がいいかモデルいじったほうがいいかの区別が
むずかしいですね、これ出来そう、と思ってPmxEいじったけど思いのほか時間が
かかってしまいこれならモーションでがんばった方が早かったかも
ってこともあると思います、今回の動画作成ではわたしは逆のことを思いましたが
これも状況でうまく使い分けれるといいですね

今回、PmxEditor0.2.1.6cを使いました、現時点で0.2.1.6dになってます
0.2.1.6cの更新点はローカル付与の仕様変更とアルファ値0の材質を表示した状態で
S影をONにするとモデル他が消えてしまう、というものと「~先」消して「~先」出して
Ctrl+zを2回で戻すと戻した「~」ボーンに入ってるのが「~先」でなく相対値になってる
現象の修正他、ぐらいだと思います

・・・はい、後半2つは初めにお読みくださいのあとがきとかに書いた内容ですね
かんなさんの生放送みてたら極北Pさんがいたので指摘したら直してくれました
基本的にはしたらばのMikuMikuDance板というところにPMDEのスレッドがあるので
そこに報告すると直してもらえそうです(って言ってました)
こういう連携というか横のつながりが簡単に出来るのがニコのいいところですね

とはいえ実はニコ生を見ることはいまだにあまりないのでこれはホントに偶然です


今回髪のボーン構造をいじったおかげで鎖の根元はずれなくなりました
またボーン数も減らしたので負荷の軽減にはなっていると思います
ただボーンを減らせば動きが固くなるのは避けようがなくどちらがいいのかは
とても判断が難しいです、そしてなによりこの変更により
ロング髪

こんな風に手軽にロング髪が出来なくなりました(画像のモデルは懐かしのv0.4です)
v0.7まではジョイントの変更だけで出来たのですがこれからはウエイト塗り直し必須です
これもv1.0になるまでに両方こなせる構造が思いつけるといいんですけど多分無理です