The real cornell box

Recently we’ve built a real cornell box!
It was a nice experience to understand real world light transport :-).

Technology behind the scene

Also, as a bonus, here’s light field capture of cornell box using Lytro camera.

https://pictures.lytro.com/nikq/stories/12978

リアルタイムレイトレエンジニアを探せ！

http://lucille.atso-net.jp/blog/?p=873 のつづき.

とまあ、そんなわけで(?)、思いのほか早く、リアルタイムレイトレエンジニア、
特に SIMD 最適化とかの低レベルチューニングができるリアルタイムレイトレエンジニアを確保する必要が出てきてしまいました.

当たり前ですが、今からどこかポテンシャルのある人物を採用して、リアルタイムレイトレエンジニアとして教育していくのでは間に合わないわけで、
ヘッドハント的なことをしてどこからか引き抜いてくる必要があるわけですが、
うーん、海外含め、まあマジでリアルタイムレイトレエンジニアなんて現状希少品種なんでまず居ないわけ.
居たとしても、すでに他の仕事で忙しく無理だったりとか.

世の中、人財とタイミングですねー.
いずれにせよ、なんとか探してみようと思います.

で、なんでかしらないけれども、そんなことをするときに一番役立っているのが、6 年くらい前までの、僕がまだ学生のころに築いたグラフィックス関連の人脈.
これもやっぱりタイミングと言えるかも(リアルタイムレイトレへの布石は 6 年前から始まっていた！なんてね).

もし、オレこそリアルタイムレイトレエンジニア！と思わん方がいればご連絡ください.

とくに、GPU レイトレとかではなく、
固定小数点でレイトレトラバーサルが書けるなどのスキルがあったり、
メガデモコーディングなどの低レベルチューニングができるようなスキルがあるほうが望ましいです.

NativeClient + SW raytracer = A new web 3D experience in very near future.

NativeClient が Google chrome 4.0 beta に搭載されているっぽい.
そんなわけで、もう少ししたら、ネイティブな速度で動くアプリが一般的な Web ブラウザ環境で実現できそうな雰囲気があります.

と、そうなると、ここで SW レイトレを走らせたら… と思いますね.
(O3D は GPU に依存する&ラスタライズグラフィックスという時点で未来がない. そもそもラスタライザは死んだし)

簡単な見積もりを取ってみましょう.

いまのだいたいの汎用的な PC 環境を考えると、 CPU は 2 GHz くらい.

2 GHz のマシンで、384 x 256 ピクセルの解像度のレイトレを 30 fps で実現するには,
2 * 1000 * 1000 * 1000 (Hz) / (384*256*30) = 678 cycles/pixel

と、ピクセルあたり　700 サイクルあれば実現できます.
SIMD 最適化レイトレエンジンなら、テクスチャも張りつつ結構それなりのモデルを扱えるような負荷量です.

web での利用なので、ハイエンドゲームみたいにゴテゴテなグラフィクスをやらなくていいし、
またレイトレでしか実現できない表現で攻めれば、低解像度でも意外と満足するとおもう。

ってか逆に twitter のように、ゆるふわで頑張らないグラフィックスクオリティが求められていそう.
(ちょっとレンダラ野郎にとってはこの点は残念かもしれないけど)
もちろんポリゴンレンダラと十分差異化した上での話ですけど.

意外と SW レイトレって大きな市場を取れる気がするんですよねー. たとえば今回のような web グラフィックス用とか.
しかも意外とまだ競合(?)がいない感じ.

レンダラインターン採用

