Syoyo Fujita's Blog

raytracing monte carlo

Category: paper review

[Paper] Ptex: Per-Face Texture Mapping for Production Rendering

http://www.disneyanimation.com/library/ptex/

遅ればせながら、Ptex を読んでみました.
SDS(サブディビジョンサーフェス)のフェースごとにテクスチャ座標をパラメータ座標で割り当て([faceid, u, v] で識別する)ることで、
UV 割り当ての必要が無くなり、また隣接するフェースの情報も保持することでフェース間でシームのない高品質なテクスチャマッピングを実現する手法です.

利点

– セットアップフリー(UV 割り当ての必要がない)
– フェースごとにテクスチャの解像度を操作できる.
– シームレス(正確にシームレスではなく、シームレスに近い状態にまでできる)

欠点

– モデラ側で Ptex をサポートする必要がある.
– パイプラインが変わる(disney ではうまくいった… なんて言っていますが、他のスタジオでも同様になるか不明?)
– SDS にしかつかえない.

個人的な感想としては、(もしやるなら) Ptex はレンダラ側でサポートするのはそれほど大変ではないけど(さほど複雑な処理をしているわけでないので)、
やはりモデラ側で Ptex の対応をどうするかが大きな問題になるかなぁ、というところです.
(現在某モデリングソフトに Ptex 対応をお願いしているらしいですが)

あとは、フェースごとにテクスチャを割り当てることで、テクスチャファイルの最適化ができるのはよいですね.
普通のポリゴンモデル + テクスチャマップというケースでも、単に UV 全体で mipmap を作るのではなく、
特定の UV 領域で miplevel の調整とかできるようなテクスチャフォーマットを考案するのもいいかもしれないと思いました.
(これはこれで、ペイントソフト側の対応が必要になりますが)

Approximating Dynamic Global Illumination in Image Space

ssdo.png
(image from “Approximating Dynamic Global Illumination in Image Space”)

Approximating Dynamic Global Illumination in Image Space
Tobias Ritschel, Thorsten Grosch, Hans-Peter Seidel
Proceedings ACM SIGGRAPH Symposium on Interactive 3D Graphics and Games (I3D) 2009
http://www.uni-koblenz.de/~ritschel/

うぉっ! これはすげー!

– スクリーンスペースなのでジオメトリの複雑さと無縁
– 動的ジオメトリ可
– 前計算なし
– GPU に容易に実装可能

で近似的に GI (1 回の indirect diffuse) をリアルタイムでやってしまっています.

手法としては、基本的には既存研究である SSAO(Screen Space Ambient Occlusion) と似ています.
各シェーディング点において周りのピクセルに対してサンプリング点を生成してそのサンプリング点のオクルージョンをチェックして光の寄与を求めます.

論文では、スクリーンスペースでの Directional Occlusion と Indirect bounces の手法について解説し,
そしてそれらの手法に対して、よりアーティファクトを減らすためのテクニックを提案しています.

Directional Occlusion

ssdo_sample.png
(image from “Approximating Dynamic Global Illumination in Image Space”)

AO(ambient occlusion) では遮蔽率に応じてグレースケールでしか GI 効果を実現できないのですが、
DO(Directional Occlusion) では、サンプル点が見えれば(上図の左で点 C が該当)、
サンプル点が対応する方向からの環境マップの色を採用することでよりリアリスティックなシェーディングを可能にしています.
(手法としては遮蔽を求める計算自体は SSAO と基本的に同じなので、あとは環境マップをフェッチしてその色を寄与とするかどうかの違いだけ)

Indirect bounces

ssdo_indirect.png
(image from “Approximating Dynamic Global Illumination in Image Space”)

Indirect bounces では 1 回の間接反射を実現します. 2 パスの処理になっています.
1 パス目は DO による処理を行い、2 パス目では DO パスの結果を元にして、同じようにシェーディング点の周りのサンプル点からの寄与を求めます.
(2 番目の図の右側)

