lucille 開発日記

このページは下 記アドレスに移転しました(this blog has been moved to below address)。

http://lucille.atso-net.jp/blog/

以下は過去の内容です。

Asian Dragon をレンダリングせよ! その2

Asian Dragon を lucille でレンダリングしてみました。

2048x2048 ピクセル、2x2 アンチエイリアシング、
300 サンプルの Structured Importance Sampling でレンダリング。

結局のところ、qslim はいつまでたっても終わらないようなので、簡略化はやめました。
なので上のレンダリング結果は元データと同じ 721 万三角形です。

私は the reference image と、lucille の rendering 結果画像とを比べて、私は違和感を感じました。
その理由が分かりました。私の画像では、model データが鏡像(z 値が入れ替わっている)になっていました。
私は、coordinate の取り扱いを間違えたようです。
(という風に書くと、機械翻訳にやさしくなるのかなぁ。ってか英訳したみたいだ。)

さて、次は 1,000 万個の三角形から成る、 Thai Statue です。 Don't you think so?

Mr. インクレディブルのトリビア

Mr. インクレディブルの、Frozen の本名は、

ギ○ッ○ョ。

てか、あの能力(ス○○ド?)は、どー見てもホ○○トア○○ムで しょ。

ちなみに、ホ○○トア○○ムは最強ス○○ドとの声が高い。

あと、きっと歴代ヒーローの中には、時を止められるヤツがいたに違い ない。

Compiler Software Engineer at Sony Computer Entertainment America

Compiler Software Engineer at Sony Computer Entertainment America
http://hotjobs.yahoo.com/jobs/CA/Foster-City/Technology/J900906BR;_ylt=AjoV4U.AaTskU1tcllsAlpyxQ6IX

第 4 世代 GPU 向けのシェーダコンパイラ技術者を SCEA が募集しているようです。

フツーに考えて、

1st: PS1 GPU
2nd: PS2 GS
3rd: PSP?
4th: PS3 GPU + GLSL?

ちなみに、PS1 の GPU の名前はそのまま GPU だったのです。

asian dragon をレンダリングせよ! その 1

さて、 asian dragon を lucille でレンダリングしようといろいろ環境を整え直しています。

stanford lucy のときもそうでしたが、おおきなジオメトリデータを最初に RIB 形式で持ってお
くのはテストレンダリングのときにあまり都合が良くないので、
今回も .obj 形式を lucille 独自の、 .obj からジオメトリを読み込めるように
したバックドアを利用してジオメトリデータをレンダラに読み込み、レンダリングするようにします。

このバックドアは、Option プロトコルで実現しています。

Option "prt" "model" ["asiandragon.obj"]

"prt" のオプション指示は、前計算放射輝度伝達(Precomputed Radiance Transfer)の
伝達シミュレーションを行なう lucille 拡張で用いているものです。

lucille の前計算放射輝度伝達シミュレーション機能のときも .obj 形式でジオメトリデータ
を与えた方が都合が良いので、このような .obj 読み込みバックドアを作成していました。

.ply

asian dragon を始め、stanford 3D scanning repository で公開されているモデルデータの
多くは .ply というフォーマットになっています。 .ply は .obj と似たようなものでそれほど
複雑ではありませんが、後で述べるメッシュ簡略化ソフト qslim で処理することも考えると
.obj にデータを変換したほうが都合がよい。

.ply を扱うライブラリは stanford 3D scanning repository のページでいくつか紹介されて
いますが、今回は rply というライブラリツールを利用することにしました。

RPly : ANSI C Library for PLY file format input and output

その理由は、バッファリングなど膨大なジオメトリデータを処理するのに適しているのと、
ANSI C で記述されていることでした。すばらしい。コンパイルもすんなり通るし。
やっぱ時代は C 言語です。
C++(しーぷるぷる) で書かれたライブラリなんてまったくもって使いものにならない。

.obj に変換するには、rply に付属のサンプルコードがほぼ .obj に近いデータを吐くので、
ちょこっと修正するだけで .obj コンバータが出来上がります。

qslim

qslim

http://graphics.cs.uiuc.edu/~garland/software/qslim.html

というのは、メッシュ処理で有名な Michael Garland 先生のメッシュ簡略化ソフトです。
なんか最近見てみたら、バージョンアップして Mac OS X にも対応しているし、
fltk のインターフェイスが付いたみたいだし、ライセンスも緩和されたっぽいですね。

テストレンダリングを少ないポリゴン数のモデルで行ないたいのが、
qslim をつかってジオメトリを簡略化する理由です。
qslim は .smf という形式を入力ジオメトリとして取り扱うことができます。
.smf は、ほぼ .ojb と同じなので、そのために先ほど .ply から .obj へと
ジオメトリデータを変換しました。

その昔、stanford lucy を qslim で簡略化しようとしたときは、メモリ制限(4GB)を超えてしまい
簡略化できなかった(ので、バウンディングボックスだけ計算させておいて、そのバウンディングボ
ックスに画面に入るようにカメラ位置を手動で調整した)のですが、
asian dragon レベル程度であれば簡略化は問題なく出来そう。

そういや、オープンソースの out-of-core 法使ったメッシュ簡略化ツールってないのかな。
それがあればメモリ制限に引っかからずにいくらでも膨大なメッシュを簡略化できるのに。

