独り言日記（2004/10）

独り言日記

スカイライト（2004/10/31）

10/31でのDOFですが、「焦点は面で考えたほうがいいよん」というツッコミをいただきまして、RRT本を参考にしてまた練って見ることにします。品質が向上するらしいっす。

話変わってフォトンマップベースのスカイライト対応、ようやくできました。ノイズが低周波であるのと計算時間がパストレよりは軽いというのが利点なのですが、ほぼパストレとのハイブリッド仕様になってます。

スカイライト（白色）のみのシーン

HDRIのみによるシーン

HDRI(IBL)のほうは、特に指向性の光源をおいていないのですがうっすらと影ができています（この影は直接照明（IBL）によるもの）。アルゴリズムについてはオリジナルですが、時が経ったら公開予定です。（大したことはない力業ですが）

ただ、HDRIのレンジが大きすぎて全体的に色が飛んでしまうため、丸めている部分があるのですが、たぶん勘違いしてるんだろうなぁ。

DOF（2004/10/30）

DOF(Defth of field：被写界深度)をレンダラで実装してみました。Cマガジンの2000年10月号の金子さんの記事を参考にさせていただきました。DOFは、カメラがピントを合わせる処理を表現するもので、「ぼけ」によりリアリティを出します。実際はカメラのレンズサイズや厚み・ピントのしぼりなどによるものなので（＜このあたりは専門でないのでよく知らないですが(^_^;;）、以下はフェイクになるのですが 焦点位置を中心に視点をぶらすことによりボケを表現しています。

焦点はかわらずに視点位置と視線ベクトルが変わります。指定の範囲の角度内でランダムで方向をずらします。焦点が変わらないので、視点は焦点を中心に「焦点と（本来の）視点を結ぶ線の距離」を半径とした球の表面上に存在することになります。パラメータとしてはブレの許容角度とサンプリング数のみ。サンプリング数の分だけ、それぞれの視点・視線から見た画像を生成します。そして生成した画像を合成することにより、「焦点を中心に手前はボケて奥がボケる」というのが表現できます。

レイトレでのDOFは、リアルタイムの場合と違って複数の画像を生成した後に合成、とはしない場合が多いと思います。のでちょっと変形して、１回のスクリーンに向かうレイトレース処理（1ピクセルの処理）にて、視点と視線方向をぶらして複数サンプリングを行い、１ピクセルごとに合成処理を行います（結局は同じことになるのですが）。

結果、以下のようにぼけが表現できました。

DOF使用前

DOF使用後（DOFサンプリング数 12、ブレの許容角度 12°）

赤い球の中心を焦点位置にしています。

ただ推測できるように、（単純に考えると）DOFのサンプリング数倍処理時間がかかります。普通に数枚のレンダリングをしているのと同じくらい時間を食ってしまうわけです。これ、最適化できないかなぁ。例えば、焦点付近ではブレは少ないので、サンプリングをスキップして補間するとか。

現状は、Shadeでの「DepthPlus」みたいにポストエフェクトでやるほうがいいかもしれませんね。単純なシーンでも、反射・屈折が増えるとたまらなく待たされましたので(^_^;;。

ちなみに、DOFの合成の際にブレを固定のランダムにして多重合成してるだけだと、サンプリング数が少ない場合に段階が分かってしまいます。ランダムに散らすことはできるのですが、どうしてもゴマが残ってしまうために（あまりきれいでない）あえてノイジーでないクッキリ方式をとっています。＜日本語がものすごい変だ・・・(^_^;;。

デフォルトゲートウェイ（2004/10/29）

どうやら先日は、おもいっきり勘違いしていたみたいでLAN内のゲートウェイとして（外向けの）グローバルアドレスを指定していました。内部向け（LAN）の方のNICでのIPを指定するんですね。というよりも、1つのネットワークのくくりの概念をいまいち理解してませんでした(^_^;;。そして、ゲートウェイの役割がようやく見えた感じです（ようは中立地帯（かつネットワーク同士の橋渡し）ですな）。またそのあたりもまとめることにしますが、一部の情報はシステム構築のところに追記しています（Wikiはどこでも気軽に更新できるからラクチンです）。

NIC（2004/10/28）

サーバ構築してるんですが、RedHat9マシンで新たに追加したギガビットイーサの挙動がおかしい・・。ifconfigでは認識してるのですが（ドライバはコンパイルしました）外部Linuxマシンからデフォルトゲートウェイとしての認識ができないっす（Winからはいけるんですが）。

どうやら、２枚挿したうちの１枚のNICはどうやら認識できなくなった模様。ってことで終電も無くなったので徹夜でサーバ構築です(T_T)。教訓として「安物のNICは買ってはいけない」と身にしみて思いました。さて、OS再インストールするかな。

面光源の最適化（2004/10/27）

レンダラを作るにあたっては、面光源のゴマ状ノイズがネックになります。サンプリング数を上げると対応できるのですが、時間が他の光源に比べて圧倒的に不利です。

速度と品質、ダブルパンチですね。ですが、時間をかければ驚くほど高品質な照明を作り出すことができるという諸刃の剣です。面光源が高周波ノイズなのは、直接照明時にランダムで散らすためです。

で、面光源の「ゴマ状」を回避するアルゴリズムを思いついてしまいました。もしかしたら車輪の再発明かもしれないですが、シャドウフォトンを使わずにきれいにぼかします。シャドウマップでもないです。ガウスフィルタみたいのでもないです。ボケ影と正影で分けて処理しているわけでもありません。

面光源のサンプリング数が12

普通に面光源を使った場合は、近寄って見るとゴマが目につき、またアニメーション時でもちらつく可能性があります。今回考えたアルゴリズムでは、ゴマ状にもならないし、かかる時間も同じ、かつアニメーション時でも（面光源部分に関しては）ちらつかないです。

まぁ、シャドウフォトンを使ったほうが速く求まるのですがボケすぎる場合がある、ということで選択できるようにはしたほうがいいですね。

RedHat9（2004/10/26）

先日、FedoraCore2を仕事場のマシンに入れようとしてあっさり失敗したのですが、RedHat9ではあっさりいけました。この〜、DELLマシンめっ。

で、0からオフィスの環境構築というのは実は初めてだったりしますのでいろいろ勉強しながら進めています。DMZ領域を作りたいのでルータマシンに３つのNICを指しているのですが、2つのファイアウォールで挟んでDMZ領域を作るというのがいいらしいですね。

それにしても、今まで分からなかったこと（正直、ネットワーク（運用方面）は未タッチだったのです。サーバアプリは作れるのですが、ネットワーク管理・運用は単体サーバでしかやったことがなかったです）が見えるというのはいいもんです。またいろいろ情報を確認できたら、まとめておくことにします。

HDRIとIBL（2004/10/25）

似たような単語が並んでしまいますが・・・技術情報は、また落ち着いたときにきっちり（日記でなくて）まとめておきますね。

さて、言葉は知っていてもアルゴリズムはあまり掘っていなかったHDRI/IBLについてです。

HDRI（High Dynamic Range Images）とは「1ピクセルの表現幅が広い画像」みたいな直訳になり、広義の意味で言うと「画像データ」を表します。一般の画像フォーマットがRGB(A)で各8ビットで表すのに対して、「指数」を追加してRGBE（Eが指数部）で１ピクセルを表現します。これにより、0.0〜1.0以上の値をそれぞれのRGB成分に持たせることができます。ファイル拡張子としては、代表的なものとしては「hdr」が使われるようです。

以下にサンプル画像があります。

http://www.debevec.org/Probes/

で、この画像ファイルは何に使うのかというと、光として扱うことになります。ピクセル色が1.0以上の値、ということは、シーン上にテクスチャとして貼り付けた場合はそれが「発光（放射）」といった状態を表して、他の物体にも光を提供することになります。このように、光（光源）としてテクスチャを扱うことを「IBL（Image Based Lighting）」と言います。よく使われる方法としては、スカイライトとしてHDRIテクスチャを天球（シーン全体を囲む球体）へ貼り付け、レイが空の彼方に飛んでいくときにそこ（環境マップのようにレイの方向ベクトルをテクスチャ上の2D位置に変換します）から交差位置でのRGB要素を見て、そのテクスチャ位置での色情報を光の輝度とします。「目からレイトレース」して、何もない空間に拡散したときに天空の輝度を最終的なピクセル色に光の要素として加える、というのがミソです。

なんてことはない、「1.0を超える値を持ったテクスチャ（HDRI）」と「環境マップ」といった感じです。理論としては難しく考えることはないようですね。昨今のGI画像でIBLがよく使われるのが分かるように、リアリティを求めるには効果絶大です（ということは、自然空間ってさまざまな光が四方八方から入り込んできているんだなぁ、と）。

ですが、「目からレイトレース」といった場合（普通の直接照明だけのレイトレースやパストレース）では、たしかにレイが飛んでいった先で天球との交点を考えるといい、と理解しやすいです。しかし、実際は「天球すべてが面光源」みたいな状態ですので（パストレースではそれこそ自然に表現できますが）フォトンマップでは実装が難しそうです。単純に考えると、一次レイを飛ばした後にその交点位置から（法線を中心軸にした）半球上に複数のレイを飛ばして（影計算を含める）交差判定を行う必要があります。パストレは自然に実装できるのは分かりますね。では、フォトンマップでは？

私の考えつく方法では、天球からあらかじめ特定の位置をサンプリングしておいて（HDRの画像より光の強さを求めておく）そこからフォトンを飛ばす、といった感じでしょうか。視点からまじめに追跡するとなると、それこそパストレース（モンテカルロ）そのものですし。何せ、パストレース特有のスカイライトのみのシーンは、柔らかい感じが好きですので実装したいところですね（さらに、高周波ノイズは出さないようにして）。

PBR本とRRT本（2004/10/25）

アマゾンから届きました。

お、重い・・・。

「Physically Based Rendering」「Realistic Ray Tracing」の技術書（洋書）２冊です。RRT本は、ソースもついていてわかりやすいです（屈折反射の式、やはりJensen氏の本（日本語版）では誤植だったんすね）。PBR本は、いろいろ網羅していて読み応えがありそうですね。

速度（2004/10/23）

ちなみに、下の画像は320x240 pixel、１ピクセルのサンプリング数 3、グローバルフォトン数 40000、コースティクスフォトン数 40000、輝度推定の半径17.0、集めるフォトン数1500で、レンダリング速度は6.6秒くらいです（空間情報はファイルに一度出して、独自キャッシュ経由でメモリに展開。なので、大容量にも対応しています）。

テストマシンは、Athlon 1.1GHz/Mem 512MBのWindows 2000です。

まだイラディアンスキャッシュとかSSE対応とか、最適化もろもろを加えてないので、最終的に3秒くらいになればいいなぁ。ですが、最適化するにあたって「ファイナルギャザリング」の負荷がクローズアップされそうですね（交差判定やトラバースよりも）。

続・Schlickモデル（2004/10/23）

GIに対応してみました。光沢反射の間接照明は面倒なので、独自のやり方でやってます。ようは、完全な鏡面反射が微小な凹凸でぶれたやつと見ることができるのでブラしているだけです(^_^;;。

床に間接的に赤色と青色が漏れているのが分かります。その他、マテリアルに「粗さ」・「光沢」・「等方性」のパラメータを追加。これで一応はそれらしいかな。

コースティクスの表現にて「光沢」も反射要素として入れてみたのですが、拡散しすぎるためにこれはコースティクスでは考慮しないことにしました。フォトンマップ本にもたしかそんなことが書いていた気がしたのですが、「あ、これのことか」ってのが分かりました。

別途、仕事場のサーバ設定をしているのですが、FedoraCore2がインストールすらできない(T_T)。CD入れてマシン起動後にしばらくしたら止まるので、どうも対処できないでいます。今度、RedHat9での確認と周辺機器のドライバあたりをチェックするかな。サーバ設定はなかなか思い通りにいかないことが多くて、やきもきしてしまいます。

参考になりそうなレンダラ（2004/10/21）

レンダラの疑問点などがあったら（また数式で意味が分からないのがあったら）先人の知恵をお借りする、ということで。

R.I.S.E.（C++のGIレンダラ。VC++/XCode/gccなどいろいろ）
http://rise.sourceforge.net/cgi-bin/makepage.cgi?Home

Picaso(VC++6.0で作成されたGIレンダラ)
http://mathias.payan.free.fr/RayTracer.php

Sunflow（Javaで作成されたGIレンダラ）
http://sunflow.sourceforge.net/

それぞれソースを公開されております。Schlickでのフォトントレース時の光沢反射のベクトルを求める方法が分からないため、追ってみようかと思ってます。（PicasoではSchlickのシェーディングをしていてもBlinnの反射を行っていたため、粗さに対するフォトンの光沢反射をサポートしていませんでした）

Schlickモデル（2004/10/21）

Schlickのシェーディングモデルをようやく理解・実装しました。パラメータがたくさんありますので（といっても直感的に理解しやすいです）まとめておきます。

まず、Phongシェーディングとかとは別のパラメータという理解が必要になります。

輝度計算の要素としては「拡散反射(d) + 光沢(g) + 鏡面反射(s)」の３つに分かれています。Phongではスペキュラとして光沢をあらわしていたのですが、Schlickの場合は「光沢（Glossy）」と「鏡面反射（specular）」に分かれています。これは、「光沢」というのは厳密な正反射ではなくて光の反射が局所的に散らばる表現（つまりは「粗い鏡面反射」ですね）、「鏡面反射」は光の完全な正反射を表す、と分けたものと考えることができそうです。

また、「垂直入射したときの鏡面反射色（フレネル項）」「粗さの要素」「等方性の要素」が別途必要です。この6つのパラメータを主に使用してマテリアルの質を調整します。ほか、物体色・光源色などはPhongシェーディングと同じです。

以下は、粗さの要素を0.1/等方性の要素を0.2にしたもの。「d = 0.8/g = 1.0/ s = 1.0」としています。

この「粗さ」というのは、物体表面が凸凹になっているかというのを示すパラメータです。鏡面までを設定（完全な鏡面反射〜非常に粗い材質）できます。これが、Phongで言うスペキュラ（鏡面反射）成分に近いです（イコールではないです）。光沢の強さを指定するのではなくて（＜Phongの場合はそうですが）、表面の粗さを指定する、という頭の切り替えがいります。

「等方性」というのは、いわゆる均等に拡散する材質となります。この逆が「異方性」になります。この異方性〜等方性までを指定するパラメータがあります。異方性反射と呼ばれるものは、表面の微小な凸凹によって「キズ」がついている状態をシミュレートしたようなものです。キズに対して垂直な方向に光沢が伸びます。上図の場合は、スクリーンの左上から右下にかけてのベクトルによりキズを指定しました。それの垂直な方向（左下から右上）に光沢が伸びているのが分かりますでしょうか。また、キズ方向を示す方向ベクトルのパラメータもいりますね。

順番が変わりましたが「フレネル項」は、視点位置によって光の光沢の見え具合が変わる、といったものを調整するパラメータです。たとえばガラスコップのエッジ部分は白く光沢して見える、というアレですね。

試しに、粗さ = 1.0 / 等方性 = 1.0にしてみました。

これは、光沢が消えた（＝表面が凸凹している）という状態です。

粗さ = 0.5 / 等方性 = 1.0にしてみました。

ちょっと光沢が出ましたね。

粗さ = 0.1 / 等方性 = 1.0にしてみました。

かなり光沢が出ました。また、「等方性 = 1.0」なので、異方性の性質は出ていないことが分かります。

と、「拡散反射(d) + 光沢(g) + 鏡面反射(s)」は固定にしていますが、そのままでもいろいろバリエーションは出せます。さらに金属質の場合はdを小さくしてgとsを調整、などで詰めていくことができそうです。

ただ、Schlick氏の論文を見る限りは「d + g + s = 1.0」になってます。また、このパラメータは自動調節するように論じられていたのですが、なかなかうまいこと望みの材質が出ないためにパラメータとして指定できるようにしたほうがいいかなぁと思ってます（しかし、フォトンで間接照明も考慮するときには、このあたりの制限は守らないといけないかもしれないですね）。

以上は、直接照明のみの実験ですがPhongシェーディングに比べて「粗さ」「等方性」のパラメータの追加で、表現の幅は広がりそうですね。

マテリアルのパラメータをSchlickのものだけに切り替えようかなぁ。

Diracのデルタ関数（2004/10/18）

Schlickの式にてBRDFの完全な鏡面反射を表すところで「Diracのデルタ関数」というのが出てきます。「δ(x-y)」であらわされる式です。超関数と呼ばれるものだそうで、詳しくはググってみてください。（私は実はよく理解してないです）

が、Schlickの式の鏡面反射を表すBRDFは以下のように表記されています。

「x」が調査する交点、「w'」が交点xから光源に向かう「逆光線ベクトル（Lvとする）」、「w」が交点xから視点に向かう「逆視線ベクトル(Evとする）」、「Ps」が鏡面反射の計算された成分値とします。Ev/Lv共に正規化されているとします。

「Fr,s」はBRDFの鏡面反射値です。これを求めます。問題は「δ(x - y)」の解です。フォトンマップ本では「δ(x)はx = 0のときだけ0ではない」これをヒントにプログラム化してみます。

Frs = 0.0f;

double s1, s2;
double theta = atan2(Lv.y, Lv.x);
double phi   = acos(Lv.z);

double theta2 = atan2(Ev.y, Ev.x);
double phi2   = acos(Ev.z);

s1 = sin(theta);
s2 = sin(theta2);

if(fabs(s1 * s1 - s2 * s2) < (1e-6) &&
     fabs(fabs(phi - phi2) - PI) < (1e-6)) {
          Frs = Ps * 2;
}

つまり、これを見る限りは「δ(x - y)」であらわされるときに、「x ≒ y」のときは値が入り、その他は0になるといった感じでしょうか（式に対し、if条件文がついたもの？）。海外サイトでプログラムと見比べてみて、ようやくSchlickモデルのBRDFを実装できました。

フォトンの見直し（2004/10/17）

今一度フォトンマップを見直してみました。やはり間違っていたようです(^_^;;。フォトンを飛ばしたときに「拡散面とぶつかったときにフォトンを格納」ってのを数回跳ね返った先で吸収される段階でのみ格納してました。よく文章読むべきでしたね。

で、とりあえず、フォトンマッピングのみでGIしたときの結果です。

3万フォトン/放射輝度推定の半径17.0/放射輝度推定の集めるフォトン数1500

拡散反射に関してはこれで正解っぽいけど、影と屈折がちょっと自信ないです。Cornell boxみたいなので厳密にいかないといけませんね。（たしか、どこかにそのまま数値化されたデータがあったはず）

SONATA ARCTICA（2004/10/17）

ひさびさにHR/HM（いわゆるヘヴィメタル）のアルバムを購入。「SONATA ARCTICA」の「RECKONING NIGHT」です。イントロ部分が、日本ファルコムのYs6のオープニング曲っぽい雰囲気のがありますねぇ(^_^;;。「Don't Say A Word」の出だしとか。昔はストーリーを持った重厚な感じのも好きだったのですが（Blind GuardianとかRhapsodyとか）、最近はライトなのに傾いてきてます。（Rhapsodyも新アルバム出ていたのですが、最近は買ってないですねぇ。Blind Guardianは、なんだかんだで全アルバムを聴きましたが最近は出してないみたいですし）

アルバム「RECKONING NIGHT」では、なんとなくですがBlind Guardianっぽい感じの曲もありました。個人的にはアタリです。

さて、レンダラですがどうもスペキュラを考慮してないかなぁということで、直接照明にスペキュラを加えてみました（あいかわらずPhong-Blinnですが。Schlickは「Diracのデルタ関数」というのがなんのことやらさっぱり分かってないので、もっと試行錯誤が必要です(^_^;;。とりあえず、スペキュラ成分はBlinnで確認してみようかなぁ）。

間接照明（フォトンの計算）でも、もしかしたらスペキュラ成分の追加（というよりも表面材質による反射の調整）がいるかもしれませんので、調整してみようかと。フォトンマップ本の９章っすね。

間接照明（2004/10/16）

GIレンダラを調整中ですが、なかなか間接照明が思い通りにいかないです(^_^;;。たぶん根本から間違っている部分があるのだと思いますが・・・（リファレンスとして、Jensen氏のフォトンマップ本のシーンを真似ています）

フォトンの低周波ノイズを軽減するために、直接照明と間接照明・コースティクスを分けて管理しました。

以下、間接照明+コースティクスです。

以下はすべて合わせたもの。

フォトン数30000、放射輝度推定の半径20.0、集めるフォトン数500です。

天井への間接照明が明らかに薄い・・・と、面光源の影のノイズが気になりますね（影フォトンで解決するのが妥当なんでしょうか）。

微調整のために、１つフォトン用のパラメータ（フォトンの放射輝度を強くするためのもの）を増やしたのですがこれも正しいかは不明です。

もうちょっときちんと理解したい部分がありましたので、洋書「Physically Based Rendering」「Realistic Ray Tracing」をアマゾンで注文しました。来るのが楽しみです。

スムージング角度（2004/10/12）

しばらく放置していたスムージング角度について、もう一度見直しました。以前までは、「面法線」「頂点法線」を作ってこれを元にスムージングをしていたのですが、急な角度を持つ面同士ではうまいこといかないです。

たとえば、円柱の底辺と側面の境目や円錐の底辺の境目など。

これは教えていただいた方法ですが、「面法線」をまず求めておき、個々の面同士の角度（cos：つまり法線での内積）を求めていきます。これがスムージング角度の指定よりも小さい（値としてはcosの比較なので「２つの法線の内積 >= cos(PI * スムージング角度 / 180.0)」）場合は、そのときの「ポリゴンの各頂点別に」法線を加算していきます。そして、すべての判定が終わった段階で「ポリゴンの頂点ごとの法線」を正規化します。

これだと、後々レイトレーシング後の交点での法線と面法線の角度を求める、といった処理も不要になり、急な角度をつくる面の表現もうまくいきました。

頂点法線（共有する頂点での法線を加算）を求めるって処理、実はいらなかったんですね。その代わり、「ポリゴン数 x ポリゴン内の頂点数」のバッファが必要になりますがこれだとリアルタイムでも問題なさそうです。

また、前処理計算の負荷ですが（これを一番危惧してました）、角度を求める内積で大部分は刈ることになるため、気にするほどの低下にはなりませんでした。また、Wiki内の記事「面法線と頂点法線」は更新しておきますね。

品川区民公園（2004/10/11）

もうすでに板についてしまった携帯写真ですが、今回は「品川区民公園」です。公園内に「しながわ水族館」があります。ただ、しながわ水族館には入ってません。さすがに撮るとまずいでしょうし（その前に携帯のカメラでは暗がりは撮れんです(^_^;;）。

http://ft-lab.ne.jp/photo/shinagawa.html

ここも家から歩いていける距離なんですが（と言っても４駅分は軽く歩いてます・・・）、自然が多くて風情があります。特に水族館の手前の池が「庭園」って感じでよいです。

木々が少ししか紅葉してなかったですが、秋の気配は感じました。

Soft-City（2004/10/09）

レトロゲームのダウンロード販売をやっている「Soft-City」に登録してみました。昔懐かしのPC-88/PC-98/FM-77AVなどでのゲームをエミュレートしています。ファミコン世代は、やっぱしこの手のレトロゲーに惹かれてしまいますわ。

ということで「琥珀色の遺言（FM-77AV版）」をダウンロード（またかよ、って感じですが(^_^;;）。Win95版を持っているのですが、Win2000/XPでまともに動かないしひさびさに雰囲気を楽しみたいなぁということで購入です。ちなみにX68K版も過去にプレイ済みです。これの携帯版もあるみたいですね。

で、「琥珀色の遺言」は大正浪漫漂う推理ものの硬派アドベンチャーゲームです。金田一耕助とかあんな雰囲気。リバーヒルソフトの藤堂龍之介シリーズは他「黄金の羅針盤」がありますが、雰囲気は同じように大正時代ものです（これもPC98版をプレイ済み）。これのタイトル曲ですが、マスネ作曲の「エレジー」というクラシック曲だそうです。（「黄金の羅針盤」では、スメタナ作曲のモルダウですね）いやぁ、懐古モード全開っす。

BRDF（2004/10/08）

BRDF（bidirectional reflectance distribution function）とは「双方向反射率分布関数」と呼ばれるもので、光の反射具合を表す式です。といっても難しく考えることはなくて、たとえばスタンダードな「フォンシェーディング（正確にはBlinn-Phongシェーディング）」の数式において、

col = (Ka + Kd (L・N) + Ks (H・N)^α) * LightColor

みたいに計算します。これからBRDF成分を抜き出してみます。

「Kd」は拡散反射係数、「Ks」は鏡面反射係数、「Ka」は環境光係数、「N」は交点での法線ベクトル、「L」は逆光線ベクトル、「H」は逆視線ベクトルと逆光線ベクトルで作られるハーフベクトル、「α」は鏡面反射の強さ、「LightColor」は光源色です。

物体の色については、拡散反射係数に含まれます（まとめて「拡散反射色」としてます。色の正体は「光の強さ」ですからね）。

この式を

Lr(x, V) = ∫ Fr(s, L, V) Li(s, L) (L・N) dV

みたいに分けてやります。このときの「Fr(s, L, V)」がBRDFの式、「Li(s, L)」が光源色（上記で言うLightColor）になります。ところで、フォンシェーディングの式は「環境成分 + 拡散反射成分 + 鏡面反射成分」に分解できます。

つまり、フォンシェーディングでのBRDFは以下のようになりますね。

環境成分     = Ka / (L・N)
拡散反射成分 = Kd
鏡面反射成分 = (Ks (H・N)^α) / (L・N)

Fr(s, L, V) = Ka / (L・N) + Kd + (Ks (H・N)^α) / (L・N)

ただ、見て分かるとおり拡散反射成分が定数(Kd)になってしまってます。これは、表面がざらついていないということでもあります。実際の現実世界の物体で「ざらつき」のない物体はありません。微小な凸凹があるはずです。これが、フォンシェーディングの限界になるわけでもあり、これを解決するための他のシェーディングモデルがいろいろあります。

と、前フリはここまでで(^_^;;。BRDFとシェーディングモデルについての割と分かりやすい論文を見つけました。

http://www.code3d.com/papers/brdf.pdf

ただ、ドイツ語っぽいんでソウルで読解してください(^_^;;。数式と画像が多いですので理解はしやすいかと(私は当然読めないですが、なんとなく理解しやすかったです。「フォトンマッピング〜実写に迫るコンピュータグラフィックス」の書籍は、このあたりが軽くてちょっと理解できなかった部分がありましたので)。BRDFについての説明と、Lambert/Phong/Cook-Torrance/Ward/Schlick/Lafortuneのそれぞれのモデルについての考察があります。

実は私のレンダラはPhongモデル使ってるのですが、異方性反射と表面の粗さを要素に加えたかったために、Schlickについてあさってました。上記論文で「なるほど」と理解できました（論文では「式75」の「A(w)」の計算が間違っているので注意）。

Schlickの論文については1994年の「An Inexpensive BRDF Model for Physically-Based Rendering」が参考になります（ググってみてください）。

これらのシェーディングモデル（というよりもBRDFの算出）は、実験と観察に基づくもののようですが、近似ってすばらしいですね。BRDF自身はBSSRDFの近似ですので「物理モデルに基づく」だと、もっと複雑になるんでしょうねぇ。

と、さも分かったように書いてますが、BRDFは未だ勉強中でようやく「見えてきた」感じだったりします(^_^;;。いやはや、奥が深いです。

空間分割の最適化（2004/10/06）

ひさびさに技術的な話題を。レンダラにて無駄な処理をしていた（というより、刈る処理を省いていた）ため、とある条件判定を入れることで、レンダリング速度が３倍速くらいになりました。こりゃよっぽど効果が高いなと判明しましたので、もし考慮されていない方はぜひ。

UGでもHUGでもOctreeでもBSPでも、空間分割時には最終的には「ボクセル内にポリゴンを納める」という状態が発生します。ここで、単純に三角形の頂点座標の最小値・最大値を求めて内包判定していました。しかし、ここで「ボクセル（直方体）と三角形ポリゴンの詳細な交差・内包判定」を行ってやります。実に時間の無駄のように思えますが、これが結構効いているみたい。この処理自身も、多角形同士の交差判定ではないため（ボクセル自身はXYZ軸に平行であるため）最適化を行うことができます。

後は、こちらのレンダラではすべての空間分割情報をファイルに書き出してメモリはキャッシュとしているのですが、これを最適化することによりほぼファイルI/Oのボトルネックは解消しました。

ということで、どうにか大規模データの対応と空間分割の最適化は理論として固まってきた感じです。理論上、1兆単位のポリゴン数を持つシーンでも処理可能なんですが、いかんせん、対応できるHDDがないですわな。64ビットCPU（64ビット対応OS）は、実は64ビット幅のアドレス空間でないみたいなのでこのあたりのネイティブ64ビット対応ができる日はいつになるのでしょうねぇ。ただ、別に64ビットでなくてもそれなりのポリゴン（32ビットを超える）は処理できますのでまだ静観しておこうと思います。＜64ビット環境

あ、地震がありましたね。うちのアパートが全壊すると（なんかモロそう(T_T)）大変なんで、バックアップは別のところに置いておきたいもんですねぇ。

懐中しるこ（2004/10/05）

そろそろ寒くなってきました。スーパーで「文明堂の懐中しるこ」を発見しました。秋から冬にかけて置かれるのかな、出会いは約1年ぶりくらいです。

上記画像、携帯の「接写モード」で撮ってみました。これくらいの解像度なら私としては十分です。が、いろいろ弱点も見えてきてますのでデジカメもほしいとこですね。

添付ファイルが消えてもた（汗）（2004/10/04）

Wikiのバージョンアップをしていたら添付ファイルを消してしまいました（T_T）。また復旧しておきます。

・・・といってもバックアップとってないので、地道に手作業します・・バックアップはとるべきですね(^_^;;。

まったりやる予定が（2004/10/03）

結局、AIRクリアしてしまいました(^_^;;。物語が加速しだしたら途中でやめれないですねぇ。アドベンチャーゲームはゆっくりとはできんですわ。でも感動しました。たしかに泣けましたね。「恋愛AVG」ってジャンルではありますが、そんなコテコテな感じでもなかったですし（それがよかったわけですが）。

よく考えると、TVのトレンディードラマはたいていは恋愛ものではありますね。そんなのと比べてみても、よくできたストーリーだなぁと思いました（というよりも、最近のトレンディードラマはつまらんです(^_^;;。ストーリーが単調というかありきたりというか）。でも・・・AIRはなんか世界観として引きずるもんがありますなぁ(^_^;;。後に残るっていうか。それが人気を呼んでいるのかもしれませんね。人によっては依存するかもねぇ。

理（ことわり）さんの「理の音楽倉庫」にて、「鳥の詩」のオーケストラアレンジのMIDIがあります。「AIRRPG」という同人のエンディング曲のようですが、壮大な展開で良いです。こっちも聞いてみて感動しました。

最近の動向（2004/10/02）

最近は、表向きは携帯いじってたりAIR（ゲーム）やったりで、ぜんぜんレンダラが停滞しているように見えますが、水面下で進んでおります。ただ、あまり表に出すようなことでもないのでネタにしてなかっただけだったりします(^_^;;。実は、レンダラ自身は今まとめに入っている時期です。いろいろ考えたのですが、やはり光の動きからすると「フォトンマッピング」の考え方が（今のところ）しっくり来るような気がしてます。ただし、絵的には劣化する・調整が難しいのはたしかではありますが。高速化する場合はパラメータも増えますので、これが一番のネックですねぇ。絵を作るためにレンダラの仕組みを理解しないといけない、というのは打破したいところではありますが・・・。現段階ではいい案が浮かびませんでした。やはりというか（私自身遠回りしてますが）先人の知恵は偉大だなぁと思います。

今蓄えている携帯カメラ画像は、後で素材の形で生かせるかもしれない（そのままじゃなくて、たとえばCG化して（2D背景絵でも3DCGでも）ゲームでの下絵にするとか）、という想いもあります。まぁ、それ以前に公園めぐりとカメラで撮るのが楽しいわけですが(^_^;;。ゲーム（特にAVG）や映画ムービーを見ていると、「あ、これは何か元ネタの写真があるな」というのはなんとなく分かりますね。これを想像で創造できるのならすごいだろうなぁ。実際のデザイナさんはどうしてるんでしょ。

AIRネタですが、2005年に劇場版が公開されるみたいですね。まだゲームのほうはコンプリートしてないですが（脇役キャラ（？）ではクリアしました）、思ったよりも感動しました(^_^;;。下手なドラマよりもいいかもしれんです。パッケージやゲーム開始段階の軽い（かつ単調な）雰囲気が、どんどん深い方向に重い方向に進むって展開、好きだなぁ。ストーリーがよさげなのでゲームでの展開を引き継ぐのなら、劇場版は期待できるかもしれませんね。

目黒自然教育園（2004/10/02）

携帯カメラ写真第三弾として目黒の自然教育園に行ってきました。実は、ここも家から歩いていける距離にあるんです。場所が目黒の白金台、ということでどんだけセレブな庭園かと思ってたんですが、これは庭園というよりも「森」そのものですねぇ。自然そのまま、といいった感じです。蚊が多いですので虫刺されの薬を用意しておいてもいいかも。停止して携帯カメラを構えると蚊が寄ってきましたので、痒くてたまらなかったです(^_^;;。

「教育園」という名のとおり、植物や昆虫についてのプレートがそこらにありますので、また時期によっては職員の方が案内してくれるイベントがあるらしいので、家族連れで行くといいかもしれません。入園料がいりますが大人210円・子供60円と安いです。

ここって、実際の道でいけないところに結構森が広がっているんですね（当然、道以外を進むことはできないです。倒木などがありますので危険）。都会でもこんな森があるんだ、ってことで新鮮でした。

それにしても、公園・庭園探しは楽しいですなぁ。趣味の１つになりそうです(^_^;;。