このとき, 周りのサンプル点は 1 回目の結果により直接光の結果をストアしているので、これを集めることで 1 回の間接反射が実現できるというわけです.

—-

さすがにオクルージョンが大きく変化するときはアーティファクトが見られますが、
(たとえば視点や物体が移動して見えない部分が見えるようになったり、見える部分が見えなくなったりするとき)
それ以外はもう十分すぎるほどのレンダリング品質だと思います.
(低周波数ライティング環境下における GI 効果という条件で、ではありますが)

効率的で、動的シーンでも OK な GI 手法が年とともに提案されて、どんどん GI が実用的になってきていると感じます.

Out-of-core Data Management for Path Tracing on Hybrid Resources

outofcoredatamanagementforpathtracingonhybridresources_fig7.png
(from Out-of-core Data Management for Path Tracing on Hybrid Resources)

Out-of-core Data Management for Path Tracing on Hybrid Resources
Brian C. Budge, Tony Bernardin, Shubhabrata Sengupta, Kenneth I. Joy, John D. Owens
Eurographics 2009
http://graphics.idav.ucdavis.edu/publications/print_pub?pub_id=957

[Ja]

大規模シーン向けのスケーラブルなパストレアーキティクチャの提案.

Out-of-core と呼ばれる、必要なときだけメモリにデータをロードして有限なメモリ量でも効率良く大規模なデータを処理する手法をパストレにも応用して、スケーラブルなパストレにしてみました, という感じ.

また、GPU も使わなければもったいない(スケーラブルでない!)ということで、
GPU でもレイトレカーネルを CUDA で実装してより異種混合プロセッサの構成でもスケールするようにしています.

GPU でのレイトレですが、レイトレコアは CPU の 6-12 倍とありますが、
システム全体でみるとレンダリング時間は CPU と CPU + GPU との構成比較で 2-3 倍程度しか違いがないように見えます.
もちろんレイトレ処理だけがレンダリングのすべてではないのもありますが、
CPU が GPU での処理結果をサバき切れてないだけなのかもしれません.

GPU で処理を行う場合は、データをあらかじめ明示的に GPU 側に転送しなくてはいけないのですが、
そのような処理もスケーラブルパストレのフレームワークの中で実現しています.

なぜパストレをアルゴリズムとして選んだかというと、パストレが基本的に incoherent なアルゴリズムだから,
これがスケーラブルにできるのであれば意義があるからだそう.

論文からの上記の図は, なにも考えていないパストレ(standard)だとすぐに破綻してレンダリング時間がシーンサイズに指数関数的に比例するのが、
スケーラビリティを考慮したパストレならレンダリング時間がほぼシーンサイズに線形に比例していることを示しています.
(standard(無限大)はいまいち何なのか不明)

RenderMan だと数日、スケーラブルパストレなら 2 時間だぜ

スケーラブルであることの比較として、
240 M 三角形(2 億三角形)相当のシーンを RenderMan と提案されているパストレとでレンダリングし、
RenderMan だと 2 CPUs で数日かかるのが、提案するスケーラブルなパストレだと 1 CPU + 1 GPU の構成で
2 時間で終わったと報告しています.

RenderMan 野郎なら、「いや、RenderMan(reyes) も最適化すればもっと早くレンダリングできる!」
と言うかもしれませんが、しかしやはり RenderMan の古典的アーキティクチャ(reyes)がそろそろ
シーンの複雑性に追いつけなくなってきているということを示しているような気がしています.
そして逆に、シーンが複雑になるほど、スケールしやすいレイトレがだんだんと適合してくると.

やはりゲームもオフラインレンダラも、将来はレイトレが基礎のレンダリング技法になることは間違いないように思えます.

Course notes on Beyond Programmable Shading

(via ompf.org)

SIGGRAPH 2008: Beyond Programmable Shading
http://s08.idav.ucdavis.edu/

Extra infos on Larrabee, and next-gen graphics techs(parallel computing framework, raycasting, etc)

