Syoyo Fujita's Blog

raytracing monte carlo

Month: January, 2006

サーバ更新

この開発日記や wiki などを立てている、自前のサーバをアップデートしました。
いままでは非常に非力なサーバだったため、movabletype で投稿しようものなら 3 分ほど待たされたり、
mediawiki も trac もまともな速度で動きませんでした。
その問題も今回のサーバアップデートによりこれからはなくなりそうです。

また、これを機に blog ソフトを、もう movable type で苦労したくなかったので、
ますおさんも使っておられる WordPress に変えました。
海外では movable type よりもシェアがあるようですね。
movable type からの移行は、今回は特に問題なく移行できました。

しばらく落ち着いて安定した稼動を確認したら、trac などを入れてみようと思います。

Advertisements

デイライトを HDR に書き出す機能を追加(Added the function which exports the sunsky simulation result to a .hdr image.)

デイライトシミュレーションの結果を .hdr に書き出す機能を付け加えました(revision 156)。

http://lucille.atso-net.jp/svn/angelina/sunsky/

angular map 形式で書き出しています。
(半球上、つまり地平線より上の部分しか計算されないので、下側は真っ黒になります)
このようにしておけば、他の HDRI 対応のレンダラとかに読み込ませて HDR ライティング(環境ライティング)
に使うことができるので、lucille との比較にも使えます。
(太陽そのものの光源は含んでいません)

実際に lucille に組み込んで使うときにも、内部で前計算によりテクスチャに展開しておき、
環境マップライティングをする、というアプローチになるので、そのテストも兼ねています。

まだ生成されたマップを HDR ライティングとしてレンダリングして試していないので、
ちょっと間違っているかも。

しかし、画像だけでも確認しようと結果の .hdr を見ようとしても、ダイナミックレンジが高すぎて、
あまりちゃんと表示できる hdr viewer がありません。
(白飛びしたり、真っ黒になってしまったり)
やはりちゃんとトーンマッパーを実装しないとダメだという必要性を感じました。

ということで、トーンマッパーを実装すんべかな、と web を調べていたら、
wikipedia の解説が結構まとまっていて充実していたのでちょっとびっくり。

http://en.wikipedia.org/wiki/Tone_mapping

しかもそこのリンクにある、 PFStmo というほとんどのトーンマッピングの論文の手法を実装したソースコードも!

PFStmo :: tone mapping operators
http://www.mpii.mpg.de/resources/tmo/

外部から呼び出せるし、これでいいじゃんと思いましたが、
出来れば勉強のためにも、 Ashikhmin あたりの簡単なものを自分で rockenfield に実装しなおそうかと思います。

Spectral rendering + MLT

Elektronik Discussion

http://homepages.paradise.net.nz/nickamy/

Spectral rendering + MLT のコンボ。

やべぇ、もう越されてた。世界って広いわ。

まあでも技術的にやっていることは同じそうなので、
地道に要素技術を実装していけばこういうきちんとした絵が出るという
目標にもなるかな。…精進します。

デイライト実装(An implementation of sunsky model)

A. J. Preetham, Peter Shirley and Brian Smits,
A Practical Analytic Model for Daylight“,
Siggraph 1999, pp. 91-100.
http://www.cs.utah.edu/vissim/papers/sunsky/

を、レンダラ王 shinji さんに感化されたので angelina に実装してみました。

http://lucille.atso-net.jp/svn/angelina/sunsky/

いつもどおり、win32(cygwin), Mac OS X(PowerPC), linux でコンパイルできる、
fltk + OpenGL なアプリです。
Windows 用には、すでにコンパイルされたバイナリ sunsky.exe を置いておきました。

この論文が提案しているデイライトのモデルは、
大気効果の計算をスペクトルで計算しているため
スペクトルレンダリングの手始めにちょうどよかったのと、
テストレンダリングでとりあえずレンダリングするときに、
明示的にライトを生成しなくとも見栄えのする照光環境が
作り出せるので役立ちそうだったからです。

論文のあるリンク先にはソースコード例もありますが、ちょうどスペクトルデータを計算する
ところの部分に関するソースはありません。

http://www.cs.cmu.edu/afs/cs/user/ajw/www/software/

こちらのほうには、スペクトルを計算するコードも補完された実装コードがあります。
(ちなみに、他には、yafray などの実装のようにスペクトルではなく RGB で近似して
求めるようにしているのも見受けられます)

