サーバ更新

この開発日記や wiki などを立てている、自前のサーバをアップデートしました。 いままでは非常に非力なサーバだったため、movabletype で投稿しようものなら 3 分ほど待たされたり、 mediawiki も trac もまともな速度で動きませんでした。 その問題も今回のサーバアップデートによりこれからはなくなりそうです。 また、これを機に blog ソフトを、もう movable type で苦労したくなかったので、 ますおさんも使っておられる WordPress に変えました。 海外では movable type よりもシェアがあるようですね。 movable type からの移行は、今回は特に問題なく移行できました。 しばらく落ち着いて安定した稼動を確認したら、trac などを入れてみようと思います。

デイライトを HDR に書き出す機能を追加(Added the function which exports the sunsky simulation result to a .hdr image.)

デイライトシミュレーションの結果を .hdr に書き出す機能を付け加えました(revision 156)。 http://lucille.atso-net.jp/svn/angelina/sunsky/ angular map 形式で書き出しています。 (半球上、つまり地平線より上の部分しか計算されないので、下側は真っ黒になります) このようにしておけば、他の HDRI 対応のレンダラとかに読み込ませて HDR ライティング(環境ライティング) に使うことができるので、lucille との比較にも使えます。 (太陽そのものの光源は含んでいません) 実際に lucille に組み込んで使うときにも、内部で前計算によりテクスチャに展開しておき、 環境マップライティングをする、というアプローチになるので、そのテストも兼ねています。 まだ生成されたマップを HDR ライティングとしてレンダリングして試していないので、 ちょっと間違っているかも。 しかし、画像だけでも確認しようと結果の .hdr を見ようとしても、ダイナミックレンジが高すぎて、 あまりちゃんと表示できる hdr viewer がありません。 (白飛びしたり、真っ黒になってしまったり) やはりちゃんとトーンマッパーを実装しないとダメだという必要性を感じました。 ということで、トーンマッパーを実装すんべかな、と web を調べていたら、 wikipedia の解説が結構まとまっていて充実していたのでちょっとびっくり。 http://en.wikipedia.org/wiki/Tone_mapping しかもそこのリンクにある、 PFStmo というほとんどのトーンマッピングの論文の手法を実装したソースコードも! PFStmo :: tone mapping operators http://www.mpii.mpg.de/resources/tmo/ 外部から呼び出せるし、これでいいじゃんと思いましたが、 出来れば勉強のためにも、 Ashikhmin あたりの簡単なものを自分で rockenfield に実装しなおそうかと思います。

デイライト実装(An implementation of sunsky model)

A. J. Preetham, Peter Shirley and Brian Smits, “A Practical Analytic Model for Daylight“, Siggraph 1999, pp. 91-100. http://www.cs.utah.edu/vissim/papers/sunsky/ を、レンダラ王 shinji さんに感化されたので angelina に実装してみました。 http://lucille.atso-net.jp/svn/angelina/sunsky/ いつもどおり、win32(cygwin), Mac OS X(PowerPC), linux でコンパイルできる、 fltk + OpenGL なアプリです。 Windows 用には、すでにコンパイルされたバイナリ sunsky.exe を置いておきました。 この論文が提案しているデイライトのモデルは、 大気効果の計算をスペクトルで計算しているため スペクトルレンダリングの手始めにちょうどよかったのと、 テストレンダリングでとりあえずレンダリングするときに、 明示的にライトを生成しなくとも見栄えのする照光環境が 作り出せるので役立ちそうだったからです。 論文のあるリンク先にはソースコード例もありますが、ちょうどスペクトルデータを計算する ところの部分に関するソースはありません。 http://www.cs.cmu.edu/afs/cs/user/ajw/www/software/ こちらのほうには、スペクトルを計算するコードも補完された実装コードがあります。 (ちなみに、他には、yafray などの実装のようにスペクトルではなく RGB で近似して 求めるようにしているのも見受けられます) 今回は、スペクトルの計算はContinue reading “デイライト実装(An implementation of sunsky model)”

The Halfway Vector Disk for BRDF Modeling

Dave Edwards, Slolmon Boulos, Jared Johnson, Peter Shirley, Michael Ashikhmin, Michael Stark, and Chris Wyman, The Halfway Vector Disk for BRDF Modeling, ACM Transaction on Graphics, vol 25(1), 2006. http://www.acm.org/tog/ 新しい経験的 BRDF(emprical BRDF. 解析的な式で表せる BRDF) の提案です。 特徴は、 o エネルギー保存則に従う o インポータンスサンプリングが可能 o ディフューズ、スペキュラー、レトロ反射を統一して扱える o 計測 BRDF のデータフィッティングにも使える(この場合エネルギー保存則は必ずしも成り立たない) です。 コンピュータグラフィックスで使われる BRDF は、大きく分けて 2 つあります。 o 経験的Continue reading “The Halfway Vector Disk for BRDF Modeling”

Coins: 並列化コンパイラ向け共通インフラストラクチャ

http://www.coins-project.org/ こんなシュゴーなコンパイラプロジェクトがあったのですね。 知りませんでした。 SIMD 化などの各種最適化や、OpenMP 化などの並列化など機能もすごいことながら、 プロジェクトメンバーもすごいです。 lucille をこれでコンパイルしたら自動でスレッド化、SIMD 化されて パフォーマンスがあがりそう。時間をみて試してみたいと思います。 SIMD 化では今のところ x86 SSE のコード出力のみが行えるようです。 gcc も 4.2 でついに OpenMP 対応(4.1 でプレビュー対応)するようです。 http://www.atmarkit.co.jp/ad/itanium/DDJ0512.html 自分でスレッド化しなくても、フリーのコンパイラでも勝手にスレッド化、 SIMD 化 してくれるようになってきているのですね。コンパイラの進化ってすごいなぁ。