Here’s my impression on these slides.

Interactive Cinematic Lighting

It’s a just review of previous works. There’s no impressive things.
I know existing research has a serious drawback(to be solved in the future work), but Fabio doesn’t talks on it.

Next Generation Parallelism in Games.

Raycasting seems interesting. I am also thinking about efficient ray traversal using octree.
I believe raytracing(ray traversal) could be done in much more faster using brilliant new data structure, compared to using current hierarchical-based traversal algorithm(e.g. kd-tree, BVH).

For example, review exising BVH raytraversal.
1 BVH – 1ray packet traversal requires 100~300 cycles on CPU.
And moderately complex scene requires 50-100 traversals for each ray(or ray packet).
5,000 ~ 30,000 cycles is too much, isn’t it?

Larrabee Graphics Architecture: Software is the New Hardware

Main memory is thousands of clocks away

Thousands of clocks!!!

When we assume texture miss rate was 5%(95% of hit rate), At least texturing requires 50 cycles.
The miss rate significantly raises when multi-texturing was used(10 ~ 30% of miss rate I guess).

Fiber can hide latency of texuring, but number of fibers are limited to size of L2.
So I don’t think Larrabee core hold many fibers to completely hide latency of texturing.

Beyond Data Parallel: Advanced Rendering on Larrabee

I am a bit disappointing on this course note. There’s no new insight on the future(beyond data-parallel). Pharr just reviews current problem & situation.

Compiler tech become more important beyond progarammable shading

I think compiler optimization technique is the most important thing in the future of graphics.

Thus now I am intensively doing a research on compiler technology.
Research focus on automatic parallelization and optimized use of memory hierarchy automatically, and found some quite impressive previous works.

I’d like to list up some of previous works which is not yet imported or unveiled to graphics community, but is much valuable.

Global Multi-Threaded Instruction Scheduling
GREMIO, the proposed method in this paper, automatically partition the sequential program and execute it on multi-cores or multi-threads.
You don’t need to write paralell code!

Efficient dynamic heap allocation of scratch-pad memory
Memory Allocation for Embedded Systems with a Compile-Time-Unknown Scratch-Pad Size

Effectively using scratchpad memory but programmers can write their code without knowing memory hierarchy explicitly. This will greatly reduce programmer’s effort.

PLuTo – An automatic parallelizer and locality optimizer for multicores

Application where PLuTo is applicable(nested loops) might not helpful for graphics apps, but with PLuTo, you no longer need to blockize data to improve memory access. PLuTo automatically do it!

Automatic Pool Allocation: Improving Performance by Controlling Data Structure Layout in the Heap

This is good for optimizing tree data structure for example ray traversal.
With this method, you now don’t need to think about optimal packing for BVH & Kd tree node for optimial cache usage!

Larrabee paper review

http://softwarecommunity.intel.com/UserFiles/en-us/File/larrabee_manycore.pdf

読みました.
結論. 性能は微妙. レイトレアクセラレータロジックはなしのよう. 開発は楽なのが唯一の救いか.

Larrabee 構成概要

なんとも普通. そりゃ CPU メニーコアなので普通になりますね.

gather/scatter

VPU のインストラクションは L1 のアドレスをソースオペランドに取ることができる.

非連続アドレスからのロード(gather)と非連続アドレスへのストア(scatter)をサポートしている。
ただしキャッシュの速度に制限されるので、たとえばすべての要素が異なる場所を示していれば(データが L1 にキャッシュされているとして)最悪 16 サイクルはかかることになる。
ただし実際はそれなりにコヒーレンスがあるのでそれより少なくなるとのこと.

大域アドレス(仮想アドレス)に対する gather/scatter はできそうな記述ですが、atomic 操作とか考えるととても複雑になって実装が難しい気がしていますがどうでしょうか.

