Syoyo Fujita's Blog

raytracing monte carlo

Month: July, 2009

OSL(Open Shading Language)

(via Blender to renderman group)

http://opensource.imageworks.com/

Open Shading Language (OSL) is a small but rich language for programmable shading in advanced renderers and other applications. OSL is similar to C, as well as other shading languages, however, it is specifically designed for advanced rendering algorithms with features such as radiance closures, BRDFs, and deferred ray tracing as first-class concepts.

Imageworks からいくつかの OpenSource プロジェクトが公開され、
そのうちのひとつが OSL(Open Shading Language).

オープンな仕様で、レイトレベースで、コンパイラもオープンソースで提供されるらしい.

オープンなレイトレシェーダ言語はこちらも考えていたので、さて OSL がどれくらい使われるようになるかですね.
よい仕様でこれが普及してくれば、OSL にスイッチして lucille に取り入れるかもしれません.
まー、でも C ベースの言語仕様で、またコンパイラが Haskell で書かれていたりするわけでもないので、
OSL はフツーな言語でフツーな実装になりそうなのがちょっと残念かなぁ.
(ま、実際に仕様やコードが公開されてからいろいろ判断しますか)

Advertisements

CUDA for high-school students

高校生のための NVIDIA CUDA サマーキャンプ
http://www.nv-info.com/cuda_for_highschool/

う、正直、「やられたッ!」という感じです. 高校生ですか.
このままうまくいくと若年化が進み、10 年後の小学校では「国語算数理科 CUDA」になりかねないッ!!

というわけで、対抗馬(?)を企画してみました.

中学生のための GI ブートキャンプ

レイトレ、BRDF を活用した物理ベースのレンダリングアルゴリズム「GI」が、今原宿界隈においてナウでヤングであると注目されています。
「GI」を活用することで、原宿界隈でオサレ皇帝(エンペラー)の称号を手にした事例が多く報告されています。
「GI」は難しくてわからないと不安な中学生のみなさんもご安心ください。
すでに GI を活用している現役中学生もいるので、ぜひチャレンジしてみませんか。
我々レンダラ野郎たちは、10 年後の小学校では「国語算数理科 GI」となるような明るい将来を切り拓くべく、学生のみなさんを応援いたします。

… まあ実際のところ、GI の基礎程度であれば中学数学で十分理解できるので、
以外と中学生の段階から GI を教えるのはアリではないかと思っています.
… いや、実のところかなり「アリ」じゃね?
GI 本とタイアップするとなお良いかなぁと考えています 🙂

DJV imaging

http://djv.sourceforge.net/

こんなツールを見つけました.
CG プロダクションむけ画像ビューア & プレイバックビューア.

DJV(だいじょうブイ)と、日本人には非常に覚えやすい名称になっています 🙂

正直、3delight の i-Display のようなよくできたフレームバッファドライバを作るのは面倒なので、
こういうのがあれば「こっちを利用して」、と言ってしまいたい.
lucille 用には今 rockenfield がありますが、まあ機能とかでいったらこの DJV のほうがはるかにいい出来ですしね.
LUT テーブルとかにも対応していますし.
似たようなフレームバッファドライバをがんばってまた作るよりは既存のもので代用して、
レンダラの開発に注力したいというのもあります.

open source なので、lucille から DJV にレンダリング結果をダイレクトに画像転送させる機能とか
追加してコントリビュートしたいなぁ.
あと linux だと EXR の表示がどうもおかしいので、それも直してあげたい.
HDR(RGBE)にも対応していないので、その機能もかな.
ま、ちょっとソース見てみますかね.

おまけ

あと、ESC で終了するのもいいですね. rockenfield も ESC で終了します.
以外と ESC で終了させることができる GUI アプリって無い気がします.
ESC で終了させることができるとオペレーションがすいすいできます.
特にコマンドラインがメインのひとはそう思うんじゃないでしょうか.
そのかわりセーブとかしていないと大変ですが 🙂

RtInt and RtFloat have enough precision there days?

RenderMan の仕様では、整数データは RtInt, 浮動小数点データは RtFloat
で表現され、これらはそれぞれ C 言語でいう int, float に対応しています.

もちろん、RtInt, RtFloat は define されているものなので、
long, double に変えることもできなくは無いのですが、
RIB や DSO などの既存アプリなどとの互換性を考えると
一旦定義してある型を変えることは非常に困難です.

で、int(32bit 整数), float(32bit 浮動小数点)ってそろそろ限界じゃね?ってお話.

まず、RtInt を考えてみましょう.
RtInt はたとえばポリゴンの定義において頂点インデックスの定義などに使われます.

