Syoyo Fujita's Blog

raytracing monte carlo

Month: October, 2008

Full CG movie | BIOHAZARD:Degeneration

http://www.biohazardcg.com/

ひょんなことから、フル CG 版のバイオハザードを、CG 野郎と観てきました.

ゲームがベースで、日本発で、フル CG というと、FF the movie 以来ではないしょうか?

映像の CG の質は、、、まあ予算もハリウッドほどはないでしょうから、
予算の割には良い出来だったのではないでしょうか.

ただ、観に行ったときは結構盛況でしたし、聞く所によると他の日もかなり盛況だったとか.
2 週間限定というのが悔やまれます.

回し方(予算/出来の費用対効果、プロモーション、脚本)をうまく考えれば、
日本の CG 映画もこれから発展してうまく経済が回っていくのではないかと思いました.
(ちょうど今はサブプライムショックでハリウッドも減衰していきそうですし, 今がチャンスではないかと思っています)

技術的には、見た目はリアル指向で作られたんだろうけど、なにか映像に深みが足りないのが気になりました.
やはり GI か!?
髪の毛の影が無いときとかあったしね.
そこを lucille で解決すれば、きっとぐーんと良くなった、に違いない.

でも実のところ、予告でやっていた、「地球が静止する日」の物体が粉になっていく効果が一番印象的でした 🙂
http://www.apple.com/trailers/fox/thedaytheearthstoodstill/

すげーなこの壊れていく効果、どうやってんだろ.

What happened to VW?

chartgfx.jpeg

VIX が 90 近くまでいくわ、日経はバブル後最安値を更新するわ、
またまた金融方面は毎日がお祭り状態でしたが、これはすごい.

独VW株が急騰=時価総額で瞬間世界一に
http://www.jiji.com/jc/c?g=int_30&k=2008102900010

フォルクスワーゲン再び天国へ(資料)(追記しました)
http://www.doblog.com/weblog/myblog/58476/2621918#2621918

独VW株、2日で4・5倍 相場操縦の疑いも
http://www.47news.jp/CN/200810/CN2008102901000096.html

簡単にまとめると、こんな感じらしい.

10 月中ごろにリーマン破綻の余波を受けて VW を空売ってた
ヘッジファンドのポジジョンクローズから、最初の踏み上げが起きた(上の図にはのってない).

で、他のヘッジファンドが空売り参戦(400 あたりのとき. このとき欧州一の時価総額?)、
10/27 までに 200 くらいまで下がってよしよしというところに、
ポルシェが「VW 株式の取得オプション行使するよ、75% 取るよ」 と声明.
で、他のヤツらの VW 株保有分とか含めると、浮動株は 10% もないみたいで、
空売りしてたヘッジファンドは買い戻す株が無くなったので慌ててポジションクローズ…

を試みるがしかし、そこにまたさらなる他のヘッジファンドがチャンスと(二番目のヘッジファンドをハメるために)買いまくり、
二番目に参戦したヘッジファンドとかが踏み上げられ、めでたく一日(10/29)で 2.5 倍もの昇竜拳で一時 1,000 突破.
時価総額が一時世界一に.
そして、たぶんいろいろヘッジファンドが飛んだ.

今回の事件(?)で、ヘッジファンドたちは 18 億ポンド(=およそ 3,000 億)の損失を被ったらしい.

Hedge funds make £18bn loss on VW
http://news.bbc.co.uk/2/hi/business/7697082.stm

そして現在, 500 くらいまでに急落、
いずれにせよ今回の件で VW 株の割合が DAX 指数の大きな部分を占めるようになってしまい、
パッシブ(インデックス)運用しているところ(年金基金とかなので、まわりまわって我々のマネーも含まれている)の
機械的売買も発動して、状況はカオス的な状態に…

しかし、なんともすごいイベントでした.
曲がりなりにも一度は世界一の時価総額を付けるほどの規模の株なのに、こうも荒れるものなのですね.
まあ 35 兆円(浮動株だけを考えれば実質動いたのは 3 兆円くらい?)なんて、
いまの世界中のじゃぶじゃぶマネーフローなら簡単に食いつくしてしまうのかもしれません.

おまけ

