Syoyo Fujita's Blog

raytracing monte carlo

Month: November, 2006

Discontinuities of dTdx and dTdy in ray differentials.

raydiff_texmap.png
texture mapped polygonal surface(with LOD caclulation by ray differentials).

Blurred texture mapping result shown near the edge is
mainly due to simple mipmap calculation(box filtering).
Choosing proper filter method for mipmap calculation would remove this blurred result. 

raydiff_lod.png
Showing LOD level(LOW: red -> green -> blue -> purple :HI)

raydiff_dtdx.png
Showing dTdx vector(normalized for visualization)

raydiff_dtdy.png
Showing dTdy vector(normalized for visualization)

http://lucille.atso-net.jp/svn/angelina/texturing/mapping/
(source tree)

http://lucille.atso-net.jp/svn/angelina/texturing/mapping/texmap.tar.gz
(source + win32 binary)

I fixed my ray differentials implementation,
but there are discontinuities for dTdx and dTdy vector.
(as a result, LOD has also discontinuities)

I don’t know this is the correct result of ray differentials(of polygonal surface),
but discontinuities in LOD across the polygon surface wouldn’t be preferable.

Does anyone know the source of this discontinuities?

http://lucille.atso-net.jp/phpbb/viewtopic.php?t=25
(Discuss this article)

—- in Japanese —

レイ微分の計算が間違っていたので、修正しました。
しかし、どうも dTdx, dTdx の結果に不連続性があります。
結果として LOD も不連続になってしまっています。
(テクスチャマップの結果を見るとそれほど違いはありませんが、あまり好まれる状況ではありません)

これがポリゴン面に対するレイ微分の正確な結果なのか、
私の実装が間違っているのか…

(ポリゴン面に対する)レイ微分のリファレンスがほしいところです。

mental ray はレイ微分をサポートしていますし、また基本的にポリゴン面を扱うので、
mental ray でレイ微分のテストをしてみたいところですが、、、、
うーん、いまだと 6 万くらいで買える(買い切りだけど) XSI Foundation を買うと、
最も安く mental ray を手に入れられるのかな…

また、そもそもポリゴンの投影面積がスクリーンに占める割合が大きいのも、
微分値を計算する(利用する)上で問題ということで、
Ray Differentials and Multiresolution Geometry Caching ~ のように
レイ微分の結果に応じて適切にジオメトリを分割していくことも必要なのかもしれません。

cgsphere.com

http://www.cgsphere.com/

球体モデルのレンダリングチャレンジ。
提供されるシーンの構図をかえなければ、あとは球体のジオメトリやマテリアル
を自由に変更可能。
球とは、これはまたアツいです。

球体といえば、「回転」ですね。
ぜひとも「鉄」で「回転」している球体(モーションブラー)をレンダリングしてみたいけど、
lucille ではまだモーションブラーを実装していないので「回転」を表現できないのがくやしい…

そういえば、まさかあの球が○○されるとは…
次はいったいどうなるのでしょう?…

test rendering

suzanne_sunsky_thumb.png

lighting: physical sky

lucille も、地道ですが開発を続けています
(完成は 200 年後を見越していましたから、あと 197 年くらいでしょうか)。
最近やった&やっているのはこんな感じです。