to be continued..

cell は 200GFlops?

単体 cell の 理論値は 200GFlops から 400GFlops らしい。

http://pc.watch.impress.co.jp/docs/2004/1202/kaigai137.htm

G5 2.5GHz single の理論値の 10 倍から 20 倍ですね。

Asian dragon

次世代のドラゴンです。Stanford Dragon なんてまったくもって古いぜ!

Stanford 3D Scanning repository が更新されていますね。

The Stanford 3D Scanning Repository

XYZ RGB Inc. から 3 つ追加されています。

いずれも 500 万から 1000 万三角形です。

lucille は 2G のメモリで stanford lucy (2700 万三角形) をレンダリングできますから、
これらをレンダリングするのは全然問題ないはず。時間があればレンダリングしてみたいですね。

というわけで、打倒! vray!

あと、結構前から注意書きとしてありますが、happy buddha や stanford lucy などは、
文化的・宗教的観点から虐待をさせてはいけませんとのこと。

Fedkiw はヒドいことするよなぁ... 溶かすとか、斬り捨てるとか...

cell プロセッサ

なんかいつの間にか発表されたっぽい。でも概要だけのようですが。

http://pcweb.mycom.co.jp/news/2004/11/29/011.html

ISSCC というのは、半導体ではもっとも権威のある学会のようです。
せっかくですから、これからは ISSCC など、半導体がらみの論文も読んで
いきたいですね。

1 ラック 16TFlops
cell プロセッサですが、1ラックで 16TFlops を達成するとのことです。
1 ラックに一体何個のプロセッサが搭載されるのかは不明ですが(10 - 100 くらい?)、
ラック 3 個で地球シミュレータと理論値では同程度と考えてよいでしょうか。

G5 2.5 dual の理論値が、

2.5GHz x 2(cpu) x 4(SIMD) x 2(積和演算) = 40 GFlops

ですから、cell のラックは G5 dual の約 400 倍になりますね。

G5 dual じゃ 1 年超かかるレンダリング計算が、cell のラックだとわずか 1 日でできることに
なります。

lucille on cell も時間があればやってみたいですね。

翻訳テスト

google のォォォッ
翻訳機能はァァァッ!!!!!
世界一ィイイイイイイイイイ!!!!!!!!!!!!!!!!!!!!!!!

日本語というものが!世界で!
最も最も最も最も最も最も最も最も最も最も最も最も最も最も最も最も最も最も最も最も最も最も最も最も最も最も最も最も最も最も最も最も最も最も最も最も 最も最も最も最も最も最も最も最も最も最も難しいッ!!!!!!!!!!!!!!!!キィィーーーーーーーーーーーー!!!!!!!!!!!

...機械翻訳の能力はまだまだのようですね。

ビットの順列とグラ フィックス

ぜんかい、Hacker's Delight のビット圧縮法が浮動小数点圧縮に使えないもんかと書きましたが、
その後良く読むと、ビット圧縮を利用したビットの順列(bit permutation)がグラフィックスに応用がある、
と書かれていました。

うーむ、いったいどんなグラフィックス用途に使えるんだろ。
とりあえずビット圧縮だったら、
Z 曲線のインデックスを (x, y) にもどす計算に使えそう。
( ビッ トインターリーブ 2 )

軽くグーグル大先生にお伺いを立てたところ、ビットの順列はどうも分 散処理とかに使うようだ。
ということでフレームバッファやテクスチャメモリへの分散アクセスとかに使えるのかな?

Lossless Compression of Floating-Point Geometry

Martin Isenburg, Peter Lindstrom, Jack Snoeyink,
Lossless Compression of Floating-Point Geometry
Proceedings of CAD'3D, May 2004.
http://www.cs.unc.edu/~isenburg/research/

Streaming Meshes に注目したのは、
既存の .obj 形式と互換のあるフォーマットにすることが可能、
という点に惹かれたのもありますが、
もうひとつは、Streaming Meshes に用いられていた
浮動小数点のロスレス圧縮です。

メッシュジオメトリもそうですが、浮動小数点を使うデータの多くの場 合、
実際には浮動小数点が表現できる範囲のごく一部
(値が一部の仮数部の範囲に集中している)
しか使われていないという点に本論文は注目しています。

基本的には、浮動小数点数を、符号部、指数部、仮数部へと分け、
指数部をキーとして算術符号化(arithmetic coding)を適用するというものです。

このとき、本論文では平行四辺形予測子(parallelogram predictor)を用いて、
予測値と実際の値との差分を符号化するようにして、効率を高めています。

平行四辺形予測子という予測法というのは、次に来る頂点位置というの は、
前の 3 つの頂点と平行四辺形を成す、というのものです。

通常頂点あたり 96bit(32x3) になるデータを、本手法を利用することにより
ロスレスで 1/3 から 1/2 に減らすことが可能とのこと。

算術符号化のアルゴリズムは IBM や富士通に特許が取られているようなので、
実装するならパテントフリーらしいレンジコーダを代わりに用いたほうが
いいかと思います。

そういえば Hacker's Delight にはビット圧縮のネタがありましたが、
あれも浮動小数点の圧縮に使えたりできないかな。