世界の株価が大きく下がっているいま、そろそろレンダラ財団の資産運用ビークルになる
レンダラファンドを立ち上げる時期に来たのかもしれません.
ただ、個人的にはまだまだ下落は終わらず、 2009 年 ~ 2010 年まで下落傾向は続くと思っていますが、、、
いずれにせよ、バフェットは動いた.
これはひとつの目安として受け取らないと、と思っています.

とりあえず一年くらいは仮想レンダラファンドとして、シミュレーション投資をしてみようかと考えています.

言語メモ

JavaScript のための型推論

JS 実装のために、型(推論)の理論や実装をもうちょっとしっかりやりたいなぁと思っています.
py2llvm で実装した型推論はやっつけだったし.

JS で型推論するのに役立ちそうな情報です.

Type Inference for JavaScript
http://pubs.doc.ic.ac.uk/chrisandersonphd/

世の中やっぱ広いわ。すでにやっているひといるし。
でも、完全な JS に対してではなくて、JS のサブセットに対する型推論.

むむぅ、そもそもまず型推論のルールの読み方から勉強しないとよくわからない…

というわけで、型の本を読んでみます.

Types and Programming Languages
http://www.amazon.co.jp/dp/0262162091/




とりあえず true と false で出来た世界の simply typed lambda calculus あたりまでなんとなく理解.

並列スクリプト言語?…

Erlang VM で動く Python/Ruby っぽい構文で書ける Reia という言語を知りました.
(via InfoQ)

http://wiki.reia-lang.org/wiki/Reia_Programming_Language

ただ、並列処理を行う構文はまだない?それとも自動で並列化?…

構文は(個人的に) Python の気持ち悪いところと Ruby の気持ち悪いところが消えていて、
好感が持てます.


module Bora
  def muda(a)
    a + 3

と Reia では記述できます.

Python の(個人的に)気持ち悪いところ(「:」 が def の末尾に必要)と
Ruby の(個人的に)気持ち悪いところ(end がペアとして必要)が消えてとてもすっきりしています.
ちなみにタブ文字は NG みたいです. インデントするときはスペースで.

そろそろ def も消せるんじゃないかなぁとおもいます.
インデントを見て関数定義かどうか判断することによって.

Rendering with JavaScript

Here’s JavaScript version of ambient occlusion renderer.

http://lucille.atso-net.jp/rwj/ambientocclusion.html

Your browser may notice “proceed or not” because the script does not respond until the rendering finishes.

[Ja]

JavaScript 版のアンビエントオクルージョンレンダラも書いてみました.
canvas を使っているので、safari, firefox, chrome あたりで動くと思います.

レンダリングが終わるまでなにも反応しないので、ブラウザが警告してくると思います. 続けるを選んでください.

Chrome で試したところ、残念ながら AS3 並みに遅いですね…
やはりオレ JS 実装が必要か.

Source code

AO renderer performance. C/Proce55ing/AS3

render_ao_time_graph1.jpg

Proce55ing, AS3 で ambient occlusion レンダラを書いたので、
ついでだから C 版も書いて、まとめとしてパフォーマンス比較をしました.

設定は 256×256 pixels, 2 subsamples, 64 AO samples, Core2 2.16 GHz.

AS3(Flash10 Player) : 56 sec
Proce55ing : 9.7 sec
C(native) : 2.6 sec

Proce55ing 版はプログレッシブにレンダリング結果を表示していてオーバヘッドがあるので、1,2 秒ほど引いて考えるとよい.

概ね以下のようなパフォーマンス傾向になると言える.

– Proce55ing(JVM) は C に比べて 3-4 倍遅い
– AS3 は P5 に比べて 6 ~ 7 倍遅い
– AS3 は C に比べて 20 倍遅い

JVM がネイティブの 3 倍程度しか遅くないというのは注目に値する.
もはや Java = 遅いという概念を捨てるときに来ていると思う.

AS3 はやはり遅いと言わざるを得ない.
AS3 は JS と違ってユーザに型付け+静的コンパイルさせてるのでほぼ Java みたいなものなんだから、
もっと早くてもいいと思うのですけどね.

Rendering with Flash10(ActionScript3)

rwf_ao.jpg

Rendering with Flash (Flash10 is required. It takes a minute to display rendered image)

Since Flash10 has been released, I’ve ported Proce55ing version of simple ambient occlusion renderer into Flash10(ActionScript3) to test the performance of AS3 in Flash10.