ベクトル演算命令は masked 実行あり。まあこれは普通ですね。ベクトルデータの load/store 命令でもベクトル要素ごとに mask をかけることができて, mask された要素はアップデートされないようにすることができるよう.こちらはたしかにあると便利.

GFLOPS

コア数は可変みたいだけど、たぶん製品として最初に出てくるのを考えると 16 コアの構成あたりが妥当そうでしょうか.
16 cores、1GHz, madd が 1cycle でできるとして、 

16(cores) * 16(vector width) * 1(GHz) * 2(madd) = 512 gflops

微妙なところですね(スカラ ALU の flops は dominant でないのでカウントしていません).

HWラスタライザ撤廃

この判断はいいと思うというか自然な流れですね。いまや HW ラスタライザ(とそれがあるためにレンダリングパイプラインが分断されてしまっている状況)は GPU の最大のネックですから。
ゲームなどは GPU レンダリングのパフォーマンスを出すために CPU で軽く
レンダリングしてから visibile なポリゴンを投入とか、deferred shading したりとラスタライザをなるべく経由しないようになっていますしね.

さらにポリゴンの密度がピクセルに近くなってきているのもラスタライザがネックになっている原因です. そろそろピクセルセントリックで処理したほうが効率的になりつつあります(その流れでレイトレ化という風にもなっています).

テクスチャは HW

テクスチャ処理は機能が決まっているわりに演算量が多い処理なので HW で提供というのは正しい判断です。Aniso filtering とか SW でやったらベラボーに時間がかかるしね.
 
ただ、演算コアから HW テクスチャユニットを使うには L2 を介して texturing コマンド(か特殊メモりアドレスへのアクセス?)を発行しないといけないので、テクスチャリングのレイテンシがでかそうなのが気になりますね。スレッディングとかで隠蔽はできますが、テクスチャリングのパフォーマンスを出すにはそのようなプログラミングが明示的に必要になりそうです.
テクスチャキャッシュは L1 相当の 32KB でその先はいきなり DRAM なのかな?
それだとマルチテクスチャリングしたときにキツいので、4MB のシェアードメモリの一部を L2 テクスチャキャッシュとして使えたりするのだろうか. でもそれだと 16 コア/4MB L2 の構成ができないから(256 KB x 16 = 4MB)、やはり 10 コア/4MB で一セットの構成になるんでしょうか.

半透明

フレキシブルな演算パイプライン構成だから半透明とかやりやすくなるとありますが、
帯域を考えるとよほど制約を与えないと使い物にはならない気がしています.

とはいえ、いずれにせよこれからのグラフィックスでは半透明、屈折, アンチエイリアスなどのなめらかで潤いのあるグラフィックス効果が重要になってくるはずなので、その流れを実現する一歩としてはいいかのかもしれません. 

レイトレ

1k x 1k, 4 Mray(eye ray + reflection) が、16 コアで 40 fps.
同じシーンを octa core CPU だと 12 fps.

レイトレ専用の HW ロジックも搭載しないみたいですし、
16 コア版で 4 倍程度(Larrabee 8 core なら 2 倍しかない)ということで
思ったほど Larrabee でレイトレというのはアドバンテージはないですね.

これだと普通に Larrabee 製品化時期の次世代の CPU で達成できなくもないレベルです.

Larrabee のレイトレ性能を理論値から計算してみますと、

512 Gflps / (41.16[fps] * 4 [Mray]) = 3,000 flops/ray

とレイあたり 3,000 flops. まあ RTRT の普通の CPU 実装だとだいたい数千 flops くらいでできると期待されますから(トラバース込みで)、flops レベルでは CPU 実装とあまり変わらないことになります。CPU が演算コアなので同等になるのは当然といえば当然でしょうか.

視覚的にリッチなリアルタイムレイトレを実現するためには 3T flops が必要と 10 年前にすでに予測されていますが[1]、私も [1] との計算方法は異なりますが 3T flops くらいが必要だと思っています.

