MMEのマネをする。その2
現状の記録。前回の続き。
あけましておめでとうございます。
今までは、MMEエフェクトを単純なxファイルへしか適応できなかったのですが、
今回、休みを利用して、PMDファイル読み込みを行い、PMDファイルへも適応できるようにしてみました。
これで、MMDと同様にMMEエフェクトファイルを使えるようになりました。
実装してみて感じるのですが、MMEの仕組みは本当に便利ですね。
MMD+MMEの資産を活用して、ゲーム作成等に活かせたら良いと思います。
(でも、エフェクトは非常に重い・・・そのままじゃ使えないかな・・・)
実装をする上で、いろいろとつまづいたり、わかったことがあったので、
後で纏めてみようと思います。
以下のモデル・エフェクトを利用させて頂きました。有難う御座います。
参考/利用させて頂いたモデル・エフェクト：
【エフェクト】
「手描き風シェーダー」：ogugu様
「MME FurShader」：ogugu様
「TexSnowLite」：そぼろ様
「AutoLuminous Ver.1.2」：そぼろ様
「TrueCamera」：そぼろ様
「SnowPlane」：ビームマン様
「MirrorWater」：ビームマン様
「Line_v4」：ビームマン様
「ParticleEX」：ビームマン様
【モデル】
「GUMIβ版」：ままま様
「ムック High Porygon Model もふもふEdition」：ちゃーりぃ様
「魔璃モデル（Ver1.10）」：そうろうＰ様
「ソフィ」：Naru-Tomorrow様
【ステージ】
「NBB ねぇ stage」：k9様
「バトーキン島」：バトーキン様
「DIVA風 鍵盤ステージ」：ブライアン成田様
「泉の洞窟」：フレスベルク様
「公園のある風景」：おやぶん様
「星空2」：3980円様
あけましておめでとうございます。
今までは、MMEエフェクトを単純なxファイルへしか適応できなかったのですが、
今回、休みを利用して、PMDファイル読み込みを行い、PMDファイルへも適応できるようにしてみました。
これで、MMDと同様にMMEエフェクトファイルを使えるようになりました。
実装してみて感じるのですが、MMEの仕組みは本当に便利ですね。
MMD+MMEの資産を活用して、ゲーム作成等に活かせたら良いと思います。
(でも、エフェクトは非常に重い・・・そのままじゃ使えないかな・・・)
実装をする上で、いろいろとつまづいたり、わかったことがあったので、
後で纏めてみようと思います。
以下のモデル・エフェクトを利用させて頂きました。有難う御座います。
参考/利用させて頂いたモデル・エフェクト：
【エフェクト】
「手描き風シェーダー」：ogugu様
「MME FurShader」：ogugu様
「TexSnowLite」：そぼろ様
「AutoLuminous Ver.1.2」：そぼろ様
「TrueCamera」：そぼろ様
「SnowPlane」：ビームマン様
「MirrorWater」：ビームマン様
「Line_v4」：ビームマン様
「ParticleEX」：ビームマン様
【モデル】
「GUMIβ版」：ままま様
「ムック High Porygon Model もふもふEdition」：ちゃーりぃ様
「魔璃モデル（Ver1.10）」：そうろうＰ様
「ソフィ」：Naru-Tomorrow様
【ステージ】
「NBB ねぇ stage」：k9様
「バトーキン島」：バトーキン様
「DIVA風 鍵盤ステージ」：ブライアン成田様
「泉の洞窟」：フレスベルク様
「公園のある風景」：おやぶん様
「星空2」：3980円様
MMEのマネをする
MMEを日々楽しく使用させて頂いてます。
MMEでは、HLSLのセマンティックス、アノテーションを使用することで、アプリケーション側とエフェクトファイル側で対話的に変数の値設定をしたり、描画タイミングを制御し、エフェクトを実装しています。
この対話的な方法を使用することで、アプリケーション側からエフェクト処理を分離することが可能になります。
MMEを使用していて、この仕組みは便利だと思いましたので、自分のプログラムでも実装してみました。
(MMEを使う前までは、HLSLのセマンティックス、アノテーションの意味がよくわからなかったけど、対話的なエフェクト処理実装のために必要だったんですね。)
実装してみると、HLSLのセマンティックス、アノテーションのスクリプト解析プログラムを書くのは大変でしたが、今までアプリケーション側でガリガリ書いていた、特定のエフェクト処理のための汎用的ではないコードが消えスッキリしました。また、MMEで使用されているエフェクトが自分のプログラムで使えるのはおもしろいです。
今後、hlslを業務で使うことはないかもしれませんが、役に立つといいなあ。
「ビームマンさんのMirrorWaterエフェクトを使わせていただきました」
実装する場合のポイントメモ：
(1)
・MME付属のREFERENCE.txtは丁寧に仕様が決められているので、REFERENCE通りに作れば作れる。
(2)
・「_INDEX」セマンティックスは、以下のことである。
D3DVERTEXELEMENT9の
Usage = D3DDECLUSAGE_PSIZE
UsageIndex = 15
・エフェクトファイルを読む時にD3DXCreateEffectFromFile関数のpDefines引数を使用して、「_INDEX」を「PSIZE15」に置き換えれば良い。以下を引数に設定する。
//MMEで使用されるエフェクトで使われているマクロを定義する。
D3DXMACRO d3dxMacros[2] =
{ //マクロ マクロ名
{"_INDEX","PSIZE15" },// <-- ここで定義する部分を設定して
{ 0, 0 }// <-- ここで終端を示すようにヌルターミネートしておく
};
(3)
・MMEで使用されているDirectX SDKのversionは、DirectX SDK February 2007。
・MMEのエフェクトファイル読み込み時には、D3DXCreateEffectFromFile関数のD3DXSHADERコンパイル オプション引数に、「0」をしている。
・最近のDirectX SDKを使用する場合は、「D3DXSHADER_ENABLE_BACKWARDS_COMPATIBILITY」か「D3DXSHADER_USE_LEGACY_D3DX9_31_DLL」を指定すればよい。
※(2)(3)は、某掲示板で教えてもらいました。有難うございます。
参考：
『DirectX SDKのEffectEditサンプル』
http://msdn.microsoft.com/ja-jp/library/cc324434.aspx
※セマンティックス、アノテーション解析sample。
『VPVP wiki - 拡張表示系ツール』
http://www6.atwiki.jp/vpvpwiki/pages/219.html#MME
※MMEの場所。
『ビームマンのエフェクト置き場』
http://www43.atwiki.jp/beamman/
※エフェクト使わせてもらいました。有難うございます。
『CompileEffect - すらりん日記』
http://watery.dip.jp/~slash/0130
http://watery.dip.jp/slash/archives/134
※D3DXMACROについて参考にしました。有難うございます。
MMEでは、HLSLのセマンティックス、アノテーションを使用することで、アプリケーション側とエフェクトファイル側で対話的に変数の値設定をしたり、描画タイミングを制御し、エフェクトを実装しています。
この対話的な方法を使用することで、アプリケーション側からエフェクト処理を分離することが可能になります。
MMEを使用していて、この仕組みは便利だと思いましたので、自分のプログラムでも実装してみました。
(MMEを使う前までは、HLSLのセマンティックス、アノテーションの意味がよくわからなかったけど、対話的なエフェクト処理実装のために必要だったんですね。)
実装してみると、HLSLのセマンティックス、アノテーションのスクリプト解析プログラムを書くのは大変でしたが、今までアプリケーション側でガリガリ書いていた、特定のエフェクト処理のための汎用的ではないコードが消えスッキリしました。また、MMEで使用されているエフェクトが自分のプログラムで使えるのはおもしろいです。
今後、hlslを業務で使うことはないかもしれませんが、役に立つといいなあ。
「ビームマンさんのMirrorWaterエフェクトを使わせていただきました」
実装する場合のポイントメモ：
(1)
・MME付属のREFERENCE.txtは丁寧に仕様が決められているので、REFERENCE通りに作れば作れる。
(2)
・「_INDEX」セマンティックスは、以下のことである。
D3DVERTEXELEMENT9の
Usage = D3DDECLUSAGE_PSIZE
UsageIndex = 15
・エフェクトファイルを読む時にD3DXCreateEffectFromFile関数のpDefines引数を使用して、「_INDEX」を「PSIZE15」に置き換えれば良い。以下を引数に設定する。
//MMEで使用されるエフェクトで使われているマクロを定義する。
D3DXMACRO d3dxMacros[2] =
{ //マクロ マクロ名
{"_INDEX","PSIZE15" },// <-- ここで定義する部分を設定して
{ 0, 0 }// <-- ここで終端を示すようにヌルターミネートしておく
};
(3)
・MMEで使用されているDirectX SDKのversionは、DirectX SDK February 2007。
・MMEのエフェクトファイル読み込み時には、D3DXCreateEffectFromFile関数のD3DXSHADERコンパイル オプション引数に、「0」をしている。
・最近のDirectX SDKを使用する場合は、「D3DXSHADER_ENABLE_BACKWARDS_COMPATIBILITY」か「D3DXSHADER_USE_LEGACY_D3DX9_31_DLL」を指定すればよい。
※(2)(3)は、某掲示板で教えてもらいました。有難うございます。
参考：
『DirectX SDKのEffectEditサンプル』
http://msdn.microsoft.com/ja-jp/library/cc324434.aspx
※セマンティックス、アノテーション解析sample。
『VPVP wiki - 拡張表示系ツール』
http://www6.atwiki.jp/vpvpwiki/pages/219.html#MME
※MMEの場所。
『ビームマンのエフェクト置き場』
http://www43.atwiki.jp/beamman/
※エフェクト使わせてもらいました。有難うございます。
『CompileEffect - すらりん日記』
http://watery.dip.jp/slash/archives/134
※D3DXMACROについて参考にしました。有難うございます。
MMDAgentメモ
CEATEC JAPAN 2010を見に行った時に気になっていた「MMDAgent」が公開されていたのでメモ。
「修正BSDライセンス」の下で、ソースが公開されています。
PMDのファイル読み込み、表示、物理シミュレーション、言葉認識とか是非参考にしたいですね。
http://www.mmdagent.jp/
「修正BSDライセンス」の下で、ソースが公開されています。
PMDのファイル読み込み、表示、物理シミュレーション、言葉認識とか是非参考にしたいですね。
http://www.mmdagent.jp/
自然画像に対する球面調和関数の展開
3Dで使われることがある球面調和関数の勉強として、
球面調和関数を使用し、単純な画像変換を行ってみました。
球面調和関数とは？：
直感的に分かりやすい紹介をしてくれている
【コラム】3Dグラフィックス・マニアックス (68) 事前計算放射輝度伝搬(PRT)〜PRTの基本。静的PRT(3) | パソコン | マイコミジャーナル
によると（引用）
『球面調和関数とは、かなり極端に簡略化して説明すると、球っぽいモノから任意の長さの針が突き出た「いびつなウニ」みたいな物体の形状を数学的な関数で表すためのもの……といえる(ウニの針が逆に凹んでいる場合もある)。』
『MPEGやJPEGの圧縮に用いられる離散コサイン変換の「球体バージョン」ということができるかもしれない。』
ということである。（ウニという表現が非常にGoodだと思います。）
この球面調和関数を使うことで、球面上の位置を使って定義される関数を球面調和関数展開し、
近似関数をつくることができる。
高次の係数（ほぼ0に近くなる）を無視すれば、情報の圧縮が可能になります。
情報の圧縮が目的です。
本当に綺麗に近似できるのかと思ったので、
今回、次のような自然画像を球面上の二つの半球面に
それぞれ正射影で貼り付けられているモノとして考え、
球面調和関数展開を行って係数を計算し、
その係数を作った近似関数から画像を再構築してみました。
計算式は、
t-pot『テイラー、フーリエ、球面調和関数』で
紹介されていた式を離散的なものに修正して使用しました。
[結果]
元画像:
l=0の時(係数は1個) ｌ=5の時(係数は36個) ｌ=20の時(係数は441個)
l=50の時(係数は2601個)
「う〜ん・・」な結果となりました。
記事では、解像度の低い32×32テクセルの6面体のキューブ環境マップの例を使い、
「実用レベルで係数は16個程度でも十分」と書かれていますが、
今回使ったのは、512*512の画像です。
結果を見る限り、少ない係数では悲惨な状況になっており、
解像度が高い場合は、多くの係数を必要とすることが
分かりました。
*記事で係数は16個程度でも十分と書かれている理由は、
32*32の解像度の低い自然画像を用いており、解像度の低い画像は、
詳細部分が失われ周波数の低い画像となっているためだと考えられます。
そもそも、解像度の高い球面全体の自然画像に対して、球面調和関数展開しても、
球面全体の自然画像では、周波数が高くなり、高次の係数が必要になってきます。
ですので、解像度の高い球面全体の自然画像に対して、
球面調和関数展開するのは、よくないと思いました。
今回の実験を行ってみて、フーリエ級数の「球体バージョン」ということを
感じ取ることができました。
もっと調べてみるとおもしろそうです。
仕事忙しいけど、こつこつやってみよう！
参考：
【コラム】3Dグラフィックス・マニアックス (68) 事前計算放射輝度伝搬(PRT)〜PRTの基本。静的PRT(3) | パソコン | マイコミジャーナル
http://journal.mycom.co.jp/column/graphics/068/index.html
t-pot『テイラー、フーリエ、球面調和関数』
http://www.t-pot.com/program/88_SH/index.html
球面調和関数を使用し、単純な画像変換を行ってみました。
球面調和関数とは？：
直感的に分かりやすい紹介をしてくれている
【コラム】3Dグラフィックス・マニアックス (68) 事前計算放射輝度伝搬(PRT)〜PRTの基本。静的PRT(3) | パソコン | マイコミジャーナル
によると（引用）
『球面調和関数とは、かなり極端に簡略化して説明すると、球っぽいモノから任意の長さの針が突き出た「いびつなウニ」みたいな物体の形状を数学的な関数で表すためのもの……といえる(ウニの針が逆に凹んでいる場合もある)。』
『MPEGやJPEGの圧縮に用いられる離散コサイン変換の「球体バージョン」ということができるかもしれない。』
ということである。（ウニという表現が非常にGoodだと思います。）
この球面調和関数を使うことで、球面上の位置を使って定義される関数を球面調和関数展開し、
近似関数をつくることができる。
高次の係数（ほぼ0に近くなる）を無視すれば、情報の圧縮が可能になります。
情報の圧縮が目的です。
本当に綺麗に近似できるのかと思ったので、
今回、次のような自然画像を球面上の二つの半球面に
それぞれ正射影で貼り付けられているモノとして考え、
球面調和関数展開を行って係数を計算し、
その係数を作った近似関数から画像を再構築してみました。
計算式は、
t-pot『テイラー、フーリエ、球面調和関数』で
紹介されていた式を離散的なものに修正して使用しました。
[結果]
元画像:
l=0の時(係数は1個) ｌ=5の時(係数は36個) ｌ=20の時(係数は441個)
l=50の時(係数は2601個)
「う〜ん・・」な結果となりました。
記事では、解像度の低い32×32テクセルの6面体のキューブ環境マップの例を使い、
「実用レベルで係数は16個程度でも十分」と書かれていますが、
今回使ったのは、512*512の画像です。
結果を見る限り、少ない係数では悲惨な状況になっており、
解像度が高い場合は、多くの係数を必要とすることが
分かりました。
*記事で係数は16個程度でも十分と書かれている理由は、
32*32の解像度の低い自然画像を用いており、解像度の低い画像は、
詳細部分が失われ周波数の低い画像となっているためだと考えられます。
そもそも、解像度の高い球面全体の自然画像に対して、球面調和関数展開しても、
球面全体の自然画像では、周波数が高くなり、高次の係数が必要になってきます。
ですので、解像度の高い球面全体の自然画像に対して、
球面調和関数展開するのは、よくないと思いました。
今回の実験を行ってみて、フーリエ級数の「球体バージョン」ということを
感じ取ることができました。
もっと調べてみるとおもしろそうです。
仕事忙しいけど、こつこつやってみよう！
参考：
【コラム】3Dグラフィックス・マニアックス (68) 事前計算放射輝度伝搬(PRT)〜PRTの基本。静的PRT(3) | パソコン | マイコミジャーナル
http://journal.mycom.co.jp/column/graphics/068/index.html
t-pot『テイラー、フーリエ、球面調和関数』
http://www.t-pot.com/program/88_SH/index.html