In my Core2 2 GHz, the demo runs in 56 sec for 256×256, 256 AO samples/pixel.
Unfortunately, this is about 7 times slow compared to Proce55ing version.

[En]

Flash10 リリース記念ということで、Flash10 の(AS3 の)パフォーマンスを調べるのも兼ねて,
Proce55ing で書いたアンビエントオクルージョンレンダラを ActionScript に移植してみました.
絵が出るまで 1 分くらいかかります(たぶん Flash10 が無いと見れません).

残念ながら、速度は Proce55ing 版の 1/7 くらいでした.
教育目的ならなんとか我慢できるレベル、でしょうか.
ただここから発展させていくことを考えるとやはり Proce55ing に比べてキツいものがあります.
(ActionScript のコードのほうが Proce55ing(java) よりも複雑になってますし. たとえば var x:Type みたいなところ)

ちなみに Flash10 からは Pixel Bender と言って、GLSL のような言語で GPU(?) で
高速ピクセル処理させる機能が付きました.
高速なのはいいのですが、言語としては制約が多く再帰関数とかが使えないなどがあるので、
Pixel Bender でレンダラというのには使えないですね.

Source code

JavaScript 実装、始め…るかも…

JavaScript の実装をしようかな… と思っています.

理由

現状 Maya などの 3D CG のパッケージなどでは拡張用のスクリプト環境として Python が使われるようになっています.

将来を見据えると 3D CG パッケージもどんどん web 化していき、拡張用スクリプティング環境は JS などの web 言語と統一していくことが見込まれます.それに使う言語が統一されていればユーザにとっても学ぶことが少なくていいでしょうし.
(将来のグラフィックス言語は関数型、とは別に、もう少し現実的にあり得る方向性として)

また、3C CG 向けに限らずとも、拡張用スクリプト言語は動的言語(or 動的型付けな DSL)というのが主流になっていくと思っている.

そのとき、JS もしくは動的言語の実装系が非力では困る(すでに Python でも CG 系の演算処理を行うには非力である).

動的言語でも、パフォーマンスを考慮して実装を行い静的言語とほぼ competitive であることを示すことができれば、
CG パッケージの JS 化移行という可能性も十分あり得るようにある.

なぜ動的言語(スクリプト言語)の中でも JS にするか、というのはやはりすでにユーザが多いし参考になる既存の処理系が多いからにつきる.

実装の方向性

通常の JS 実装系とはかなり方向性が異なる.

– 数値計算のパフォーマンスに特化(web 用のたとえば文字列操作、正規表現、DOM 操作に特化ではない). 組み込み用演算スクリプティング環境という位置づけ.
– コンパイルに時間はかけてよいことにする.メモリもいっぱい使ってよい. AOT(Ahead of time)なコンパイルをする.
– LLVM をバックエンドにつかう. 可能な限り静的に最適化されたコードを吐く.
– 完全な実装まではやらない. Prof of concept ができればよしとする.
– JS の仕様バージョンは現在の ecmascript3(ecma-262). ecmascript4 はなんかキャンセルになったみたいだし.

やることの利点

– 動的言語実装のノウハウがつく
– JS ならば他にすでに多くの実装やサンプルがあるので、それらをリファレンスとして検証に使える
– スクリプト言語(動的型付け言語)でも、実行速度に特化して実装を最適化すればどこまでパフォーマンスを出せるかを確かめることができる(SIMD 命令の利用、メモリ最適化を考慮するなど).

最適化の方向性

C に比べて xx 倍しか遅くない! C と同等! V8 より xx 倍早い! というあいまいな比較はしない.
実行したいプログラムの理論値を求め、それと現状の最適化実装のパフォーマンスとの乖離率で最適化の度合いを測る.
(理論値以上の性能は出ないわけですから)

期間

まあレンダラ作成の片手間に、ということなので、いつ終わるかは不明です. 終わらないで途中で辞めるかもしれません.

手始めに

JS および動的言語の実装ってどうすればいいんだろう…
というわけで、手始めに既存の JS 実装を調べてみます.

– リファレンス実装 www.ecmascript.org
ECMAScript4 のリファレンス実装.
コードを眺めてみます…


うわっ、SML/NJ ですか. OCaml は分かるのでなんとなく読めるけど…
しかしなぜに SML/NJ なのだろう. Appel の影響か!?
まあ C++ でも困るけど…
ecmascript4 の実装なので、3.1 に移行することになった今、多くの(?)実装の部分がいらない子になるんだろうなぁ…