たとえば 2k x 1k pixels, 60 fps 実現するとして, 120 Mpixels/sec 処理する必要があり,

3 [Tflops] / 120 [Mpixels] = 25,000 flops/sec

これだと 1 レイの処理に 2,500 flops をかけたとして, レイを pixel あたり 10 本処理することができます. これだけ処理できれば既存のラスタライズグラフィックス品質+αをレイトレで実現できるでしょう.

そんなわけで、3T flops を実現してレイトレプロセッサを謳うには Larrabee は 48 cores @ 2 GHz の構成にする必要があります. 第一世代でここまでの構成は、どうでしょうかね、なんとか実現可能かもしれませんが難しいところだと思います.

金融

たとえば単純な BlackScholes option pricing だと算術関数が一番のネックなので、これがアクセラレートされないとベクタ長やコア数のスケール以外ではさほど CPU との違いはない気がしています.

開発環境

既存の C/C++ 開発スタイルで開発できます. Larrabee Native というプログラミングモデルと呼ばれています.
それ以外でも、DX の compute shader とか Ct, SPMD スタイルも利用可能.
プログラマブルパイプラインの利点ですね.
また、演算コアでの printf とかもサポートするようなのでデバッグが楽にできます
(ただし printf などは host と通信する必要があるのでベラボーに遅くなるはず.
使うとしてもデバッグ用途だけにするのがよさそうです)

まとめ

性能は微妙ですが、開発が既存のモデルをそのまま大体使えそうという利点は大きい.

Larrabee がいきなり既存の GPU を置き換えるとかリアルタイムレイトレプロセッサとして使えるほどにはなれそうにありませんが(しかも実際に製品として出てくるにはあと 1,2 年かかることを考えると、さらに性能に疑問があります)、
たとえばオフラインレンダラの高速化などの、単なるプログラミングしやすい演算アクセラレータとして使うにはいいかもしれ
ません。

MUDA や lucille で Larrabee をサポートするのはどうするかなぁ… Intel の SDK の出来次第でしょうか. ’08 末あたりにはシミュレータが提供されはじめるみたいなので、それから考えることにします.

おまけ

しかし、論文はいかにもやっつけな感じですねぇ、、、特に図が.

Refernces

[1] 並列画像処理
http://www.amazon.co.jp/dp/4339025933

EGSR 2008 papers

(via private communication)

http://kesen.huang.googlepages.com/egsr2008Papers.htm

There are interesting papers this year!
Especially,

Shallow Bounding Volume Hierarchies for Fast SIMD Ray Tracing of Incoherent Rays
Holger Dammertz, Johannes Hanika, Alexander Keller
http://www.uni-ulm.de/in/mi/mitarbeiter/holger-dammertz.html

QBVH

They makes QBVH, quad-tree BVH which is applicable for SIMD processing.
In QBVH it tests 4 bounding box simultaneously by SIMD, while traversal is done in single mono ray.

They reports QBVH is about 2x faster than BVH for path tracing setting.

Using n-ary BVH for RT raytracing is already proposed in Japan by Kimura[1]. They tested up to 16-ary BVH.
Dammertz et al. have to cite Kimura’s paper 😉

entry point caching

The paper also proposes entry point caching to speed up shadow ray tracing, which is somethat similar approach introduced by Reshetov’s MLRTA[SIGGRAPH 2005].

Performance gain using entry point cache for tracing shadow ray is not so significant, up to about 60% faster when the scene has complex visibility.

[Ja]

なんか今年の EGSR はすごそうだ。
SIGGRAPH が年々論文の質が落ちているのにたいして、
EGSR はじょじょにクオリティがあがっています。
(タイトルを見ればクオリティが大体わかる)
学術界はそういう風に流れをつろうとしているのだろうか。

さて、早速タイトルに興味をひかれて、

Shallow Bounding Volume Hierarchies for Fast SIMD Ray Tracing of Incoherent Rays

を読んでみました。

