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 rayContinue reading “OSL(Open Shading Language)”

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 の定義を二回のコールに分けて対応とかできなくはないですが、 そのような処理をエクスポータなどに書くのは面倒くさいですよね.Continue reading “RtInt and RtFloat have enough precision there days?”

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] いろいろな意味で、レイトレグラフィックスエンジニアを本格的に教育して増やして雇用を生み出して、 レイトレグラフィックス経済圏を作り出していく必要がだんだんと出てきました. ってゆーかオレらだけでは近い将来のレイトレ需要を吸収できなくなりそうってだけなんですけどね :-) まあレイトレグラフィックスの流れは確定的なのでその世の中の動きは歓迎なのですが、 問題は、将来は絶対に(特にリアルタイム方面で)必要になるのが分かっていても、 今はまだ十分に必要とされないのでどれくらいの需要を見越せばよいか予測が困難. 教育には時間がかかるので、今からやらないと間に合わない. しかし今はまだそれほど必要とされていない(認知されていない)職業なので、 教育のための資金などをどっかの金持ちから集めたり、レイトレエンジニア志望を募ったりするのが困難. どうしていったらいいでしょうかね… ま、まずはできることからになるわけですが、かといって草の根的にやるのは時間もかかる. もっと体系的で効率的な方法を見つけなければならない. で、そんなことを考えていても時間は過ぎ去っていくわけで、、、 今のタイミングでレンダラ財団があれば! レイトレエンジニアも育てやすかっただろうになぁ.Continue reading “How to educate (realtime) raytracing engineers to prepare for future demands?”

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 機構のサポート).Continue reading “Go procedural | Houdini campaign”

レンダラインターン

学生さんにとってはもうすぐ夏休みですね. 最近は、レンダラインターンを実現できないかなぁと考えています. ちょっといまからじゃ今夏の募集をするには遅いかもしれませんが… 学生がインターンをするメリット – 世界最高峰のレンダラ野郎とともに、世界最高のレンダラ技術を得られる(盗み見られる) (まあ少なくとも、日本の大学で教えているものよりははるかにまともなものになるでしょう) – 世界のレンダラ研究者、レンダラ実務家(非常に貴重な品種!)とのコネクションを得られる 我々がインターンを受け入れるメリット – 低コストで若い人の貴重な時間を手に入れることができる – レンダラビジョンの浸透 🙂 – レンダラ技術者雇用の創出(長期的に. すぐには難しいかもしれないけれど) – レンダラ帝国、レンダラ財団設立のためのステップとして、まずはレンダラ人口を増やすためにも必要. もちろん、インターンにもデメリットがあります. – 若い貴重な時間を拘束するので、ミスマッチがあったときに大きな時間的ロスをする. – そのような貴重な時間であるのに、低報酬に甘んじなければならない  - 本来であれば適切な報酬が支払われるべきであるのですが… これは我々がもっと頑張ってそうできるようにしないといけません. あと、問題は日本に(まずは日本人優先です)、これからレンダラ野郎として成長していきたいと思っている学生の方がいるかどうか. まあ 「レンダラ野郎同士は惹かれ合う」 ということわざがありますから、以外とマッチングはしやすいのではないかと思っています.

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; CiContinue reading “Poor shader optimination in PRMan”

Adaptive sampling in RenderMan?…

そういえば、RenderMan にはアダプティブサンプリングの指定って無いですね. PixelSamples はすべてのピクセルに対して同じ数のサンプル数を指定します. 一応、 PixelVariance というコマンドがあるのですが、あまり使われていないようです. http://lucille.sourceforge.net/blog/archives/000206.html 実際、私もいくつか聞いた限りですが、固定サンプル数でレンダリングを回していたりするそうです. すこし adaptive sampling しない理由を考えてみました. – Refinement の基準に「絶対」というものがないので、品質を上げようとするとアダプティブサンプル数のトライアンドエラーの時間がかかってしまう. – アニメーションを考えると、エッジ部分のサンプル数がフレーム間で増減したりなどでポッピングとかおきて問題になりそう. – サンプリングパターンが固定だと、コンポなどの合成時に便利 – REYES アルゴリズム的に sampling のコストが低いので固定でも以外といける(ShadingRate のほうが影響が大きい) というわけで、最終レンダリング時は固定で、プレビュー用はアダプティブを使ってレンダリングを高速化することも、 という感じの用途になりそうでしょうか. とくに RenderMan 系は. ついでに言うと、某レンダラはコンポのことを考えて、 ピクセルフィルタもボックスやテントなど、あとで加工、合成しやすいものしか使っていないそうです.