今回は、スペクトルの計算は 380 – 780 nm の間で、
10 nm 間隔(41 サンプル)固定で行っています。

sunlight and skylight

このデイライトのモデルでは、

o 太陽の位置に応じて大気拡散された太陽の色(sunlight)を求める式
o 太陽の位置に応じて空の色の分布(skylight)を計算する式
o 空気遠近感(aerial perspective)を計算する式

の 3 つで成り立っています。
最初の sunlight では、たとえば日が沈むときには太陽が赤くなるようなことがシミュレートされます。
skylight では、空の色の分布をシミュレートします。
aerial perspective では、物体との距離に応じた大気散乱による遠近感効果をシミュレートします。

今回は上の 2 つを実装しました。とりあえずはまず太陽の色と半球上の空の色の分布が
分かればよかったので。

シミュレーションをコントロールするパラメータは、それほど多くありません。

o 観測点の緯度、経度
o 観測点が基準とする子午線(15 度単位。日本だと明石天文台のある 135 度)
o 日時(1 – 365 日)
o 時刻(0 – 24 時)
o 濁度(turbidity) : 低いほど晴れ、高いほど霧や霞の度合いが高くなる

程度になります。

論文には、観測点の緯度経度と時刻から、太陽の位置を計算する式も載っています。

http://www1.kaiho.mlit.go.jp/KOHO/automail/sun_form3.htm
これと、論文にある計算式で求まった太陽位置の出没時刻が合うかどうか調べて見ましたが、
大体合っているようでした。
(というか同じ計算式をもし使っているんだったら、一致しないと自分の実装がおかしいかも…)

さて、計算はスペクトルで計算されるので、これを視覚化するには RGB に変換し、
また skylight の分布はダイナミックレンジも高いのでトーンマップを行う必要があります。

今回は RGB 変換後のトーンマップには、
RGB のうち値が大きいもので RGB それぞれを割るという適当な処理にしました。

色の変化を視覚化して見る分にはこれでよかったのですが、
実際にはちゃんとしたトーンマップを考える必要がありますね。

そのほかの大気シミュレーションの物理モデル

今回実装した論文は、daylight とタイトルに名前がある通り、
主に日中の空の色の表現にフォーカスを置いていますので、
夜の空の色のシミュレーションはできません。
これを補完するものとして、夜のシミュレーションや、
また日の出/日暮れをより正確にシミュレーションしようというモデルもあります。

Henrik Wann Jensen, Fredo Durand, Michael M. Stark, Simon
Premoze, Julie Dorsey and Peter Shirley,
A Physically-Based Night Sky Model“,
Siggraph 2001
http://graphics.stanford.edu/~henrik/papers/nightsky/

Jörg Haber, Marcus Magnor, Hans-Peter Seidel
Physically based Simulation of Twilight
Phenomena
“,
ACM Trans. on Graphics, 2005.
http://www.mpi-inf.mpg.de/departments/irg3/dtd/

ところで、このような物理ベースの手法を使うとなると、単位に非常に気を使います。
今回は初期実装ですので、うまく行っている感じが出ればそれでいいのですが、
レンダラに組み込むときにはうまく単位を合わせてきちんと検証しなければと思います。

参考文献

http://www.asahi-net.or.jp/~cg1y-aytk/ao/index.html
http://www.weather-photography.com/gallery.php?cat=optics
どちらも各種大気現象の写真を見ることができます。

The Halfway Vector Disk for BRDF Modeling

Dave Edwards, Slolmon Boulos, Jared Johnson, Peter Shirley,
Michael Ashikhmin, Michael Stark, and Chris Wyman,
The Halfway Vector Disk for BRDF Modeling,
ACM Transaction on Graphics, vol 25(1), 2006.
http://www.acm.org/tog/

新しい経験的 BRDF(emprical BRDF. 解析的な式で表せる BRDF) の提案です。

特徴は、

o エネルギー保存則に従う
o インポータンスサンプリングが可能
o ディフューズ、スペキュラー、レトロ反射を統一して扱える
o 計測 BRDF のデータフィッティングにも使える(この場合エネルギー保存則は必ずしも成り立たない)

です。

コンピュータグラフィックスで使われる BRDF は、大きく分けて 2 つあります。

o 経験的 BRDF(Emprical BRDF or Analytic BRDF)
o 計測 BRDF(Measured BRDF)

