Syoyo Fujita's Blog

raytracing monte carlo

Month: June, 2009

AOV interface in RMan

RenderMan、またそれに限らず他の最近のレンダラでは AOV(Arbitrary Output Variable) と呼ばれる、
任意のレンダリング画像の各要素を出力する仕組みがあります.

この機能を使うと、rgb, alpha, z, それ以外にも specular などの画像要素だけを出力することができます.

特に RMan 系はもうなんでもあり!なインターフェイスになっています.

http://wiki.aqsis.org/guide/aov

http://www.fundza.com/rman_shaders/secondary_images/index.html

RMan 系はシェーダ引数の output 変数でどのデータを書き出すか指定するようです.

この利点はシェーダを書けば何でも出せるところで、
欠点は「スペキュラー」要素など、シェーダコンパイラ側(レンダラ側)では判定できないようなコンポーネントを出せないところでしょうか.

ただ、3Delight とかはスペキュラー要素を出すことができるらしい.
たぶん predefined された shader のみとかで、それにはすでにどの要素がスペキュラーかアノテーションが入ったものになっているのではないでしょうか.

レンダラ側としては、「シェーダであとはよろしく、何でも出せるよ」というのは実装するほうは楽でいいのですけど,
せっかくシェーダコンパイラを書いているので、独自の構文解析を加えて「ここはなんだかスペキュラーっぽいぞ」と自動判定する仕組みを作るのも面白いかも.

Advertisements

lucille fansite

mixi に lucille のコミュニティができたらしい.

http://mixi.jp/view_community.pl?id=4372692

ありがたいことです.
が、残念ながら私は mixi をやらない(できない)ので参加できません…
ので, 立ち上げた chiyama さんを lucille 神の代弁者として 🙂 いろいろお任せしたいと思います.

その代わりというわけでもありませんが、
オフィシャルのほうでも、現在いろいろとコミュニティ立ち上げを企画しています.
こちらもお楽しみにしてもらえればと思います 🙂

これからの時代、ソフトウェアやサービスの普及は、
コミュニティの運営がうまくいくかどうかにかかってくると思います.

lucille は、他にはない GI レンダラとしての機能を提供していくこともそうですが、
うまくコミュニティも形成していくことで次世代のデファクトスタンダードを確保し、
レンダラ帝国やレンダラ財団を作っていけたらと思っています.

Investigation on next-gen scene file format.

新しいことをやるなら、せっかくなのでいろいろ提案したい.
そこで、次世代のシーンファイルフォーマット(主にレンダラ向け)はなにがいいか、
最近いろいろ考えています.

要求としては、

– シンプルかつ拡張性がある
– 人間が読めるものである(XML は論外)
– なるべく既存のものと互換性がある
– 大規模データ、また DelayedReadArchive, Procedural のようなものが扱える

になるでしょうか.

今の所のところの候補は 2 つ. Python と JSON(JavaScript) です.

Python as a scene file format

Python は Gelato でシーンフォーマットとして採用されていましたね.
Python プログラムそのままをシーンデータとして扱うことができます.

利点としては、

– 既存の 3D アプリが Python 対応のものが多いので、ユーザの認知度が高く、知識の流用ができる.
– Python スクリプトなので、動的ジオメトリ生成(procedural)などが容易に書ける.

欠点としては、

– Python インタプリタを含める必要がある(自前で Python コンパイラを作らない場合).
– 特に既存 Python インタプリタを使う場合、大規模データを食わせたときのパースの時間が気になる.
– ちょっと記述の自由度が高く、フリーダムすぎるかな. 何かしら制約は付けたいところ.

が挙げられます.

JSON(JavaScript) as a scene file format

Web の世界では JSON という XML, YAML のような簡単なルールで定義されたデータフォーマットがあります.
これの良い所は、eval() すれば簡単に JavaScript に取り込めることができます(つまりパーサいらず).