レイトレのデータ構造を 4 分木 BVH(QBVH)にして,
bounding box の交差判定を SIMD で同時にやる手法。

ただしレイのトラバースはパケットではなくて、
シングルで行っている。
パケットでやると分岐のコストが大きくなるから、というのと、
シングルのほうが incoherent rays にそのまま使えるからという
判断のようだ。

パストレのレンダリングにおいて、BVH を使うよりも QBVH を
使ったときのほうが、最大でレイトレ時間は 1/2 に
高速化できたことを報告している。
(かつ、メモリ使用量も少なくなる)

QBVH の利点は、パケットレイトレをしているわけでないので、
既存レンダラに組込みやすいということ
(パケットにも対応できるでしょうけどね)

ちなみに、空間データ構造を4分木で持つというのは
すでに日本では先行例があります [1]。
彼らはこの文献も cite すべきだよなぁ。

うーん、これが「あのお方」が言っていた、
「incoherent ray の効率的な処理方法を近々発表するよ」
のやつなのかなぁ、、、たぶん違う気がする。
今回のは非リアルタイム系で、
「あのお方」はリアルタイムレイトレ系の方を意味していたはず。
でもラストオーサーは「あの」会社だしなぁ…
やっぱこれなのかなぁ…

References

[1] 並列演算に適したバウンディングボリューム階層によるレイトレーシングの高速化
木村秀敬.
http://www.jaist.ac.jp/library/thesis/ks-master-2007/paper/h-kimura/paper.pdf

Real-Time KD-Tree Construction on Graphics Hardware

Real-Time KD-Tree Construction on Graphics Hardware
Kun Zhou; Qiming Hou; Rui Wang; Baining Guo
http://research.microsoft.com/research/pubs/view.aspx?
0rc=p&type=technical+report&id=1468

My impression: TOO BAD!
The comparison against CPU is not fair.
And much worser, when analyzing the result the GPU implementation is 4-5 times inefficient than CPU.

これはひどい.

– レイトレのトラバーサルパフォーマンス

Core2 CPU 4 core にたいして GF8800 Ultra で、差が良くて GPU が1.5 倍.
複雑なシーンでは 10 % 程度の向上しかない.
理論値で比較すると、GFLOPS が 1/4, メモリ帯域が 1/4 ~ 1/5 の CPU と competitive って…
最新 8 core CPU に負けるじゃん.

– kd-tree construction
なぜパフォーマンス比較に [Wald & Havran 2006] を使うのだろうか? そりゃ勝てるだろ.
構築 Quality が低いからと言っているが、[Shevtov et al 2007] と比較すべき.

– stackless kd-tree は遅いので使わなかった
これは良い判断というか当たり前ですね. 帯域と演算量が増えるのだから.
いまの時代 GPU でも local メモリがあるのだから、stackless を使う必要はもうないだろう.
(stackless が stack 版に比べて 10% 程度のオーバヘッドにしかならないなどの効率のよい
stackless アルゴリズムが提案されない限り)

– kNN search
> プライオリティベースの手法は GPU では効率が悪いので使わなかった.

と言っておきながら、でもパフォーマンス比較では CPU 実装には
この効率が悪いプライオリティベースと比較して、GPU が 10 倍以上早いと言っている.

CPU 実装のほうも提案手法でやって比較するべきだろう.たぶん差はもっと縮まるはずである.

– パフォーマンスについては観測値しかのせていない
bandwidth, トラバース回数, 評価したノード数なども載せないと、fair な比較ができないし、
分かる人間が読めば、観測値では(ねつ造で) GPU が早いように見えるが、
実際は GPU のほうが効率がわるいのが分かる.
(提案手法を CPU で再実装したほうが効率がよい)

まとめ

しかしなんでしょうね、GPU 系の論文はなんで相変わらずこんなにも粗悪なのでしょうか.

– 無理矢理勝てる相手を見つけての比較
– 観測値だけ見てほら早くなったでしょ
– 十分でない考察
– こーすっと並列度がまして GPU で処理しやすくなるかもしれネ
– -> やってみたらなんかいい感じだったよ.

