Syoyo Fujita's Blog

raytracing monte carlo

Month: June, 2008

ヒカルの GI

主人公・大域照明(おおいき・ヒカル)はごく普通の小学校6年生。祖父の家の倉にあった古い Utah teapot に血痕を見つけたヒカルは、その Utah teapot に宿っていた錬金術時代の天才光学者・ニュートンの霊に取り憑かれる。光追跡のルールもニュートンがかつて憑いていた陰影聖・Bui Tuong Phong の強さも知らないヒカルは、「神の一追跡を極める」という彼の壮大な目標に付き合わされ、彼にせがまれるままに光を追跡することになる。以降、ニュートンはヒカル以外には姿も見えず会話もできず、物を動かすことすら出来ない存在であることを前提に話は進む。

通称、ヒカ GI(ヒカギ).
これで CG 教本を書いたらおもしろいと思うんですよね。

Coocle

単語を入れるとくくってくれる、
Prof. KMT が最近提案した次世代の検索エンジンである Coocle 構想、
すでに実サービスとなっていました!

http://zapanet.info/coocle/

これはすごい.

レイトレーシングでくくってみる.
http://zapanet.info/coocle/?q=%E3%83%AC%E3%82%A4%E3%83%88%E3%83%AC%E3%83%BC%E3%82%B7%E3%83%B3%E3%82%B0

ふむふむ、なかなかくくり精度が高いですね.

GPU でくくってみる.
http://zapanet.info/coocle/?q=gpu

なるほど、そりゃ 1T flops が $199 だもんなー.

Google funding PyPy progress

(via reddit.com)

http://morepypy.blogspot.com/2008/06/pypy-improvements.html

ぱいぱいプロジェクトに Google からのオープンソースファンディングが行われたとのこと。

ぱいぱい(PyPy)プロジェクトは、python コードを実行時に JIT や型推論によるスペシャライズなどの最適化を行い、 C 言語と同じくらいの速度で実行させようとする取り組み。

スクリプト言語(動的言語)のような完結さと自由度がありながら、実行時は静的言語(ネイティブコード)と同じくらいの速度で動くという、スクリプト言語デザイナの究極の目標のひとつの実現がこれで加速されるかもしませんね.

グラフィックスをやっている人間からすると、python とかのスクリプト(インタプリタ)言語は記述は楽でいいんですけど、パフォーマンスが絶望的なので実用に耐えられないんですよね。かといって C を使い続けるのも、コーディングの生産性が低いので不満がある。

そんなわけで、部分的に C のモジュールを呼び出すとか、スクリプト言語を DSL やコードジェネレータとして使うとかでパフォーマンスを上げる方向に行くわけなのだけれども、やっぱりなんだかんだで設定が面倒だったり、ネイティブ/スクリプト間などのインターフェイスを考えないといけなかったりする。
普通にスクリプトを書いたら、そのまま全体が最適化されて実行されてくれるのがうれしいよね。PyPy ならそれをきっとやってくれるんじゃないかと思っています。

Visualizing Light Transport

(via C0DE517E)

MLT vs Monte Carlo

Wow, we can easily understand how MLT works with this video.

Discussion about ATI’s new ruby demo.

http://ompf.org/forum/viewtopic.php?f=6&t=882

cinema 2.0 の ATI の ruby デモで、
これはどうやっているのか、ompf でも議論が交わされている.
レイトレだと思っていたけど、どうも違うみたいだ.

– ボクセルレンダリングだよ(+圧縮つき).
– 前計算したのをストリーミングで表示しているだけだよ(カメラパス固定)
– 新しいリライティング手法だよ.
– いやいややっぱレイトレだろ.

というか、発表会で直にデモを見たヤツはいないのだろうか?

ビデオを見るかぎり、レンダーエレメントの表示
(フォトンマップ?, オクルージョン?)と、
露出を動的に変えることができるリライティングツールとしての
機能が少なくともあるみたいだ.

ついでに、解説を書き起こしてくれたひとがいるけど、
ネイティブでもよく聞き取れなかったのですね.
(うまく聞き取れなくて、自分の英語力が足りないのかと思った)

Ruby raytraced, and AMD’s cinema 2.0

http://www.hothardware.com/News/AMDs_Cinema_20_to_Tackle_MovieQuality_Realism/

ruby_rt.jpg

(a larget image at pcper.com)

AMD’s new Ruby demo states that it is realtime raytraced!

And more, AMD’s cinema 2.0 looks promising.
Although people in productions may still choose CPU rendering for (final) rendering for robustness and functionality,
cinema 2.0 will definitely bring acceleration for rendering of editing & previewing scene for interactive feedback.
(And this is the most important part in the production pipeline).

[Ja]

今回の ATI の新製品とデモはすごいですね.
リアルタイムレイトレがかなり現実的なものに感じられました.

でも 1T flops (+ quad CPU?) のパワーがあるといっても、ruby の新しいデモはぜんぶレイトレされているのだろうか。
(しかもなんか解説ではフォトンマップがどうのとか言っています。フォトンマップまでやっているのか?)