です。経験的は BRDF は、材質の反射率を実験などして測定し、その分布が、
「なんかこの関数とパラメータの組み合わせを使うとうまく分布に当てはまるっぽい」という
経験則(もちろん数学的裏づけも必要ですが)で導出された、解析的な式で表されたものです。

経験的 BRDF には、有名なフォン反射(フォン BRDF)や Ashikhmin BRDF などがあげられます。
ほとんどの場合、 CG では解析式で表すことができるこの経験的 BRDF が使われます。

対して、計測 BRDF では、まんま計測器で材質を計測したデータをそのまま使います。
本当にリアルで物理的に正確な物質の反射を扱いたいときに使いますが、
データ量が膨大になったり、材質毎に計測データが必要になるので、研究用以外では
あまり使われていないと思います(商用 レンダラでサポートしているのってあるのかな?)。

さて、経験的 BRDF ですが、ここ最近では Ashikhmin BRDF

Ashikhmin, M., Shirley, P.
An Anisotropic Phong BRDF Model,
Journal of Graphics Tools,  v.5, no. 2 (2000), pp.
25-32
http://www.cs.sunysb.edu/~ash/

の提案以降は特に新しい BRDF の提案モデルはありませんでした。

今回提案された Halfway vector disk を使う BRDF モデルは、
特に、モンテカルロレンダリングを行うときに重要である、
エネルギー保存かつ効率的にインポータンスサンプル可能な汎用目的の
BRDF モデルとなっています。
(論文によればこの二つを満たす BRDF モデルはこれが初めてとのことです。
Ashikhmin BRDF はインポータンスサンプルもできてなかったっけ?と思いましたが、
読み返してみると half vector と diffuse term のみできるということだったみたいです)

また、この提案手法を計測データの当てはめに使っても、
よいフィッティング結果が出るとのこと(ただしエネルギー保存則は成り立たなくなる)。

提案されている BRDF モデルの式は論文に掲載されていますので、
既存のレンダラに組み込むのは容易であると思います。

Coins: 並列化コンパイラ向け共通インフラストラクチャ

http://www.coins-project.org/

こんなシュゴーなコンパイラプロジェクトがあったのですね。
知りませんでした。
SIMD 化などの各種最適化や、OpenMP
化などの並列化など機能もすごいことながら、
プロジェクトメンバーもすごいです。

lucille をこれでコンパイルしたら自動でスレッド化、SIMD
化されて
パフォーマンスがあがりそう。時間をみて試してみたいと思います。

SIMD 化では今のところ x86 SSE
のコード出力のみが行えるようです。

gcc も 4.2 でついに OpenMP 対応(4.1
でプレビュー対応)するようです。


http://www.atmarkit.co.jp/ad/itanium/DDJ0512.html

自分でスレッド化しなくても、フリーのコンパイラでも勝手にスレッド化、
SIMD 化
してくれるようになってきているのですね。コンパイラの進化ってすごいなぁ。

Symposium on Interactive 3D Graphics and Games 2006


Symposium on Interactive 3D
Graphics and Games
2006
 の採択論文が公開されたようです。

Paper pdf links by Ke-Sen
Huang.

http://myweb.hinet.net/home7/hks/Papers2006/i3d2006Papers.htm

I3D は基本的にリアルタイム系ですが、
脱リアルタイムなレンダリングにも
通じるテクニックもあると思いますので、
面白そうなものがあれば紹介していきたいと思います。

まだ詳細には読んでいませんが、

Variance Shadow Maps
(デプス値ではなく、デプスの分散を保持することで、
シャドウ境界をきれいに表現するシャドウマップ法).

Abstract Shade Trees.
(アーティストがシェーダ言語をいじらずともより直感的にシェーダを作れるらしい)

View-Dependent Precomputed Light
Transport Using Nonlinear Guassian
Function Approximations.
(wavelet や SH ではなく、ガウス関数を用いる
all-frequency lighting。
係数データも少なくてすむらしい)

あたりが興味深そうです。

そろそろ 2006 年の CG
学会の採択論文がぞくぞくと公開され始めてきます。

今年も相変わらず年間 1,000
論文程度の読破を目標としていきたいと思います。
冬場は最低ノルマの一日 1 編、(学会で盛り上がる?)夏場は一日 10
編、というほどの振り分けで。
(いうかこれくらいのペースで消化しても年間に発表されるグラフィックスおよび
それらに関連する研究の論文はそれよりも多いので、
常に毎年未読の論文数が
たまってしまっていってしまうのですけどね… ライフワークにはもってこいでしょうか?) 

