[MMD]MHX2Importと標準化プラグイン
Makehumanの最新版から出力されるMHX2形式に対応したインポータです。
物凄く遅いです。
MHX2形式を開いてみるとMHX形式とは全く異なる内容でしたので、分析から始め直すことになりました。
どんなデータ要素があるのかと分析するためにトークン解析器を作ったのですが、この解析器をそのままインポータに流用しているため、とんでもなく遅いです。
でもまぁ、使用頻度が高いものではないので、それほど高速化する必要は無いのかもしれません。
インポート時に使用しているデータ要素は、ごくごく一部です。
ウェイト関連のデータが格納されているようですが、これらを反映させると衣装関連のウェイトが是正されるかもしれません。
でも、どうせ私は裸でしか使わないし……
MHX2にあるデータ要素は全てクラスに一旦格納して、そこからPMX形式に変換しています。
MHX2を格納したクラスはPublicで作ったような気がしますので、適当にリンクしてもっと良いインポータを作っていただいてもOKですし、必要でしたらライブラリの形式で提供します。
https://bowlroll.net/file/174297
物凄く遅いです。
MHX2形式を開いてみるとMHX形式とは全く異なる内容でしたので、分析から始め直すことになりました。
どんなデータ要素があるのかと分析するためにトークン解析器を作ったのですが、この解析器をそのままインポータに流用しているため、とんでもなく遅いです。
でもまぁ、使用頻度が高いものではないので、それほど高速化する必要は無いのかもしれません。
インポート時に使用しているデータ要素は、ごくごく一部です。
ウェイト関連のデータが格納されているようですが、これらを反映させると衣装関連のウェイトが是正されるかもしれません。
でも、どうせ私は裸でしか使わないし……
MHX2にあるデータ要素は全てクラスに一旦格納して、そこからPMX形式に変換しています。
MHX2を格納したクラスはPublicで作ったような気がしますので、適当にリンクしてもっと良いインポータを作っていただいてもOKですし、必要でしたらライブラリの形式で提供します。
https://bowlroll.net/file/174297
[MMD]XXXROID YUKARI
サイバースペース風実験
作成中の動画の演出に使えないかと、昨日のお仕事中に思いついたので実験です。
昔のCG映画やアニメで見る演出ですが、ローポリ風の緑色のポリゴンで構成されたステージ。
攻殻機動隊やMATRIXで見かけるかもしれません。
こういう感じの映像です。
テストとしてはこにわ様が販売されているカスタム少女用の病室ステージを使ってみましょう。
まず最初に思いついたのが、MMEの Grid
これはこれでカッコイイのですが、メッシュがちょっと目立ちすぎて目的とは違った感じですね。
設定で減らせるのかな？
次に思いつくのは、動画編集側での単色化。
うん。違いますね。
このステージは綺麗なテクスチャが貼られているのですが、それが邪魔しているようです。
ここまでは、だいたい予想通りでした。
そして、昨日思いついたのは、テクスチャを単色で塗りつぶしてしまったらどうなるかな？です。
こんな感じ。使えそうです。
少し、透明度を上げてみましょう。
おお、もう一息といったとこですね。
エッジを描画すればよくなりそうに思います。
解説としては、以下の方法でモデル改造をしています。
1.材質に含まれる面を取得する
2.面がマッピングされている画像を調べて、平均の色を取得する
3.求めた平均の色を16諧調のグレースケール変換し、別途用意した16諧調の材質にマッピングしなおす
カーテンのところを見ればわかりますけど、隣り合った面なのにガッツリと色が変わってますね。
これは平均の求め方が悪いのか、作ったスクリプトにどこかにバグがあるのか。
動画に使えそうかな？
使いものになりそうであれば、プラグイン化したいところですが、いくつか課題はあるのでコスト面であまり割に合わないかも。
昔のCG映画やアニメで見る演出ですが、ローポリ風の緑色のポリゴンで構成されたステージ。
攻殻機動隊やMATRIXで見かけるかもしれません。
こういう感じの映像です。
テストとしてはこにわ様が販売されているカスタム少女用の病室ステージを使ってみましょう。
まず最初に思いついたのが、MMEの Grid
これはこれでカッコイイのですが、メッシュがちょっと目立ちすぎて目的とは違った感じですね。
設定で減らせるのかな？
次に思いつくのは、動画編集側での単色化。
うん。違いますね。
このステージは綺麗なテクスチャが貼られているのですが、それが邪魔しているようです。
ここまでは、だいたい予想通りでした。
そして、昨日思いついたのは、テクスチャを単色で塗りつぶしてしまったらどうなるかな？です。
こんな感じ。使えそうです。
少し、透明度を上げてみましょう。
おお、もう一息といったとこですね。
エッジを描画すればよくなりそうに思います。
解説としては、以下の方法でモデル改造をしています。
1.材質に含まれる面を取得する
2.面がマッピングされている画像を調べて、平均の色を取得する
3.求めた平均の色を16諧調のグレースケール変換し、別途用意した16諧調の材質にマッピングしなおす
カーテンのところを見ればわかりますけど、隣り合った面なのにガッツリと色が変わってますね。
これは平均の求め方が悪いのか、作ったスクリプトにどこかにバグがあるのか。
動画に使えそうかな？
使いものになりそうであれば、プラグイン化したいところですが、いくつか課題はあるのでコスト面であまり割に合わないかも。
VMDSpectrum対応ステージの実験
ふと思付いたミニ動画を作成しようと、ダンスステージを探していました。
探していたのは VMDSpectrum で音に合わせて派手に明滅するステージ。
そうして見つけたのが、くうわんこ様の「ダンスステージ」です。
バックスクリーンがキラキラと輝く素敵なステージです。
まさに探していた通りのステージです。カッコイイ。
さて早速、VMDSpectrumで音データからVMDデータを作成し、読み込ませてみると・・・・
ガーン。めったに見ない制限にかかってしまいました。
このステージのバックスクリーンは、シンメトリ版で173のバンド数から成るので、20000÷173＝156フレームしか光らせることができない計算になります。
２フレーム置きに光らせたとしても、231フレームしか動画が作成できないことに。
本当なんでしょうか。
VMDSpectrumでステージを光らせる動画はソコソコ見かけるように思いますので、私が勘違いしている可能性が高いです。
数百フレームごとに動画を分割して出力しているとは、ちょっと信じられないので何かテクニックがあるのかもしれません。
ともかく、この制限にひっかかったことによって思いついた実験です。
このステージはバックのライトの１つ１つが材質に分かれていて、それぞれに設定された材質モーフを動かすことで個別に発光させる仕組みになっています。
こんなかんじ。
これを材質モーフではなく、screen.bmp による背景AVIで発光させることはできないか？というのが実験主旨です。
これならモーションを読み込ませる必要が無いので、登録ポイント数の限界の問題は解消されます。
まず第一段階。
バックスクリーンにある無数のライトをUV展開します。
本当はキッチリと展開する必要もないのですが、将来を考えてそれなりにUV展開することにします。
手作業でやっていると大変なので、スクリプトを書いて展開します。
こんな感じに、敷き詰めて展開します。
そして第二段階。
VMDSpectrumで出力したVMDファイルに基づいて、背景AVIファイルを作成します。
第一段階でUV展開された各ライトと対応するUV位置に、モーションの値に基づいた輝度を出力していきます。
こんな感じのAVIになります。
そしてバックスクリーンをscreen.bmpにUV展開したステージモデルと、背景AVIを読み込んで再生！
あるぇぇ・・・・光ってくれない。
MMDではPMXモデルにscreen.bmpは使えませんので、CVN68Nimitz様のDummyScreenCopyを使用しています。
一応、目論見通り、背景AVIの各部分が対応するバックスクリーンのライトに当たっている・・・ような気がしますが、ライトは薄暗く光るだけです。
AutoLuminousの仕組みはよくわかっていないのですが、うまくすれば光ってくれるかなと思っていたのですが。
ちょっと調べてみないとわからないですが、なんだかうまくいかなさそう。
他にも課題はあるので、実験は失敗かも？
探していたのは VMDSpectrum で音に合わせて派手に明滅するステージ。
そうして見つけたのが、くうわんこ様の「ダンスステージ」です。
バックスクリーンがキラキラと輝く素敵なステージです。
まさに探していた通りのステージです。カッコイイ。
さて早速、VMDSpectrumで音データからVMDデータを作成し、読み込ませてみると・・・・
ガーン。めったに見ない制限にかかってしまいました。
このステージのバックスクリーンは、シンメトリ版で173のバンド数から成るので、20000÷173＝156フレームしか光らせることができない計算になります。
２フレーム置きに光らせたとしても、231フレームしか動画が作成できないことに。
本当なんでしょうか。
VMDSpectrumでステージを光らせる動画はソコソコ見かけるように思いますので、私が勘違いしている可能性が高いです。
数百フレームごとに動画を分割して出力しているとは、ちょっと信じられないので何かテクニックがあるのかもしれません。
ともかく、この制限にひっかかったことによって思いついた実験です。
このステージはバックのライトの１つ１つが材質に分かれていて、それぞれに設定された材質モーフを動かすことで個別に発光させる仕組みになっています。
こんなかんじ。
これを材質モーフではなく、screen.bmp による背景AVIで発光させることはできないか？というのが実験主旨です。
これならモーションを読み込ませる必要が無いので、登録ポイント数の限界の問題は解消されます。
まず第一段階。
バックスクリーンにある無数のライトをUV展開します。
本当はキッチリと展開する必要もないのですが、将来を考えてそれなりにUV展開することにします。
手作業でやっていると大変なので、スクリプトを書いて展開します。
こんな感じに、敷き詰めて展開します。
そして第二段階。
VMDSpectrumで出力したVMDファイルに基づいて、背景AVIファイルを作成します。
第一段階でUV展開された各ライトと対応するUV位置に、モーションの値に基づいた輝度を出力していきます。
こんな感じのAVIになります。
そしてバックスクリーンをscreen.bmpにUV展開したステージモデルと、背景AVIを読み込んで再生！
あるぇぇ・・・・光ってくれない。
MMDではPMXモデルにscreen.bmpは使えませんので、CVN68Nimitz様のDummyScreenCopyを使用しています。
一応、目論見通り、背景AVIの各部分が対応するバックスクリーンのライトに当たっている・・・ような気がしますが、ライトは薄暗く光るだけです。
AutoLuminousの仕組みはよくわかっていないのですが、うまくすれば光ってくれるかなと思っていたのですが。
ちょっと調べてみないとわからないですが、なんだかうまくいかなさそう。
他にも課題はあるので、実験は失敗かも？
[MMD]ホワイトデーゆかりさん
ゆかりさん・・・バレンタインデーのお返しをするね。
すっかり小ネタ動画制作者になってる昨今ですが、久しぶりの動画もやっぱり小ネタです。
[広告 ] VPS
こんなヒドイ仕打ちをされるようなこと、いったいゆかりさんは何をバレンタインデーにやらかしたのでしょうか。
それにしてもこのマスターはバカですね。
話は変わりますが、ＦＣ２は動画を投稿するときにカテゴリを選択しなければなりません。
カテゴリはいろいろとあるのですが、MMD動画を投稿するとなると、しっくりと当てはまるカテゴリが無くて結局はいつも「アニメ・エロゲ」として投稿しています。
アニメ・エロゲを期待して動画を開いた人には申し訳ありません。
そして今回、いつものとおり「アニメ・エロゲ」のカテゴリでゆかりさんの動画を投稿しようと、アップロード画面を開くとそこには・・・
選びたかったけれど自制しました。
ほめて。
すっかり小ネタ動画制作者になってる昨今ですが、久しぶりの動画もやっぱり小ネタです。
[広告 ] VPS
こんなヒドイ仕打ちをされるようなこと、いったいゆかりさんは何をバレンタインデーにやらかしたのでしょうか。
それにしてもこのマスターはバカですね。
話は変わりますが、ＦＣ２は動画を投稿するときにカテゴリを選択しなければなりません。
カテゴリはいろいろとあるのですが、MMD動画を投稿するとなると、しっくりと当てはまるカテゴリが無くて結局はいつも「アニメ・エロゲ」として投稿しています。
アニメ・エロゲを期待して動画を開いた人には申し訳ありません。
そして今回、いつものとおり「アニメ・エロゲ」のカテゴリでゆかりさんの動画を投稿しようと、アップロード画面を開くとそこには・・・
選びたかったけれど自制しました。
ほめて。