o 64-bit 対応(Intel Mac)
o angelina からの physical sky のコード取り込みまで
– VEM(http://www.mpi-inf.mpg.de/resources/hdr/vem/) や RWT, EIHDRI を使ってレンダラ内部でサンプル点を作成するようにしたい
o OpenMPI でビルドできるか確認
o angelina からの BVH のコード取り込み & SSE 化
o 屈折とか座標系関係での間違い発見(未修整)

そろそろ diffuse + IBL なシーンから抜け出して、
本格的に Bidirectioal Path Tracing を実装し、その後 MLT に移ろうかと考えていています。
Lafortune の Ph.D thesis あたりでパストレ理論から復習しているのですが、
Realistic Camera Model を使ったときに、importance(W) の計算や、相対パス密度の計算が
どうしたら(力技以外で)効率良く計算できるかいまいちよくわかりません。
とりあえずはカメラはやるとしても Thin lens model まででしょうかね。

ところで、ERPT ってよくよく調べてみると、Veach が Ph.D. で述べている MLT の効率化
(期待値をストア、stratify のさせかた)以外に特に目新しいものがない気がしてきました。

あと、期待値をストアするという点では、

Using all Metropolis–Hastings proposals to estimate mean values
http://www.math.ntnu.no/~haakont/abstracts/S4-2004.pdf

のような手法も MLT に使えるのかぁと思ったりしています。

NVIDIA CUDA

NVIDIA CUDA
http://developer.nvidia.com/object/cuda.html

これはよいですね。

通常の C 言語でコーディングし、専用のコンパイラでコンパイルすると、
計算を GPU で実行してくれるというもの。

今までは Sh や Brooks などの GPGPU 言語もありましたが、
結局商用化(Sh)や発展なし?(Brooks)で、あまり普及しなかった気がします。

どれくらいのレベルで C のコードを書けるのかは分かりませんが、
現在の SIMD 命令を使うために SSE 関数を使うのと同じくらいの
レベルであれば、非常に使いやすいものになるかと思います。

オフラインレンダラを、たとえば CUDA のコンパイラで再コンパイルするだけとかで、
GPU で計算をアクセラレートすることができるようにできるといいなぁ、と期待しています。

汎用的な処理ができるようにハードウェアが進化してきたことも大きいですが、
それにうまく処理をマッピングすることを実現するコンパイラが出来てきたことも大きいと思います。

最近は AMD + ATI もあり、こちらもそろそろ何かしら出してきそうな気がします。

32-bit and 64-bit performance test

Core 2 duo マシンを使うことができるようになったので、
よい機会なので 32-bit のバイナリと、64-bit のバイナリのパフォーマンステスト
を行ってみました。
また、比較環境として Athlon X2 も測定してみました。
まずは交差判定のテスト。10000 レイと 10000 三角形との SIMD 交差判定テストです。
テストでは 1 つのコアだけを使っています。使用したコードはこちら。

http://lucille.atso-net.jp/svn/angelina/isect/32bit_vs_64bit/

32bit_64bit.png

2.16 GHz Core 2 Duo, Mac OS X, gcc-4.0.1:

o 32-bit
97111703.708308 isects/sec (22.256312 clocks per isect)

o 64-bit
114009485.589201 isects/sec (18.962169 clocks per isect)

2.0 GHz Athlon X2, Linux, gcc 4.1.2:

o 32-bit
57712062.975403 isects/sec (35.040012 clocks per isect)

o 64-bit
62688889.460054 isects/sec (32.166952 clocks per isect)

C2D: 64-bit is 17% faster than 32-bit
X2: 64-bit is 9% faster than 32-bit

Core 2 では 17% の向上、X2 では 9% の向上となりました。
本来であればインストラクション解析も行って正確で fair な解析を
行いたいところですが、 intel にはインストラクションシミュレータが
ありません。なのでとりあえずはこれ以上突っ込んで解析するのはあきらめました。

1 交差判定に必要なクロック数は、Core 2 と X2 で大きな差がありますね。
128-bit SIMD 演算器が Core 2 では 1 クロックに向上したことによることの恩恵でしょうか。
(そもそも、今まで SSE は 1 クロックで処理できるものと思っていたのですが、違ったとは)
とはいえ AMD も時期プロセッサでは fp 演算器を倍増するとのことですから、
この差はいずれ縮まるかもしれません。

次に、lucille 自体を、C2D 上で 32-bit バイナリ版と 64-bit バイナリ版で
速度比較してみました。
テストに使ったのは chinahou.rib です。

32-bit: 17.864 sec
64-bit: 16.177 sec

約 10% ほどの向上になりました。

64-bit にしても、それほど劇的にはパフォーマンスアップするわけではないようですが、
少なくとも 「C2D では 64-bit は遅くなる」ということはグラフィックスの場合には
無さそうです。

Uploading rendered animation.

なるほど、ビデオ共有にはこのような使い方があるのですね。

http://stage6.divx.com/members/218434/videos/1029389

これは単純なテス投稿です。レイトレーシングのアニメーションで、屈折球がシーン内で回っているだけのものを作りました。
自作レンダラでレンダリングしたシーンをアップロードして、
自作レンダラをアピールする場所として使えますね。
stage6 だとかなり高画質でアップロードできますので、
「エンコードの質が悪くて…」という問題もないでしょう。

これからの「国語算数理科GI」では、
課題をレンダリングした結果を stage6 にアップロードして提出せよ、
という風潮が出てきそう。

アメリカの大学の授業ではもうやっているかもしれませんね。