– Tamarin
Tamarin(-tracing) は正確には入力としてコンパイル済みの ABC を受け取ってインタプリタ(+JIT)する実行環境.

ABC へのコンパイルは Flex SDK で見つかる.
JS -> ABC へのコンパイラは Java でかかれている.
こいつはなんだかもうでかすぎて読む気がしない.

– V8
C++ なのと、デザインドキュメントがあまりないので、やはりあまり読む and 参考になる気がしない.

– SpiderMonkey
C なのがいいね!構成がすっきりしていて、コメントもあるので読みやすい.

– Narcissus
http://mxr.mozilla.org/mozilla/source/js/narcissus/

JS で書かれた JS エンジン.
全部で 3,000 行くらいととてもコンパクト.
ひとまず実装上の参考にするにはこれが一番ですね.

まとめ

というわけで、既存 JS 実装で読んで参考になるのは Narcissus, SpiderMoneky かな.
それ以外は無理にソース解読するより言語仕様書を読んで理解したほうが早そうだ.

Path tracing with Proce55ing.

rwp_pt.jpg
(Path tracing. Java applet. Java is launched)

Cont. of “Rendering with Proce55ing

I’ve implemented simple path tracer in Proce55ing.
512 paths per pixel, 256×256 in 80 sec. Wouldn’t it fast enough to teach GI in Proce55ing?

[Ja]

簡単なパストレもついでなので「なんかこう、ダダーっと」いう感じで Proce55ing で作ってみた.
球の色が床に付く大域照明効果(color bleeding)に注目.

256×256 解像度、4 subsampling, 128 path samples なので 512 samples/pixel 相当.
これで Core2 2GHz で 80 secs くらいで終わるので、学習用であれば速度は十分と言えよう.
GI を Proce55ing で教えるというはやはりアリだと思う.

いずれ BPT(Bi-directional Path Tracing), MLT(Metropolis Light Trasnport) まで Proce55ing で実装してみる予定です.
そこに加えて反射、屈折、BRDF, 空間データ構造, モンテカルロ基礎までやれば GI を一通りカバーできるかな.

(GI のこんなのも取り上げてほしい、というリクエストがありましたら教えてください)

Rendering with Proce55ing.

rwp.jpg

Ambient Occlusion rendering (Java applet. Java is launched)

[En]

I’ve been planning to write a good introduction to theory and practice of global illumination rendering with literate programming style and seek for good language to implement, teach and learn global illumination algorithm.

And now, I finally found Proce55ing is a good candidate for the language. Although Proce55ing is primary designed for media art programming, I also found it could be enough to implement simple render as well.

Benefit of using Proce55ing.

– It has GUI facility in default. This is very important for renderer newbie.
– It is easy to install. Dowload and just run.
– It is cross platform.
– It is fast enough to execute compute-intensive global illumination computation program.

I investigated many languages other than Proce55ing, but nothing else fits my requirements:

JavaScript: it is widely used in web, easy to program and execute in web, and can be used in conjunction with GUI(html), but unfortunately it is very slow to execute numeric program.
ActionScript(Flash): Same as JavaScript.
C/C++: Fast to execute but it does not have GUI and the code become nasty.
Java: It has versioning nightmare (compiler/runtime version mismatch problem. “Write once, run anywhere” is a Myth!). It is very difficult to make reader/lerner’s language environment same.
Python: Syntax is very clean and easy to learn, but it does not have default GUI and slow to execute.
Other LL language: Has same problem of Python, especially slow to execute.

Rendering with Processing

I wrote a simple renderer which renders the scene with ambient occlusion with Proce55ing.
(Click above link)

You’ll found rendering speed is not so slow.
In my core2 2.15GHz, it finishes about 40 seconds for 256×256, 256 AO samples, 4 subsamples per pixel setting(i.e. 1024 rays per pixel).

Don’t you think Proce55ing is a nice language(IDE) for teaching rendering?

[Ja]

Proce55ing で簡単な大域照明レンダラを書いてみました. アンビエントオクルージョンを計算しています.
上記リンクの applet では視点からのレイがヒットした場合、 ヒット点から 256 rays を飛ばして遮蔽率を計算しています.
4 サブピクセルサンプリングしているので、 1pixel あたり 1024 本レイを飛ばしていることになります.

