|
ハードディスクがクラッシュしちゃいました。
というわけで、スペキュラーの話題のときにたくさんいただいたお便りも(T_T)。どうしてこう僕のマシンは不安定なんざんしょ。え、NT入れろって?そういうわけにもいかないんですよねまだまだ。
スペキュラーの時に、とりあえずRekiさんとMasaさんと21's Evilさんから、「式が違う!」といわれてしまいました。そう。またやっちゃったんです。オオボケを。
あれだけ得意げに式を提示しておきながら間違っているとは我ながら情けない。どこが間違いだったかというと、s = l + 2b ではなくて、lの符号が逆で、s = 2b -lなのではないかということなんですが、これはまったくその通り!で、もう弁解のしようもありません。
弁解しておくと(しようもないんじゃないの?)、vectorStormの中では自動的に光線ベクトルの符号が反転しているので、僕のプログラムの中では光線ベクトルの矢印は逆むきだったのです。だからvectorStormの中で使っている式をそのまま書いちゃったんですな。いやぁ、またしてもいい恥かきました。
さて、そんなわけでまたしてもshi3zヨワヨワじゃーんといじめられてしまいそうなので、とりあえず今日はずっと先延ばしにしていた環境マッピングの話でもしてお茶を濁そうと思います。意外とこの話題、国内のページではMasaさんのとこくらいでしかお目にかかれません。
Masaさんは前回このページで説明したようなスペキュラーの計算方法(Phongの方法といいます)以外にBlinnの方法というものがあることを教えてくれました(あ、でもそれは応用グラフィックスに載ってましたね)。 できればこのページで紹介したかったのになくてしまって本当に残念です(T_T)
|
|
|
|
汚職事件がニュースを賑わすのが当然となってしまったこの世の中、われらがパソコン業界も、トップレベルではドロドロとしたスゴイ争いがいきまいています。
われわれエンドユーザーのレベルではもはやどうでもいいような事態ですが、政治が庶民の暮らしに無関係でないように、われわれにとっても不誠実なものが誠実なものを上回ってしまうことが度々発生するという不幸な現実があります。
むしろアルゴリズムというのはいかに不誠実であるかを競うようなものと言っても良いでしょう。良いプログラマーは善良なペテン師であるという古言がありますが、まさにそのとおりです。
そもそも金属的な質感や光沢を出そうという発想にもっとも誠実といえるのは、おそらくレイ・トレーシング法やラジオシティ法に代表される光線追跡法でしょう。さらに空気のボリュームレンダリングなどを加えるとより誠実であるといえるかもしれません。しかし、誠実な方法は誠実ゆえに要領よく仕事をこなすことができません。
現在のパソコンでは、できうる限り誠実にコンピュータ・グラフィックスを描画するプログラムを作ると、ものにもよりますが莫大な時間がかかってしまい、とてもリアルタイムの処理には使えたものではありません。
そこで完全に同じとはいかないまでもあまり違いが気にならないレベルでの近似・・・つまり不誠実だが高速なアルゴリズムがたくさん考えられました。
前回のスペキュラーの計算も、環境マッピングもそれらのうちのひとつです。
さて、環境マッピングというのは、いわゆる「映り込み」を再現するために考え出されました。
映り込みというのは、金属などの表面に、周りの風景(つまり環境)が反射することを言います。いかにも金属質なものというのは、まわりの環境が強烈に映り込んでいるものがほとんどです。そう。ちょうどパチンコ球などを想像していただければ、おわかりになるでしょうか。
その現象を誠実に再現するには、光線の追跡をシミュレーションするのが今の物理学で考えられるもっとも現実的な計算法ですが、これには前述のように莫大な時間がかかってしまいます。
そこで、これを擬似的に解決するために、環境マッピングは右図のように物体の周囲の環境を一枚の絵に投影してしまいます。この絵を環境マップと呼びます。
これはちょうど、地球からメルカトル図法の地図をつくることに似ています。メルカトル図法の地図は、地球を円筒に投影して広げたものにたとえることができますが、まさにその計算を事前にしておくのです。
こうして制作した環境マップを、物体に貼り付けるのが環境マッピングです。
貼り付けかたは、作成時の手順とまるきり逆で、今度はメルカトル図法の地図を球に貼り付けて地球儀をつくるようなものです。
ただし、このままではただの球形マップとまったく同じです。環境マッピングは環境マッピング用の座標系が固定されている点が違います。つまり、ふつうに球形マップの場合は、マッピングしたあと球が回転するとマップも回転しますが、環境マッピングの場合はマップは固定されたままです。そうしないとまわりの環境との整合性がおかしなことになるのは説明するまでもありませんね。
このような計算は要するに、法線ベクトルから極座標に変換すればテクスチャマップ用のUV座標が求まるのですが、このためには三角関数がたくさんでてきます。基本的に浮動小数点演算なので、整数のように馬鹿の一つ覚え的にテーブルを使いまくるわけにもいきません。
これを解決するためのとっておきの不誠実な方法が、フェイク・マッピングと呼ばれるものです。
これは、法線ベクトルから極座標を求めるなどというまどろっこしい方法を使わずに、絶対座標系に変換された(これ重要)法線ベクトルをXY座標系に正射影(Z値を無視して二次元座標に変換)して、それをそのままUV座標として使うものです。
これは使いようによっては爆発的に計算量が減ります(ただし、もともと極座標で法線ベクトルを保持しておいて、必要におうじてオイラー角単位で回転するという方法もありますが、オイラー角を求めるためにきわめてダサイ式と場合分けを用いなくてはならず、エレガントではありません)。
ただし、これはさすがにフェイクと呼ばれるだけあって、360度どの方向からみても完璧というわけにはいきません。なぜなら、上から見ると、Zが違うものでもすべてのUV座標が同じ値になっているはずで、これではきわめて不自然な描画になってしまいます。
が、世のメガデモと称するデモはこれでも上手く誤魔化して使っていますから、あまり深く追求しなければ使えるでしょう(これも限定条件の多すぎるメガデモのアルゴリズムの実用性が低い事実を指してるといえます)。
二次元的な移動をするだけのゲームなら十分使えそうですが、大切なことは環境マッピングしてるゲームなんてほとんどみたことない!ってことかもしれません。なんでざんしょ。
まぁ理由は簡単で、ゲームにはあまり金属質なのを出してもしょうがない場合が多々あるんですな。映画とかを見ればわかるように、映像表現のなかで金属質の表現というのは、めったに必要に迫られません。これがまぁ、僕がメガデモ無意味論を唱えるもうひとつの理由でもあるのですが(同様に最近流行りのメタボールも映像表現としてみれば無意味な要素がほとんどです)。
しかし3Dシステムとしては派手な映像表現は大きなセールスポイントとなるでしょうから、搭載しないわけにはいきません。そこで搭載してみました。
といっても、まだテストプログラムの段階ですが、やはり金属的な物体を表現するときにはかなり有効っぽいので、ぜひみなさんにもご覧いただきたいと思い、実行コードを公開します。DirectX5に対応したハードならまず見れると思いますので、ぜひご照覧ください。
起動時に最適化を行うため、数十秒待ちが入り(この最適化作業は近いうちにプリプロセスできるようになります)、画面が止まりますが、かまわず待っていると右図のようなポットが登場します。
4色光源とスペキュラー・ライティングを使用しています。うちの環境では60fpsで動作していますが、動作報告をいただけたら幸いです。
DOWNLOAD [emvmap.zip]
※ 明らかに私の不備だが、このプログラムは右クリックでの終了にのみ対応している。左クリックをすると確実に一般保護違反がおきるので注意していただきたい(なおせよ>おれ)
|
|
|