RtInt の場合、2^31 の頂点インデックス数が表現の限界になります.
この数字により表現できるのは、およそ 700 万ポリゴンほどになります.
現在の CG 表現の複雑性を考えると、Polygons, PointsPolygons
で表現できる 1 プリミティブのポリゴン数の限界が 700 万ポリゴンというのは、
そろそろまずいんじゃないか?と思います.もってあと 2, 3 年かな.
まあ Polygon の定義を二回のコールに分けて対応とかできなくはないですが、
そのような処理をエクスポータなどに書くのは面倒くさいですよね.

つづいて RtFloat.

まあシェーディングは float の精度でもまだいけるかなーという感じですが、
ジオメトリデータはそろそろ double でないと精度不足じゃないでしょうか.
特に地形などの巨大シーンを扱う場合.
DelayedReadArchive とか、グリッドで切って分割レンダリングとかで精度を稼いで
対応できなくはないですが、まあそんなワークフローを作るのは面倒くさいですよね.

そんなわけで、lucille は RtInt は long(64bit int)、RtFloat は double にしたいなーと思っています.
ただそれだと他 RenderMan 互換レンダラとの互換性が取れなくなるので、
別 API で long と double を受け付けるものを用意するのが現実的でしょうか.
PointsPolygonsEx みたいな感じで
(うーん、しかし Win32 API みたいで格好良くないですね)

結論

さすがに RenderMan はフォーマットが 20 年前に定義されていることもあり、
いろいろなところで限界が来ています.
今回はその中で精度は足りるか?という話でした.
やっぱいずれは lucille 用に次世代対応な独自フォーマットを定義するようにしたいですね.

solidangle.com

http://www.solidangle.com

For information regarding our products, including the Arnold Renderer,

ほう,,, 実に興味深い.
興味のある方はコンタクトしてみるといいんじゃないでしょうか.
# 私経由でも紹介できますが 😉

How to educate (realtime) raytracing engineers to prepare for future demands?

The future is definitely (realtime) raytracing-based graphics.
But not now. But we have to prepare for it now.
Then the problem arises:
How to educate (realtime) raytracing engineers from now on, to prepare for exploding demands in the future?

[Ja]

いろいろな意味で、レイトレグラフィックスエンジニアを本格的に教育して増やして雇用を生み出して、
レイトレグラフィックス経済圏を作り出していく必要がだんだんと出てきました.
ってゆーかオレらだけでは近い将来のレイトレ需要を吸収できなくなりそうってだけなんですけどね :-)

まあレイトレグラフィックスの流れは確定的なのでその世の中の動きは歓迎なのですが、
問題は、将来は絶対に(特にリアルタイム方面で)必要になるのが分かっていても、
今はまだ十分に必要とされないのでどれくらいの需要を見越せばよいか予測が困難.
教育には時間がかかるので、今からやらないと間に合わない.
しかし今はまだそれほど必要とされていない(認知されていない)職業なので、
教育のための資金などをどっかの金持ちから集めたり、レイトレエンジニア志望を募ったりするのが困難.

どうしていったらいいでしょうかね…
ま、まずはできることからになるわけですが、かといって草の根的にやるのは時間もかかる.
もっと体系的で効率的な方法を見つけなければならない. で、そんなことを考えていても時間は過ぎ去っていくわけで、、、
今のタイミングでレンダラ財団があれば! レイトレエンジニアも育てやすかっただろうになぁ.

今回はタイミング的に実現できませんでしたが、
レイトレエンジニア需要の次にくる (リアルタイム) GI エンジニア需要のときにはそのときにこそ、
レンダラ財団を立ち上げておきたいなぁと思っています.

Go procedural | Houdini campaign

http://www.sidefx.com/index.php?option=com_content&task=view&id=1548&Itemid=66

go procedural と称して、houdini が半額キャンペーンやっています.
これを機会にちょっと Houdini 環境も整備しようかな.

go procedural プロモーションでは、なぜプロシージャルベースの手法が必要か、以下のように述べられています.

CG 業界は爆発的に成長していますが、スタジオは多量の高度にリアルな視覚効果のショットを、
少ないリソースでこなしていかなくてはならなくなってきています.
この爆発的増加を解決するために、多くのスタジオは Houdini を利用したプロシージャルな手法を選択しています.

これを読んで、こんなことを想像しました.

– ユーザの目は越えてきており、高品質で物量のある VFX を作らなくてはならなくなってきている.
-> 人手でそれを解決するには自ずと限界がある
-> よって、モデリングやアニメーションをプロシージャルでやることでその問題を解決しようというのが Houdini の go procedural なのだろう
-> ではそうなったとき、レンダリングはどうなるか?
-> プロシージャルで多量に複雑に生成されたジオメトリ、テクスチャをレンダリングするには高速、高品質なレンダラが必要だ

… というわけで、これからはレンダラも高速、高品質、プロシージャル対応なものが必要とされてくるに違いない!
まあ物量が増えて、求められるクオリティが上がってくるのは間違いないので、その点では go procedural は、
大規模でも高速にレンダリングするという lucille の方向性とマッチしています.

