レイトレ合宿参加レポート

運営をやって頂いているみなさん、参加者のみなさん、どうもお疲れ様でした。そしてありがとうございました。今回初参加させていただきましたが、大変有意義な時間を過ごせて感激です。熱が冷めないうちに、参加レポートとしてまとめておこうと思います。

環境

AWS, c4.8xlargeでのレンダリングになります。Microsoft Windows Server 2012 R2
年々短くなっています。来年は１秒かもしれませんね（白目
AWSのアカウントがあれば気軽にテストできたのがよかったです。

Open Problems in My Little Raytracer

今回が初の試みとのことです。事前のレイトレアンケートをベースにいろいろ語る枠です。個人的にはこの時間が最も大きな収穫だったなぁと思っています。

資料はこちら
http://www.slideshare.net/qatnonoil/open-problems-in-my-little-raytracer

これを見ながらおのおの語っていきます。

インテグレーター

思っていたよりPTの人気が高かったです。

アーノルドはPTだよ？

ブリュートフォースなリファレンスとしてPTが使いやすい、という意見があって、なるほどと思いました。
インテグレーターって論文では使わないんですね、それっぽい用語なんですが。
BDPTが生半可な理解や実装ではバグりやすいため、がっちりしたレンダラーを作るうえでは一つBDPTが正しく実装できるというのは一つ大きなポイントではないか？という意見がありました。これを聞いて次回はBDPTにチャレンジしたいなぁと、気持ちが高まっております。
ちなみに自分も実は一回挑戦してみてはいたのですが、実装がゆるふわすぎてまったく説明できないレベルの理解度の上、間違った実装になってしまっている感じしかしなかったこと、さらに自分の実装では収束がむしろ遅かったので、断念しています。

デノイズ

今一番ホットな分野とのこと。主にプロダクションレンダラーではやはり今最も求められている技術ではないでしょうか。ただ、どんどんいいものが出てくるため、追いかけるのはとても大変なようです。
自分も一応Non-local Means Filterを最後にかけています。というのも**最初メジアンフィルターでお茶を濁せばいいじゃん？**とかおもっていたんですが、思いのほか画像がボケボケに・・・。そんな人にもNon-local Means Filterはおすすめです。案外エッジがはっきりした部分はボケないです。

アドベントカレンダーの記事にもなっています。
http://qiita.com/Ushio@github/items/56a1c34a5a425ab6b0c2

並列化

OpenMPでタイリングして並列でいいよね、という意見が多かったです。自分はMacを使うことが多く、あまりOpenMPには明るくなかった上、なんかマクロが気持ち悪く好みじゃないため、今回はpplを使って行単位並列でした（tbbもよかったのですが、どうせwinだったので）。tbbが最強との声や、C++11のthreadでも十分OpenMPより早いのできるよ、とかの声も。

レイトレにおいては、基本的に最小単位の実行時間にばらつきがありますので、効率的な動的タスクスケジューラーは必須機能だと思います。そうしないと同期のボトルネックが無視できないでしょう。

どっかでちゃんと自分もベンチマークはしておきたい・・・。
でもあまり面倒な制御はしたくないし、ライブラリが十分早いならそれに乗っかって楽をしたいところです。

デバッグについて

やはりみんな苦労しているようです。レイトレのデバッグはやはりかなり高難度な部類だと自分も思います。少なくとも乱数は固定すべきですし、特定のピクセルでブレークする方法はないとつらいです。また、上にも書きましたが、最低でもリファレンスになるレンダラーはあったほうがよさそうです。ゼロ割を検知できる浮動小数点エラーはとても便利とのこと。自分もだいぶ助けられました。

あと、本質的な問題点として、バグがあっても人が死なないのでみんなまじめにデバッグしてくれないという声がありました。Mitsuba Renderにもバグがいろいろと残っているらしいです。
まあ、これからはLightmetricaの時代ですかね。

非正規化数のボトルネック

常識でしょ？という声もありました。でも知らなかった・・・。設定によってはパフォーマンスに大きく差が出るようです。あとで調べたい。

BVH, QBVHについて

３倍速い！という方と、1.25倍しかいかなくない？という意見がぶつかっていました。そもそも正しいベンチマーク方法はどういうものか？というのすら難しいですが、やはり一般的なレイトレのボトルネックはほとんどがレイとシーンとの交差判定を占めることから、ここに大きな熱意をもって高速化について力を注ぐのは理に適っているのですね。まだ自分はQBVHの実装はしたことがないんですが、次回はぜひ投入してレイの数でも圧倒したいところです。ただsimdか・・・面倒だなぁ・・・。自動でやってくれないかなぁ・・・。

Eric Veach氏の論文

Eric Veach氏の論文を読むと、もろもろの問題の答えが普通に書いてある、という声がレイトレ上級者の方には常識のようでした。
http://graphics.stanford.edu/papers/veach_thesis/

自分もこれから読みます。理解が進んだあかつきには解説記事なども書いて行けたらいいですね。
まだまだレイトレ界隈の解説記事、不足気味だと思います。玉石混交はよくはありませんが、それを考えても個人的には絶対数は多いほうがいいと思っています。

大変有益な時間でした。ぜひ来年もこういう時間はほしいです。

セミナー：BSSRDF -理論と実装- Shockerさんより

いや～Shockerさんの講義は大変レベルが高く、概要を把握するので限界でした。でもわからないなりに、空気感や、用語、戦っている問題とその対策などを肌でわずかながら触れることができました。いつか自分も有用な情報を自ら発信できるようになりたいところです。日々精進あるのみですね。
Pocolさんは今回お休みで、リモートでしたので、セミナーが１つ少なかったです。残念！

いろいろ迷子のレンダラー Lost Child Render

いや～もろもろ理論がわからず、四苦八苦しながら作成しました。でもとっても楽しかった。そしてこれからももっと楽しい世界が待っている気がします。
自分の経路はざっくり、

eduptをいじくる
Ray Tracing from the Ground Up
Ray Tracing in One Weekend(3冊）
さらにRay Tracing from the Ground Up
さらにeduptを読む

を主にレイトレコア部分は参照しながら作成しました。
Ray Tracing from the Ground Upが紙でしたので、Google翻訳アプリで撮影してヘルプしてもらったのは内緒です。

発表のときのスライドはこちらです。
http://www.slideshare.net/ushiostarfish/lost-child-render

ソースコードはこちら
https://github.com/Ushio/lost-child-render

来年はBDPTにチャレンジしたいなと、妄想だけ広げている次第です。

シェーディングノーマルをどうしたものか悩んでいたんですが、
結局実装のめどが立たず、その弱点があまり目立たないようにシーンを作ることにしました。
※前述のEric Veach氏の論文に対処方法が載っているとのこと

ちなみにまだMISの計算にバグがあります。
どうやら、MISで混ぜてもよいのは、同じ長さのパス（積分の次元が同じパス）同士のみのようです。ここもEric Veach氏の論文に書いてあると教えていただきました。ありがとうございます。

そんな問題だらけのレンダラーでしが、
今回はなんと！５位に入賞して景品をいただきました！ありがとうございます！

景品は「水レンズでわかる目のしくみセット」です！
なんと解説書付き！自分のレンダラーも解説書がないとだめかもしれませんね。
これで勉強して来年も頑張りたいです。

ではまた！