なんか GPGPU が出てから、このような粗悪な論文がとても多くなったような気がします.
GPU メーカーからお金でも流れているのかなぁ
研究者がこんな論文を嬉々として書いているのだったら、なんか悲しいです.

おまけ:
FLOPS もそうだけど、帯域がこれからのレイトレではネックになりそうですね.
http://www.cs.utexas.edu/~pnav/papers/utcs-tr-06-40/utcs-tr-06-40.pdf

もうひとつおまけ:
http://pc.watch.impress.co.jp/docs/2008/0402/tawada138.htm
> メモリクロックが引き上げられて多少カバーされているものの、GeForce 9800 GTXのメモリ帯域幅は70.4GB/sec。GeForce 8800 GTXは86.4GB/secとなるので、この部分ではダウングレードしている。

これから重要になる要素が帯域なのに、そこがダウングレードはまずいでしょ.
GPU もシングルチップでの性能アップはもう無理そうですね.
マルチコア化 or 廉価版拡大でインド、ブラジル、ロシアなどの新興国向けに焦点を絞っていくかでしょうか.

—-

私はもう GPU (で何かやる)のは終わりだと思っているので、
GPU ネタ論文とかに感想を書くのはこれで最後にしたいと思います.

Filter Importance Sampling

Filter Importance Sampling
M. Ernst, M. Stamminger, G. Greiner,
RT06
http://doi.ieeecomputersociety.org/10.1109/RT.2006.280223

簡単な要約

レイトレでのピクセルサンプリングでは、
サンプル点の分布はリコンストラクションフィルタ(Mitchell とかね)の重みを考慮していない.
そこで本手法では、リコンストラクションフィルタの分布からサンプル点を
インポータンスサンプルで生成する手法を提案し、MC ノイズが 50% ほど減ることを示しています.

# リコンストラクションフィルタの関数に従ってサンプル点を分布させるのは、
# なんか前からあったような気もしないでもないですが.

問題定義

通常のレンダリングでは、レイトレなどでサンプリングをした後、
そのサンプル群からリコンストラクションフィルタで各サンプルを重み付けして最終的なピクセル色を求めます.

このとき、サンプルの値が大きくても、それに対応するリコンストラクションフィルタの重みが小さくて、
最終的なピクセル色へのサンプルの寄与が小さくなることがあります.

たとえば論文では、となりあうピクセルで、強いライティングからのサンプルが、
一方のピクセルではフィルタ重みが小さいので寄与が小さく、
他方のピクセルではフィルタ重みが大きいので寄与が大きくなり、
結果として分散が大きくなってノイズとなることを例として取り上げています.
(とくに 1 pixel あたりのサンプル数が 64 などと少ないとき)

提案されている解決方法

問題は、リコンストラクションフィルタの分布が考慮されていないためです.
そこで本論文では、リコンストラクションフィルタの分布にしたがって
サンプル点をインポータンスサンプリングして生成し、
重みはすべて同じ(=box filtering)とすることで、
このような現象に対処して既存手法より 50% のノイズ減少が可能であることを提案しています.

リコンストラクションフィルタにしたがってサンプル位置を生成するので、
たとえばフィルタ幅がピクセル幅を越えている場合は、
ピクセルをはみでるサンプルもでてくることに注意します.

私的考察

手法としてはリコンストラクションフィルタにしたがってサンプル位置を分布させるだけなので、
実装は容易なほうでしょう.

しかし、問題は、これはリコンストラクションも込みの関数からのインポータンスサンプリングなので、
リコンストラクションフィルタがあらかじめ決まっている必要があるということです.

プロダクションなどでの利用では、サンプリングとピクセルリコンストラクションは
分離していたほうが良い気がします.
(コンポジット時にサンプル点の Z 値を使うとか, ピクセルになる前の情報が必要だと思うので)