lucille をプロシージャルに強いレンダラにしてみましょうかね.
もちろん、プロシージャル対応はどのような形式になるにしろ、対応は必須となるでしょうが.
(たとえば RIB の Procedural, MentalRay で言う Geometry shader 機構のサポート).

プロシージャルに強い、というのは、プロシージャルのためのインターフェイスを用意するだけでなく、
レンダラ側で、プロシージャル専用言語を用意するとか、プロシージャルコードを Python で書けるとか、
マルチスレッドでもスケールアップしてプロシージャルのコードが動作するとか、
(MR の Geometry shader とかは、明示的にやらないとシングルスレッドコードとして実行されるんじゃないかな?)
Houdini の procedural コード(VEX?)と連携できるとか,
そんなあたりの、プロシージャルを書き、そして実行する部分を効率化することを強化するということになります.

レンダラインターン

学生さんにとってはもうすぐ夏休みですね.

最近は、レンダラインターンを実現できないかなぁと考えています.
ちょっといまからじゃ今夏の募集をするには遅いかもしれませんが…

学生がインターンをするメリット

– 世界最高峰のレンダラ野郎とともに、世界最高のレンダラ技術を得られる(盗み見られる)
(まあ少なくとも、日本の大学で教えているものよりははるかにまともなものになるでしょう)
– 世界のレンダラ研究者、レンダラ実務家(非常に貴重な品種!)とのコネクションを得られる

我々がインターンを受け入れるメリット

– 低コストで若い人の貴重な時間を手に入れることができる
– レンダラビジョンの浸透 🙂
– レンダラ技術者雇用の創出(長期的に. すぐには難しいかもしれないけれど)
– レンダラ帝国、レンダラ財団設立のためのステップとして、まずはレンダラ人口を増やすためにも必要.

もちろん、インターンにもデメリットがあります.

– 若い貴重な時間を拘束するので、ミスマッチがあったときに大きな時間的ロスをする.
– そのような貴重な時間であるのに、低報酬に甘んじなければならない
 - 本来であれば適切な報酬が支払われるべきであるのですが… これは我々がもっと頑張ってそうできるようにしないといけません.

あと、問題は日本に(まずは日本人優先です)、これからレンダラ野郎として成長していきたいと思っている学生の方がいるかどうか.
まあ 「レンダラ野郎同士は惹かれ合う」 ということわざがありますから、以外とマッチングはしやすいのではないかと思っています.

Poor shader optimination in PRMan

あまり使うことはないと思いますが、
以下のような、何もしないけど重いループが PRMan ではコンパイル時の最適化で除去されません(-O2 をつけてコンパイルしたとしても).
(このシェーダを使うと、レンダリングに時間がかかる)


surface
myloop()
{
  float i;
  for (i = 0; i < 100000; i += 1) {
  }
}

一方、3Delight(-O3 オプション有効)はこのループを除去します.
よってこのシェーダを使ったレンダリングは一瞬で終わります.

次に、以下のような Ci にいろいろ代入するけれども、最後の Ci 代入だけが効果がある例.


surface
myshader()
{
    float i0 = 0.0;
    Ci = i0;
    float i1 = 1.0;
    Ci = i1;
    ...
    float i10000 = 10000.0;
    Ci = i10000;
}

Ci = i10000 の expression 以外は DCE(Dead Code Elimination) されることが期待されます.

PRman だとシェーディング処理がそこそこかかります(DCE されていない).
3Delight(-O3 最適化オプション有効)だと一瞬でした(DCE されているようだ)

んー、PRMan のシェーダコンパイラ(やインタプリタ)は、あまり最適化してくれないようですね.

Adaptive sampling in RenderMan?…

そういえば、RenderMan にはアダプティブサンプリングの指定って無いですね.
PixelSamples はすべてのピクセルに対して同じ数のサンプル数を指定します.

一応、 PixelVariance というコマンドがあるのですが、あまり使われていないようです.

http://lucille.sourceforge.net/blog/archives/000206.html

実際、私もいくつか聞いた限りですが、固定サンプル数でレンダリングを回していたりするそうです.

すこし adaptive sampling しない理由を考えてみました.

– Refinement の基準に「絶対」というものがないので、品質を上げようとするとアダプティブサンプル数のトライアンドエラーの時間がかかってしまう.
– アニメーションを考えると、エッジ部分のサンプル数がフレーム間で増減したりなどでポッピングとかおきて問題になりそう.
– サンプリングパターンが固定だと、コンポなどの合成時に便利
– REYES アルゴリズム的に sampling のコストが低いので固定でも以外といける(ShadingRate のほうが影響が大きい)

というわけで、最終レンダリング時は固定で、プレビュー用はアダプティブを使ってレンダリングを高速化することも、
という感じの用途になりそうでしょうか. とくに RenderMan 系は.

ついでに言うと、某レンダラはコンポのことを考えて、
ピクセルフィルタもボックスやテントなど、あとで加工、合成しやすいものしか使っていないそうです.