以前にレンダラインターン欲しいなぁ… と書きましたが
(http://lucille.atso-net.jp/blog/?p=871)

このたび、我々にとって初のレンダラインターンを採用させていただきました.
レンダラに興味があり、かつインターンをしていただける時間を割いていただけるとは、とてもありがたいことです.

レンダラインターン(フォトリアル系、GI 系)なんて、
世界初!、とは言わなくとも、世界でもかなりまれな存在ではないでしょうか?
(でも、リアルタイムレイトレ系をやらせたら世界初、かもしれませんね 🙂 )

インターンもそうですが、最近はだんだんといろいろレンダラ、リアルタイムレイトレに道が見えてきてきています.
だんだんと面白くなってきました. (まあまだどうなるか分かりませんが、、、)
ここでどう先行者利益を確保していくか、そろそろ本気で考えていかなくてはいけませんね(レンダラ財団設立資金確保のために).

Realtime raytracing goes mainstrem in the very near future.

日経エレクトロニクス 10 月 5 日号で、リアルタイムレイトレの記事が特集されます.

http://techon.nikkeibp.co.jp/article/HONSHI/20090925/175633/

ゲームや映像制作などのグラフィックス野郎ではない、より一般的なところでもリアルタイムレイトレが注目されようとしています.

最近では NV もレイトレを重要なアプリのひとつにしようとしていますね.
http://www.4gamer.net/games/099/G009929/20091001065/screenshot.html?num=009

(ところで、写真の Physics のところ、fumeFX だよね… もしかして fumeFX の会社を買収したのか？！)

大手が動き始め、一般人も注目してきて… だんだんと(リアルタイム)レイトレの波がやってきているという感じでしょうか.

とはいえ、Intel や NV がバカスカとレイトレにお金を突っ込んだとして、うまくいくかというのはまた別の話.
個人的にはどっちも Winner’s curse(勝者の呪い)に陥るんじゃないかと思います.

リアルタイムレイトレは新しい技術と新しいマーケットですから、ビジネスとして考えたときには、
小さい開発会社や個人でも十分これら大企業と戦える戦場になるだろうと思っています.

まー、とりあえず直近の問題は、とはいえ見た目で判断すると、FPS に見られるようなグラフィックスにはレイトレはまだまだかなわないということ.

一方で、FPS などに見られるグラフィックス表現も半導体性能の向上やラスタライザ表現力が頭打ちなわけで、将来性に疑問が残ります.
実際、NV の PC 向けハイエンド GPU のマーケットはここ数半期赤字で(SEC form 10-K 参照)、
高品位 FPS ゲーム -> ラスタライズグラフィック性能向上というサイクルに陰りが見えています.

Intel や NV は結局は rasterizer グラフィックスの置き換えを狙っているような感じがしますが、
それじゃうまくいかないだろーなー、と思っています.

さて、そうなったときにレイトレが進む道はどこか?

ここはレイトレでしかできない、新しいレイトレグラフィックスマーケットを新しく考えるのがよいと思います.
よく経営的なところでブルーオーシャンとか破壊的イノベーションとか言われているやつですね.

具体的なネタはまあ明かせませんが(competitor が増えると困りますからね 😉 )、
我々レイトレでしかできない、新しいレイトレグラフィックス市場を開拓すべく、いろいろ動き始めています.

The effect of importance sampling

In this post, I’d like to let you know the power of importance sampling.

First of all, see the images rendered with importance sampling and without importance sampling when choosing random ray direction.

(Path tracer with importance sampling)

(Path tracer without importance sampling)

Both use same the number of samples per pixel, thus the rendering time are identical for both images.
But you can see much more visual noise in the non importance sampled image.

For the image with importance sample, I’ve drawn the samples according to the following probability function,

(i.e. generate samples proportional to cosine attenuation)

to generate random ray direction.
This importance sampling technique is widely used in many G.I. renderer.

For non importance sampled image, I’ve used following naive probability function

(i.e. uniformly sample point on the hemisphere)

to generate random ray direction, then multiply cosine attenuation to the contribution.

Why so different?

Let me briefly explain why so the result image is different with and without importance sampling.

Importance sampling for the light integral.

Mathematically, Things what I’ve did in the above importance sampled image is reduced to computing the following integral.

(w_i is sampled with the PDF function p(w) = cos(theta) sin(theta) / PI)

Imagine if L(w) was always 1(e.g. uniformly lit sky), then the result of the integral become

(1 + 1 + 1 + … + 1) * (PI/N) = PI,

for any random number and for any N(# of MC samples).

The light integral with ordinal sampling.

On the other hand, The case of non-importance sampled image is formulated as follows.

(w_i is sampled with the PDF function p(w) = sin(theta) / (2 PI) )

Again imagine if L(w) always returned 1, then the integral will give

(cos(u0) + cos(u1) + cos(u2) + … + cos(uN)) * (2 PI / N) =
(0.34 + 0.56 + 0.90 + … + 0.12) * (2 PI / N) ~= PI

which is nearly equal to PI when N goes large, but not exactly goes to PI as in the importance sampled case.
There’s variance(error) in this case.

Conclusion

As a conclusion, the reason why 2 images are so different is due to the variance of cos(theta).
The variance of cos(theta) turned into more visual noise in non-importance sampled image.

Caustic Graphics ray traced global illumination demonstration

(via Twitter)

Caustic Graphics ray traced global illumination demonstration
http://www.pcper.com/comments.php?nid=7801

おー、Caustic でパストレっぽいこともできるのね.
ただ、パフォーマンスはちょっと微妙な感じ.
2M ~ 10M rays/sec くらいという感じかな.
ただ、実際の製品のパフォーマンスの 1/10~1/20 と言われている FPGA で動かしてこのレベルということであれば、まあ妥当な数字かもしれません.

しかし相変わらずいつもビデオでデモしているときの場所が大学の研究室っぽいのはなにか狙っているのだろうか.
アジェンダが、ホワイトボードに手書きだし 🙂

でもこれで $10M くらいレイズしているんだよなー、うらやましいぜ!

Review of Cloudy: From the perspective of a renderer writer.

I’ve watch the Cloudy(Cloudy with a chance of meatballs) and I’d like to give visual impression from the perspective of a render writer.

Overall, Cloudy was beautifully rendererd compared to previous motion picture Monster-house(Both used same renderer).

There’s no visually recognizable Monte-carlo noises in Cloudy
(noise in global illumination, noise in motion blur, etc) even seen though on the IMAX quality(4k?) screen.
It’s perfect. I’ve convinced raytracing-based renderer is now practical!

Motion blur

Motion blur would be the one of the biggest challenge in Cloudy, because rendering motion blur effect in raytracing-based render requires a lot of time to render(sometimes 10x than still images).

I cannot see any visual Monte-carlo noise(which is one of the biggest artifact in raytracing-based renderer).
I think they did well on rendering beautiful motion-blur effect.

G.I./Raytracing

There’s no G.I. noise in Cloudy, awesome!
But I could see perfect reflection and refraction effect(glass material), which sometimes gives distinct appearance compared to characters and buildings(toon-like appearance).

And… I have to say there wasn’t no caustics effect onto the table from the Cognac glass in the restaurant scene.
(I know its OK, because the table are self-emitted).

Hairs

Rendering hairs are also one of the most challenging factor in Cloudy.
Hairs was rendered beautifully.
I also couldn’t see any visual artifacts for the hairs(monte-carlo G.I. noise, motion blur noise).

Clothes

I could see a kind of BRDF-based cloth apparance, but overall cloth seems are rendererd with simple appearance model.

Effects(Particles and smokes)

As far as I know, effects are rendered SPIW’s in-house render.
Effects give TOTALLY distinct appearance from characters and environments: it has very realistic appearance.
I think, personally, it’d be better if effects have somewhat toon like appearance like characters.

[Ja]

Cloudy を観てきました.

ストーリーは、私はアメリカナイズされたアニメものは Pixar 作品ですら好まないので「へー」という感じでしたが、
子供が観たらいろいろ楽しいのかも.
まさかあそこまでのフードディザスタームービー(食べ物災害映画)になるとは！

さて、期待のレンダリングの出来ですが、、、
モーションブラーも G.I. もヘアーもよくできています。
IMAX 3D で観てきましたが、あれだけの解像度でも視覚的なモンテカルロノイズはまったくありませんでした.
(逆に奇麗すぎてもうちょっと映画特有なフィルムノイズ的なものとかあったほうがいいのでは、と思うくらい)

「あー、やっぱりもうレイトレレンダラでいいんじゃね？ってかこれからはレイトレレンダラっしょ」

そんな感じですね. もうここまでレイトレベースでクオリティ出るなら、　REYES の時代は終わりに近いんじゃないかなー.
(レンダリング時間が解決されれば)

ただ、いかにもレイトレなエフェクト(窓やグラスの反射や屈折)はいかにもレイトレ！って感じで、
ちょっとキャラクターや背景と比べて浮いている感は否めませんでした.
glossy 反射やフロストグラス的な表現があるとよかったかも.

あとはパーティクルと煙も、ちょっと浮いている感じでした.
パーティクル系は別途のインハウスレンダラを使っているとのことなので、そのせいなのかもしれませんが、
もうちょっと各エフェクトとキャラクターの質感との間で「なじむぞッ！！」感を出すとよかったのでは。

あとはレストランシーンで、ワイングラスからのコースティクスが無かったのが気になりますねー.
テーブルが発光するようなもののように見えたので(テーブルにライトが埋め込まれている)、
だからコースティクスが無いだけだったのかもしれませんが.

エンドクレジットにて、レンダラ野郎を確認しました。
顔ぶれはほとんど変わっていませんでしたね。

Watching Cloudy gathering 9/19(Sat)

せっかくなんで、某スタジオの某レンダラの出来を確認するのを裏の目的として,
Cloudy(くもりときどきミートボ－ル) 鑑賞オフをしたいと思います.

N 年の歳月を費やした? モーションブラーの出来はどうか！ヘアーの出来はどうか！
ぜひともご確認ください.
観賞後、ご意見あれば直接某レンダラ開発チームにレポートしますんで 😉

時間と場所ですが、
9/19(土) １０９シネマズ川崎 IMAX シアターになります.

残念ながらまだスケジュールは決まっていないようです。
また、インターネットからの予約も３日前からしかでません。

上映時間は夕方あたりを選択して、観賞後は(勝手に)某レンダラの出来を語る懇親会にしたいと思います.

参加希望の方は以下の URL にて、参加表明をお願いします.
http://atnd.org/events/1542

おまけ

109 シネマズ川崎で、ちょうど今、ダークナイトも IMAX 上映してます.

aobench was ported for various parallel framework

Recently, aobench has been parallelized by various parallel framework.

I think this is a significant leap for aobench.
I mean, aobench become a good practical example to see the performance if it was paralellized by (your) parallel framework.

OK, I’d like to show 3 results done by each parallel frameworks so far.

Java’s parallel utility

Firstly, hopson paralleized aobench by using Java’s parallel utility java.util.concurrent.

http://hopson.web.fc2.com/aobench/java/

He also refactor Java version of aobench to run much faster than existing Java version of aobench.

VS2010’s parallel_for

Secondly, hiroyuk parallelized aobench by using VS2010’s parallel_for and he reported he got almost linear performance gain on the quad processor. And, he reported how he did it at CEDEC 2009(A game conference in Japan).

http://www.4gamer.net/games/032/G003263/20090903008/screenshot.html?num=010

OpenCL

Lastly, aobench was ported to OpenCL platform by kioku, then Nickolay made a good site to manage various OpenCL implementation of aobench.

http://code.google.com/p/aobenchcl/

I’ve heard that OpenCL version of aobench was used widely to measure the performance of your Mac, and your CPU/GPU.
And I’ve found a OpenCL aobench result on GTX285.

http://www.barefeats.com/opencl.html

aobench on GTX285 runs at 40fps, which is about 40x faster than CPU(2GHz C2D), Wow!

Conclusion

This is just a first step. There are still many parallel framework in the world.
I believe many people will parallelize aobench using various parallel framework in the future!

Don’t miss the news from http://twitter.com/aobench!