画面を見た限りでは、 dominant な要素は一次レイと完全反射なので(影は fake そう)、
まあ頑張れば今のリアルタイムレイトレ技術で出来なくはないとおもいますが…

でもこのレイトレデモを作ったのはどのチームなのだろうか?
優秀なレイトレ野郎は I に行ったから(落ちこぼれは N に行ったけど)、
これだけのものを作れるレイトレ技術者がいたことに驚きました.

RapidMind のマククールとか, 以外を付いて Ramamoorthi lab のビームレイトレ野郎とかだったりして.
(A については私はサイダー情報をもっていないので、いろいろ思いつくことを自由に書いています)

cinema 2.0 も、なかなか promising な提案だと思います。

最終レンダリングは、Gelato を見て分かるように GPU でやる価値はあまりないわけですが
(実際プロダクションの人たちに聞いても GPU で最終レンダリングをアクセラレートには否定的)、
ライティングやマテリアル編集のインタラクティブプレビューなどにこの cinema 2.0 を使うのはかなり価値がありそうだと思います.
(こちらのほうが時間がかかるので、アクセラレートされるとプロダクションでは重宝される)

金融ニュースサイトから PC ニュースを得る利点

前回ちょっと書きましたが、
最近は PC 情報などは主に金融ニュースサイト(google finance が主)から得るようになっています。

PC ニュースサイトから PC 系のニュースを得るのではなく、
金融ニュースサイトから PC 系のニュースを得る利点はどんなものか、ちょっと考えてみました。

情報が素早く得られる.

金融は情報の鮮度が命なので、新製品発表などがあった場合はすぐに情報が伝わります。
とくに金融ニュースサイトは自サイトのアクセス数を増やすためにも、
情報があればすぐに掲載しなければという力が働いてるはずです。
結果、我々は情報をすぐに得られることができます。
(まあ PC のニュースは、情報トレーダーをやるのではなければ、
そんなにすぐに得られるというのはさほど重要ではないですが)

メーカーごとに情報がまとまっている

たとえば AMD, NVDA, INTC, JAVA などの銘柄ごとにまとまっているので、
メーカー別で情報を得たい場合に有益.
結構これが便利.

違う視点からの情報を得られる.

PC サイトからなどでは、主に技術的な側面からの情報が主になりますが、
金融系であれば、インベスターや財務からの視点で製品情報などの解説が
されたりするので、新製品がどれだけマーケットに影響を与えているのか
など、より広い視野で情報を得ることができます.

—-

とまあ、こんな感じでしょうか.

おまけ

ランキングなんて、、、意味ない(いちカイにヤリ 投資世代)
http://www.doblog.com/weblog/myblog/31550/2620418#2620418

そういう訳なので『アルファブロガー』というところから「こんど人気投票します、ノミネートされてますからブログにバンナーを貼って置いてください」というメールがきたときは少なからず立腹しました。

さすが!やはり金融関係にはスマートなひとが多いですね。
なんちゃって web 2.0 野郎と違い、ちゃんとわかっていらしゃる。
我々は金融方面から、financial literacy 意外にも、
いろいろなものを学習させていただく必要があると思う。

そのような意味では、Fischer Black 先生の自伝にはとても感銘を受けました。
研究に対する態度・ライフスタイル、研究者としてのあり方など.
Black 先生は実務からの研究を重視し、
学術方面からの研究については、
「象牙の塔の研究者は、その者が行った研究ではなく講義によってのみ評価されるべきである」
と痛烈に(?)批判されています.
私もまったくその通りだと思います.

また、学術寄りな人物として初めて Black 先生は Goldman-Sachs のパートナーになっています.
(パートナー = 共同経営者。Goldman-Sachs に入社した者は皆パートナーになるのが
目的であったといってもよいだろう. 出世の最終地点と言える.
現在は株式会社になったので、パートナー制ではなくなった)

Binning-based SAH BVH construction

I’ve implemented binning-based SAH BVH construction [1].

sponza_bvh.png

http://lucille.svn.sourceforge.net/viewvc/lucille/
trunk/src/render/bvh.c?view=markup

binning-based SAH construction is known in realtime raytracing field as it computes sufficiently optimal SAH in blazingly fast construction time.

Despite to my previous manner(implementing an algorithm in indivisual program), I’ve implemented binning-based SAH BVH in lucille core, since I believe this method is promising and practical.

How much is it fast?

Construction with binning-based SAH is amazingly fast.

SAH BVH for sponza scene(76k triangles) was constructed just 0.49 sec on my Core2 2.16 GHz!

And more, current my implementation is straightforward and unoptimized, thus there’s a enough room for optimization by using MUDA and tuning memory access(x10 speed up could be possible).
But I am much satisfied with the speed from current implementation
(less than 1 sec is sufficient for offline rendering)

Visual diagnositics for spatial data structure

I’ve also added visual diagnostics for BVH traversal to debug & tuning traversal.