シーンファイルとして解釈するばあい、
オブジェクトインスタンス(リファレンス)や、procedural で実行するコードフラグメントも JSON ファイル内に含めることができます.
(リファレンスはリンク文字列で表現できる)

利点としては、

– 記述ルールが決まっているので、自前で高速パーサを書くことも可能. よって大規模データでも対応しやすい.
– 同じく記述ルールが決まっているので、バリデータを書きやすい.
– JavaScript 以外の言語にもパーサが広く移植されている.

欠点としては、

– ベクトル型とか記述できない(基本は文字列、数値、配列だけ)ので、ちょっと書き方が冗長になる(手で書く場合).
- アイテムの区切りにカンマを忘れずに書かなければならない

でしょうか.
JSON は、試しに V8 で動く例を作ってみました(read() を使っているので V8 の shell 上でしか動きません).


// A sample for next-gen scene file format
{
    "name": "myscene.json",

    "camera":
    {
        "eye": [0, 0, 0],
        "target": [0, 0, -1],
        "up": [0, 1, 0]
    },

    "world":
    {
        "polygon1":
        {
            "positions": [1, 1, 0, 1, -1, 0, -1, -1, 0, -1, 1, 0]
        }
    }
}

これを読んで解釈する JavaScript はこんな感じ.


// main.js
var scene = JSON.parse(read("scene.json"))
print("camera.eye = " + scene.camera.eye);
print("camera.target = " + scene.camera.target);
print("camera.up = " + scene.camera.up);
print("triangle.v[0].x = " + scene.world.polygon1.positions[0])

$ shell main.js
camera.eye = 0,0,0
camera.target = 0,0,-1
camera.up = 0,1,0
triangle.v[0].x = 1

どうでしょう? 以外と JSON よさげではないでしょうか.

Play with Blocks(closure in C)

Snow Leopard を待つまでもなく、LLVM/clang を使い, C で block 構文(クロージャ)を使ってみることができます.
(ただし Mac 限定)
Grand Central Dispatch も構文が似ているので、これをベースにした仕組みなのかな?

参考にしたのはこれ.

http://lists.cs.uiuc.edu/pipermail/cfe-dev/2009-June/005378.html

– LLVM/clang を svn から引っ張りだす.
– compiler-rt を $(llvm)/tools に放り込む
– ML に attach されている Makefile も放り込む
– LLVM/clang を make する.

こんな感じのコードを作る.


#include 
int main(int argc, char **argv) {
 void (^helloBlock)(void) = ^{
   fprintf(stdout, "The World! Time stops...\n");
 };

 helloBlock();

 return 0;
}

こんな感じでコンパイル&実行します.


$ clang -o muda main.c -L/path/to/LLVMlib -lBlocks
$ ./muda
The world! Time stops...

おー. しかし現状 Mac でしか動かない(ランタイム側のサポートも必要なので)のが残念ですね.

ただ、gcc でもそのうちサポートされそうな気がします.
(compiler-rt は libclosure ってライブラリをベースにしていて、さほど Apple 独自のランタイムライブラリ群を使っているというわけではないようなので)

Haskell? job AD

haskell_ad.png

おおぉ! Google で Haskell と検索すると Haskell 求人の広告がッ!
しかも Jane Street Capital からだッ!
渋いねぇ〜、まったくオタク渋いねぇ.

… ってか正確には関数型プログラマの求人広告みたいですけどね.
リンク先は基本、OCaml を JSC で使ってますよーってアピールするページになっていますし 🙂

しかし、AD で表示される個数が少ないってことは、
Haskell プログラマを求める企業にはこれはチャンスではないでしょうか?
出せばかなりいい条件で AD 効果が得られるのでは?

我々もお金があればぜひ AD を出したいですね.
(Haskell をこれから intensive に使っていこうと思っているので、Haskeller が必要になっていくのです)

RMS 2.0

ついでに RMS(RenderMan Studio) 2.0 も導入したので,
Maya から RIB を吐いて遊んでいます.