もちろん全部精細に読みこなす必要はなくて、どんなことが書いてあるか、

利点や欠点は何か? だけだいたい覚えておいて、
後で詳細な理解が必要と判断したときに
再度引っ張りだしてきてじっくりと読むようにしています。

スペクトルフォーマット(Spectrum Data format proposal)

何気にスペクトルフォーマット形式でデファクトスタンダードのものってなさそうだなぁと
思い、
オープンなスペクトルデータフォーマットを提案するのもよいではないかと思っています。

HDR フォーマットもそうですが、
実際にスペクトルを保存するとしたところで、中身は技術的
にたいしたものではないはずです
(HDR はピクセルデータを浮動小数点にたものだし、
スペクトルなら各波長のデータを保持したものですし)。

よって、
ここで日本発のデファクトスタンダードを確立しておくのもよいと思うのです。

まずはフォーマットの名称を考えてみました。

その名も OpenSPW(Open Spectrum and
Wavelength data format)。拡張子は .spw。

OpenSPW を制定する組織は SPW Foundation
になることでしょう。



やべぇ、もう SPW 以外に思い浮かばねぇ。

マクスウェル方程式(maxwell equation)

maxwellrender
が(順調に?)リリース延期のところを見ると、
今が追い越せ追いつけのチャンスだと思い、
スペクトルレンダリングについて
調査を進めています。

そもそもマクスウェル方程式ってそもそもなんじゃらほい?
ということで、
電磁気学(少なくともマクスウェルの方程式の意味)
を勉強する必要を感じました。

手元には、 Max Born の「光学の原理」

http://www.amazon.co.jp/exec/obidos/ASIN/4486016785

という、たぶん光学ではバイブルであろう
書籍があり、
これにもまず最初にマクスウェル方程式について記載されています。

しかし、いきなり電場 E が… rot が…
というくだりで天下り的に記述されていて
正直参考になりませんでした。

いろいろ探してみたところ、
下記が入門として参考になると思い購入してみました。

竹内 淳
高校数学でわかるマクスウェル方程式―電磁気を学びたい人、
学びはじめた人へ
ブルーバックス

http://www.amazon.co.jp/exec/obidos/ASIN/4062573830

かなりわかりやすく解説されていると思います。
読んでいて、そういえば電気、磁気は高校時代の物理でもやったなぁー、

と思い出し、もっとマジメにやっておけばよかったと反省してしまいました。

しかし、これを読んでマクスウェルの方程式を理解したところで、

マクスウェル方程式そのものを解くのは一般的すぎますし、
レンダリングへの利用では、
各種光学現象を表現するために波長や位相の変数を
レイに付加する程度であとは幾何光学の問題として多くは解決できそうですから、

マクスウェル方程式(や電磁気)そのものをレンダリング内部で扱う必要は出てこないであろうと、

今のところ思っています。

光は電磁的な性質を持つ ->
電磁気が満たす条件はマクスウェル方程式で支配される
->
マクスウェル方程式を知っておくべき、
という感じで知識として心に留めておく程度で
十分ではないでしょうか。

ところで、G.I. レンダラの作成ほど、
小中高校までの算数数学、
小中高校までの理科物理で学んだ知識が
そのまま応用できるものは無いのではないかと思います。
小学生のときにやったプリズムやルーペで黒紙を燃やす(Caustics,
火線効果)などの実験
が今役に立とうとは。
やはり小学校の科目はいずれ「国語算数理科 G.I.」になるに違いない。

Lustre

「ハリー・ポッター」シリーズに投入されたLustre

http://www.itmedia.co.jp/enterprise/articles/0601/06/news032.html

レンダーファームにおけるストレージ問題に関する記事です。

SIGGRAPH で出会ったレンダラ野郎たちも、
レンダリング時間もそうですが、膨大なファイル処理も問題であると言っていました。
そのため、なるべくサーバからフェッチするテクスチャデータなどのファイル量/回数を減らし、
レンダリングノードの HDD にキャッシュさせるなどしているとのことです
(しかしこのキャッシュだけでも数百 GB くらい使うらしい…)。

単純にレンダラを作るだけでなくて、これらレンダラとの I/O インターフェイス周りも
考えてレンダラを設計していかないとダメですね。