Proce55ing は基本的にはインタラクティブメディアアートに使われる言語(環境)ですが、
レンダリングアルゴリズムとその実装を初心者に教えるプログラミング環境をずーっと探していたのですが、
最近 Proce55ing がその目的にとても適しているのではないかと思っています.

理由は,

– GUI がデフォルトで付いている
– すぐに使える. ダウンロードして起動するだけ
– クロスプラットフォーム(Win, Linux, Mac)
– 十分な処理速度. Proce55ing は中身は実は Java なので、処理速度は JVM の性能次第になります. 最近の JVM は性能がいいのでネイティブに比べてとても遅いというわけではありません. 特に Java6 からはモダンな JIT 最適化が行われています(参考資料 . とくに Chris Wimmer 氏の修論は必見. SSA + リニアスキャンレジスタアロケーションの JDK6 における practical な実装方法が涙が出るほど詳細に解説されています). 処理速度は大域照明レンダラなどの演算がメインになる計算には重要ですから、ネイティブ同等とまではいかなくても、それなりに早く動くというのは必須用件になります.

なので、取っ付きやすさと実行速度を兼ね備えている点ではベストな教育用言語かと.

取っ付きやすさという意味では JavaScript や Python という手もありますが、いかんせんやはり大域照明レンダリングをするには実行速度が遅すぎました(ただ、いずれ数年後もしくはFlash10 では、 JS などの LL で動的な言語もネイティブと変わらないくらい早くなる可能性もあります. 待てなかったら数値演算に最適化を特化した オレ JS 実装を用意するのもアリ?).

Proce55ing の言語は Java ベースなのでプログラミングの点からちょっと初心者には取っ付きづらいですが(オブジェクトの new の振る舞いとか)、まあ Java ほど複雑ではないし OO 指向も強制ではないので難しすぎるということはないでしょう.

関数型言語で教える?…

ちなみにゲーム屋さんもだんだんと「関数型がいいべ、手続き型や OO 指向は良くない」ということに気づきはじめてきていますね(こことか).
私も 8 年くらい前に OO 指向は実はグラフィックスには必要ない概念(グラフィックスアルゴリズムは struct によるデータのまとめ + 簡単な関数ポインタ程度で十分実現可能)であると分かってからは、なるべく OO 脳に冒されないように注意し(無駄に深かったり多種なクラス階層は保守性が絶望的に低下する)、C++ はどうしようもないとき以外には近づかないようにしています 🙂

これから 5 年 10 年後と時代を先取りして、と考えると関数型言語でレンダラ実装を教えるというのもありかもしれない.

Proce55ing みたいに GUI が標準で付いた関数型プログラミング環境(ただし lisp 系は除く)ってないのかな?

世界恐慌で資産 100 倍!

VIX 70 オーバーって…. すげぇな….

今回も資産暴落により、オプションで価値が 100 倍になったものがあります
(前回: 株価大暴落で資産 500 倍!? )
たとえば 11P90 です(11 月限プット 9,000)

11p90.jpg

9 月初めに 10 円(1 万円の価値)程度だったのが, 10 月 10 日に 1,600 円(160 万円の価値)になりました.
10 月限だと 1,000 倍のものもあったかもしれません.
(限月が来てしまったのでチャートを入手できませんでした.)

しかし、周りでは今回の暴落で損をしているひとしか取り上げないのはなんででしょうね.
確実に今回大もうけをしたひともいるわけですし(前回のサブプライムショックでの例)
暴落 = 大もうけという金融商品があることを知らないだけかもしれません.
financial literacy の向上がやはり望まれます.

ちなみに、株価が動かないと儲かるという方法もあります(ショートストラドル)
要はそれぞれの方向にたいして、それぞれ利益がでる(損が出る)という投資方法があるです.
そのようなことを可能にしたのは、金融工学と金融マーケットの成長のおかげなのです.

おまけ

日経オプションは、最近権利行使価格が 500 円刻みから 250 円刻みになりました.
また呼び値も 20 円までは 1 円単位になりました.
まだまだ使いやすいとはいえませんが(権利行使が 100 円単位くらいにはなってほしい),
一歩づつ日経オプション市場は整備されているといえるでしょう.