RMS では、File -> Export … で RIB を吐いてもジオメトリだけしか吐かないようで,
Render コマンド(Maya のコマンド)で


Render -r rib input.ma

という感じで maya ファイルを RIB に変換しないとシーン全体をエクスポートできないっぽい.
(しかし Render, コマンドラインで起動すると遅い!… mel コンソール上でやるのがいいのかな)

が、この RIB ファイルがくせ者(?)で, いろいろ PRMan 拡張が入っています.
ResourceBegin/End とか.
またデフォルトで DelayedReadArchive でオブジェクトデータをインクルードするようになっています.
なるべく比較ができやすいようにある程度これら拡張もサポートしたいところですが, どこまでやるかですかねー.
GI 拡張の入れ方とかはどうせ袂を分つことになるので, 完全互換は目指していませんし.

Hagetaka the movie

http://www.hagetaka-movie.jp/index.html

映画版ハゲタカを観てきました.

いやー、良いっすねぇ.

「腐った○○○を….

買い叩く!
買い叩く!
買い叩く!

カコイイ!

ドラマ版との対比がいろいろあったりしてニヤリとする部分が多くあります.

中高生にはこういうのこそ観てもらって, 金融の世界にもっと興味をもってもらいたいです.
(ちょうどストーリーは現実世界の企業やファンドに今起きていることがモデルとなっていたりするので)

TF2 + IMAX

世界最速上映? らしい Transformers2 を IMAX シアターで鑑賞してきました.

感想は,

これ、そろそろ『から○りサー○ス』実写化もいけんじゃね…?
小型昆虫とか, 機械の変形とか, ○○○とか,
これだけできりゃ『から○りサー○ス』実写化の準備としては十分すぎますよね.

いやー、ホント実写化切望します. あ、VFX パートのレンダリングはもちろん lucille で.
だってそのために作っているわけでもあるわけですので 🙂
(単純な金属機械ではない、木製機械のようなオーガニックな質感もレンダリングできるのを目指しているので)

おまけ

上海での巨大一輪車キャラが橋を壊すシーンですが,
左側の建物に手がかすったとき, 予告編だと破壊は起きていないのですが,
本編だと破壊のエフェクトが描画されています.
気が向いた方はチェックしてみてください.

Python in NaCl.

http://lackingrhoticity.blogspot.com/2009/06/python-standard-library-in-native.html

nacl-python-repl-3.png

おー, Python と Python ライブラリが NaCl 上で動き始めたらしい.
ただ os モジュールなどはまだ対応ができていないらしいですが.

ブラウザ上で Python REPL ができています.

iPhone 3GS has NEON instruction!?

According to wikipedia about ARM,

http://en.wikipedia.org/wiki/ARM_architecture

iPhone 3GS has finally NEON instruction!
It’s a quite interesting device for SIMD optiminist(like us)!

[Ja]

iPhone 3GS の ARM にはついに NEON が搭載されるらしい.
NEON とは x86 で言う SSE で、つまりは SIMD ユニット(と C 言語による SIMD イントリンジック関数)の名前です.

今までの iPhone 3G にも SIMD ユニットが無いことはなかったのですが(VFP として知られる),
VFP はアセンブラレベルでしか指定できずに, またプログラムインターフェイスもへんてこなもので,
非常に限られた部分にだけ使うのがやっとでした.

それが NEON になり, x86 での SSE プログラミングと同じ感じで NEON インストラクションを使い,
iPhone 3GS に搭載されている ARM の SIMD パワーをより手軽に引き出すことができます.
しかし手軽になったとはいえ, もちろん最大限の効果を引き出すにはプログラマの SIMD プログラミング力が必要になります.
いかに SIMD パワーを NEON を使って引き出すか.
SIMD 野郎にとってはおもしろいおもちゃになるのではないでしょうか.

また、NEON により iPhone 上でのリアルタイムレイトレも現実的になってきますね!