本手法はリコンストラクションフィルタが bake されていてもよい、
という用途では有効と言えるでしょうか.

Recent advances on motion blur rendering

Last week, I’ve talked/discussed a lot with renderists over the world about the offline renderer.

After the discussion, I think we’ve confirmed that there is still a lot of things to do in (global illumination) rendering.

One of it is fast & efficient computation of motion blur, this still has not been solved fully in the context of RenderMan style renderer, as well as ray tracing renderer.

After I’ve researched recent advances on motion blurring, I found interesting paper.

Eulerian Motion Blur
Doyub Kim and Hyeong-Seok Ko,
In Eurographics Workshop on Natural Phenomena, 2007,

http://www.doyub.com/research/

eulerian_mb.png
(image from Eulerian Motion Blur)

Almost all previous motion blur technique focuses on Lagrangian motion(e.g. moving objects).
They propose new Eulerian motion blur techniques.
(Some people may imagine this approach is similar to image-based motion blur technique)

Natural phenomenon & fine geometries(fluids, clouds, gases, furs, etc) become dominant part in the (production) graphics, thus I think such a Eulerian motion blur techniques will be developed & used intensively near the future.

Here is another recent papers about motion blurring.

Zheng, Yuanfang ; Köstler, Harald ; Thürey, Nils ; Rüde, Ulrich:
Enhanced Motion Blur Calculation with Optical Flow .
In: Aka GmbH (Hrsg.) : RWTH Aachen (Veranst.) : Proceedings of Vision, Modeling and Visualization 2006 (Vision, Modeling and Visualization Aachen 22. – 24. Nov 2006). Aachen : IOS Press, 2006, S. 253–260. – ISBN Erscheinungsjahr.
(see my previous post on this paper)

Frank Dachille, Arie Kaufman,
High-Degree Temporal Antialiasing
Proceedings of Computer Animation 2000, pp. 49-54, 2000.
http://citeseer.ist.psu.edu/455657.html

highdegree_mb.png
(image from High-Degree Temporal Antialiasing)

(my old post on this paper)

Pixmotor: A Pixel Motion Integrator
SIGGRAPH ’07 Technical Sketch, August 2007
Ivan Neulander
http://www.rhythm.com/~ivan/pubs.html

pixmotor.png
(image from Pixmotor)

Vlastimil Havran, Cyrille Damez, Karol Myszkowski and Hans-Peter Seidel
An Efficient Spatio-Temporal Architecture for Animation Rendering
Proceedings of the 13th Eurographics workshop on Rendering, Leuven, Belgium, Pages: 106 – 117, 2003
http://www.mpi-inf.mpg.de/resources/anim/EGSR03/

spatio_temporal_arch.png
(image from An Efficient Spatio-Temporal Architecture for Animation Rendering)

(my old post on this paper)

[Ja]

まだまだ、グラフィックスの研究はやるべきことは一杯あるなー、と実感。
まあモーションブラーについては前にも指摘したと思いますが、今一度。

Hardware-Aware Analysis and Optimization of Stable Fluids

Hardware-Aware Analysis and Optimization of Stable Fluids
Theodore Kim
I3D 2008.
http://www.cs.unc.edu/~kim/I3D08/

both3small.jpg
(image from Hardware-Aware Analysis and Optimization of Stable Fluids)

I like what they are doing in this paper, i.e., first estimate theoretical performance of computation and bandwidth of the algorithm, compares measured performance and theoretical peak to find bottleneck, then derive new technique which fills gaps between measured performance and theoretical peak.

Stable Fluid is bandwidth-intensive

They find that classic “Stable Fluid” algorithm is bandwidth-intensive.
80% ~ 95% of computational core is idle while waiting input/output data.
Its a bit surprise because I’ve thought fluid simulation algorithm is still compute-intensive.

I think, in global illumination algorithm development case, estimating a theoretical peak performance as done in this paper is alsp important before starting to implement my/your new GI algoritm.