Visualizing hit distance.

sponza_depth.png

Visualizing # of node traversals(blue = few, green = middle, red = much).
sponza_travs.png

Visualizing # of triangle isects
sponza_isects.png

[Ja]

やっとこさ、lucille の次期バージョンがモノになりつつあります.
その第一弾として、ビンニングベースの SAH BVH を lucille 本体のコアに実装しました.

いままではアルゴリズムのテスト実装は独立プログラムとしてコーディングしてばっかりだったのですが、
ビンニングベースの SAH BVH はかなり実務的かつ効率的なので、
lucille の空間データ構造アルゴリズムとして採用することにしたためです.

sponza シーン(7 万三角形)で、leaf には 4 個の三角形以下になるまで再分割して構築して、Core2 2 GHz で 0.49 sec.
特に SIMD 化もメモリ最適化もしていない素直なコードでも、
これだけ高速に構築できて、個人的には非常に満足していませす.

ついでに、テストビューアとビジュアルダイアグノスティックス(ビジュアル診断)も実装して、
レイのトラバース回数などを視覚化して確認できるようにしました.
パフォーマンスのチューニングなどに使っていく予定です.

とはいえ、ちょっと視覚化してみて傾向を見て分かったことですが、
小手先のトラバース処理のチューニングではもうダメで、
効率化にはアルゴリズムそのものを変えないとダメですね.

トラバースの視覚化診断結果から、なんか新しくてとても効率のよいレイトレの
空間データ構造が、いくつか首のあたりくらいまで思いつくのですが、
なかなか最後までひらめききらないですね。もう少し時間がかかりそうです。

[1] Highly Parallel Fast KD-tree Construction for Interactive Ray Tracing of Dynamic Scenes
Maxim Shevtsov, Alexei Soupikov and Alexander Kapustin.
EUROGRAPHICS 2007
http://graphics.cs.uni-sb.de/Courses/ss07/sem/index.html

AMD goes with OpenCL

(via google finance)

AMD Stream Processor First to Break 1 Teraflop Barrier
http://www.amd.com/us-en/Corporate/VirtualPressRoom/0,,51_104_543~126593,00.html

In keeping with its open systems philosophy, AMD has also joined the Khronos Compute Working Group. This working group’s goals include developing industry standards for data parallel programming and working with proposed specifications like OpenCL. The OpenCL specification can help provide developers with an easy path to development across multiple platforms.

“An open industry standard programming specification will help drive broad-based support for stream computing technology in mainstream applications,” said Rick Bergman, senior vice president and general manager, Graphics Product Group, AMD. “We believe that OpenCL is a step in the right direction and we fully support this effort. AMD intends to ensure that the AMD Stream SDK rapidly evolves to comply with open industry standards as they emerge.”

Its a good news that AMD comply with OpenCL.
Since OpenCL itself might be just a specification, they’d continue to develop their own Stream SDK for their implementation.

[Ja]

最近 PC 系ニュースも PC 系サイトからではなく金融系サイトからになりつつあります。

それはさておき、AMD は OpenCL をサポートをするようですね.
現状では OpenCL が並列言語戦争(?)における一番の本命になりそうだ.

Apple は OpenCL の実装に LLVM を使うようだが、
AMD は既存の Stream SDK(Brooks, CAL) を使って
OpenCL の実装を行うみたいだ.

ところで、Ct も OpenCL も、データ並列言語なんですよね。
まあそれがコンパイラを実装する側も、プログラムを書く側も
一定レベルまではやりやすいんだけど、
少しアルゴリズムが複雑になると、
途端にアルゴリズムのマッピングが難しくなるんですよね.
とくに大域照明のアルゴリズムとか.
そーゆーわけで、データ並列言語は直近の実務解だと思うけど、
もっと先を見据えて考えてみると、一時的な移行期の言語で終わってしまうと思います.

Intel’s Ct has JIT compiler.

(via lucillerender.tumblr.com)

9年前のアイディアから生まれたAtom
〜研究活動を紹介する「Intel@Research Day」
http://pc.watch.impress.co.jp/docs/2008/0613/hot554.htm

Intel の並列化言語 Ct では、JIT コンパイルで SSE, AVX, Larrabee のコードを
実行時に生成するようになるのか. これはなかなかよいですね.
ただ、Intel のことだから、JIT インフラには LLVM は使わずに、
独自の JIT インフラを作ってやっていきそう.

ついでに、Intel は特に CUDA にも OpenCL にも流れず、自分路線(Ct?)でいくようだ.
まあそりゃ Ct を立ち上げておいて、いまさら引けないから当たり前だろうか.

http://softwareblogs.intel.com/2008/06/10/mac-os-x-106-snow-leopard-reading-from-the-intel-cookbook/

競合はよいものだ、と言っているけど、開発者にとっては統一されていたほうがありがたいなぁ。

そんなわけで、MUDA をさらに上位な言語として、MUDA から Ct や OpenCL コードを吐くようにする、という仕組みにすることを考えています。