Symposium on Interactive 3D Graphics and Games 2006

Symposium on Interactive 3D Graphics and Games 2006 の採択論文が公開されたようです。 Paper pdf links by Ke-Sen Huang. http://myweb.hinet.net/home7/hks/Papers2006/i3d2006Papers.htm I3D は基本的にリアルタイム系ですが、 脱リアルタイムなレンダリングにも 通じるテクニックもあると思いますので、 面白そうなものがあれば紹介していきたいと思います。 まだ詳細には読んでいませんが、 Variance Shadow Maps (デプス値ではなく、デプスの分散を保持することで、 シャドウ境界をきれいに表現するシャドウマップ法). Abstract Shade Trees. (アーティストがシェーダ言語をいじらずともより直感的にシェーダを作れるらしい) View-Dependent Precomputed Light Transport Using Nonlinear Guassian Function Approximations. (wavelet や SH ではなく、ガウス関数を用いる all-frequency lighting。 係数データも少なくてすむらしい) あたりが興味深そうです。 — そろそろ 2006 年の CG 学会の採択論文がぞくぞくと公開され始めてきます。 今年も相変わらず年間 1,000Continue reading “Symposium on Interactive 3D Graphics and Games 2006”

スペクトルフォーマット(Spectrum Data format proposal)

何気にスペクトルフォーマット形式でデファクトスタンダードのものってなさそうだなぁと 思い、 オープンなスペクトルデータフォーマットを提案するのもよいではないかと思っています。 HDR フォーマットもそうですが、 実際にスペクトルを保存するとしたところで、中身は技術的 にたいしたものではないはずです (HDR はピクセルデータを浮動小数点にたものだし、 スペクトルなら各波長のデータを保持したものですし)。 よって、 ここで日本発のデファクトスタンダードを確立しておくのもよいと思うのです。 まずはフォーマットの名称を考えてみました。 その名も OpenSPW(Open Spectrum and Wavelength data format)。拡張子は .spw。 OpenSPW を制定する組織は SPW Foundation になることでしょう。 … … やべぇ、もう SPW 以外に思い浮かばねぇ。

マクスウェル方程式(maxwell equation)

maxwellrender が(順調に?)リリース延期のところを見ると、 今が追い越せ追いつけのチャンスだと思い、 スペクトルレンダリングについて 調査を進めています。 そもそもマクスウェル方程式ってそもそもなんじゃらほい? ということで、 電磁気学(少なくともマクスウェルの方程式の意味) を勉強する必要を感じました。 手元には、 Max Born の「光学の原理」 http://www.amazon.co.jp/exec/obidos/ASIN/4486016785 という、たぶん光学ではバイブルであろう 書籍があり、 これにもまず最初にマクスウェル方程式について記載されています。 しかし、いきなり電場 E が… rot が… というくだりで天下り的に記述されていて 正直参考になりませんでした。 いろいろ探してみたところ、 下記が入門として参考になると思い購入してみました。 竹内 淳 高校数学でわかるマクスウェル方程式―電磁気を学びたい人、 学びはじめた人へ ブルーバックス http://www.amazon.co.jp/exec/obidos/ASIN/4062573830 かなりわかりやすく解説されていると思います。 読んでいて、そういえば電気、磁気は高校時代の物理でもやったなぁー、 と思い出し、もっとマジメにやっておけばよかったと反省してしまいました。 しかし、これを読んでマクスウェルの方程式を理解したところで、 マクスウェル方程式そのものを解くのは一般的すぎますし、 レンダリングへの利用では、 各種光学現象を表現するために波長や位相の変数を レイに付加する程度であとは幾何光学の問題として多くは解決できそうですから、 マクスウェル方程式(や電磁気)そのものをレンダリング内部で扱う必要は出てこないであろうと、 今のところ思っています。 光は電磁的な性質を持つ -> 電磁気が満たす条件はマクスウェル方程式で支配される -> マクスウェル方程式を知っておくべき、 という感じで知識として心に留めておく程度で 十分ではないでしょうか。 ところで、G.I. レンダラの作成ほど、 小中高校までの算数数学、 小中高校までの理科物理で学んだ知識が そのまま応用できるものは無いのではないかと思います。 小学生のときにやったプリズムやルーペで黒紙を燃やす(Caustics,Continue reading “マクスウェル方程式(maxwell equation)”

Lustre

「ハリー・ポッター」シリーズに投入されたLustre http://www.itmedia.co.jp/enterprise/articles/0601/06/news032.html レンダーファームにおけるストレージ問題に関する記事です。 SIGGRAPH で出会ったレンダラ野郎たちも、 レンダリング時間もそうですが、膨大なファイル処理も問題であると言っていました。 そのため、なるべくサーバからフェッチするテクスチャデータなどのファイル量/回数を減らし、 レンダリングノードの HDD にキャッシュさせるなどしているとのことです (しかしこのキャッシュだけでも数百 GB くらい使うらしい…)。 単純にレンダラを作るだけでなくて、これらレンダラとの I/O インターフェイス周りも 考えてレンダラを設計していかないとダメですね。