バーチャルネット右翼きも19歳
CGを勉強してる男の子です。2年を越えるお芋の国での防人を経てようやく東亜に帰国出来きました。座右の銘は「来世に期待age」です。ちょっとシャイで人間の屑の気がありますがみんな仲良くしてあげてください。
スポンサーサイト
上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。


週間きぬくんダイアリー
- Siggraph Asia

・OpenCL ( http://sa09.idav.ucdavis.edu/ )
scatter が使えるので、複数ピクセルに同時に書き込めて
全ピクセルで行う gauss filter の texture fetch が減らせる。
発想としては O(1) の Bilateral Filter に近い。
ただこんな足し引きは昔は当たり前のようにやってたらしい。

オーダーに依存しない 64 レイヤー の半透明描画。
A-buffer と同じ発想。ステンシルを使って書き込むサブピクセルを打っていたのを
atomic なインデックスを使ってでかめのバッファに書き込んでソーティングしてる。
ローカルメモリに書けば高速にソート出来るはず、バイトロニックソート?

・Micro Rendering Final Gathering
発表の内容よりもびっくりしたのが研究でシェーダーオーサリングツールみたいなのを自作して使用してた。
研究所で流用してるらしい。
アンリアル的な UI でデバッガの機能や一通りのシェーダーが載っていた。
ファイルフォーマットも自作に近いだろうし、ああ、もうこんなのを研究でも内作しないといけない時代になったんだなと痛切。

きゃろりんと話してて
今CGで注目してるのはアップサンプリングとベクターグラフィックス
始めはそうかーと思っていましたが、よくよく考えてみるとそうかも
http://www.mpi-inf.mpg.de/~rherzog/Papers/spatioTemporalUpsampling_preprintI3D2010.pdf

アップサンプリングはポストプロセスとして
ベクターグラフィックスはプリプロセスとして組めば
グラフィックスフレームワークに入り込む余地が多いにあるなと思いました。

それとは関係なく gradient mesh を使ったベクトル圧縮を教えてもらいました。
http://kesen.huang.googlepages.com/sig2007.html
ライトマップとか法線マップの圧縮にも向いてそうな印象、圧縮率は10倍ぐらい?
OpenCL の Scatter を使って高速な Real Time Encoding、もしくは直接 DXTn の展開も行えそう。
こういう系は苦手なんですが実装中。

- ジェームズ・キャメロンが何故かニコニコに
http://www.nicovideo.jp/watch/nl8836993
なんでやねん。
ちなみに今日有給とったので見てくるかも。
スポンサーサイト


ところで君は 1texel 何バイトなんだい?
ただのチラシの裏です。
気にしないで下さい。

コーネルボックスで適当に試してみたが DXT1 は人類の英知の集大成だけあって
高圧縮で高品質(HDR除く)の画像が生成される。

という事はGIは少なくとも高品質で計算すべき

その計算されたのを基にテクスチャサイズを減らす方向でいこう

圧縮率は固定、つまりどこを小さくしても問題ないのかに注目すべき

仮にも圧縮されるので非圧縮のときよりもテクスチャの質は悪くなる。
悪くなるんだから、テクスチャサイズもざっくり減らせるはず。
つまり相乗効果でテクスチャを減らせるはずだ!

[将来]
さらに DXT1 に対しても圧縮をかけることでさらなる圧縮が出来るはず。

というわけでテーマを徹底的に圧縮に置きます。
すぐに脱線するかもしれないのであまり気にしないで下さい。


DXT1 ライトマップ を OpenGL で可視化してみる・続続
> とりあえず実験を始めるために実装すること
> - フォトントレースして、各ライトマップテクセルでkNNしてライトマップを書き出す
> - BC1に圧縮して、OpenGLでライトマップで可視化する

とりあえずここまでは出来ました。
id software の Real-Time DXT Compression は RGBA8 を想定してて、いつもアルファの1バイト分ずれるというのにハマってしまいましたが寝る前に資料を再読しててそれに気づいて修正。

DXT1 は base color(565)x2, 2bitのルックアップ x 16 の 8 byte のデータがそのままずらずらと並んでいるだけです。



GLuint lightmapidx[5][2];
int sizeBlock = 32;
unsigned char* lightmapData = new unsigned char[sizeBlock*sizeBlock*4];

int outputBytes;
// Reference : Real Time DXT Compression
// http://cache-www.intel.com/cd/00/00/32/43/324337_324337.pdf

CompressImageDXT1( lightmapData, lightmapDXT1, sizeBlock, sizeBlock, outputBytes);

assert(outputBytes == sizeBlock*sizeBlock*3/6);

glGenTextures(1, &lightmapidx[0][1]);
glBindTexture(GL_TEXTURE_2D, lightmapidx[0][1]);
glCompressedTexImage2D(GL_TEXTURE_2D, 0, GL_COMPRESSED_RGB_S3TC_DXT1_EXT,
   sizeBlock, sizeBlock, 0, outputBytes, lightmapDXT1);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR);



rawvsdxt1_1210.jpg

左がオリジナル画像で、右が DXT1 圧縮後。
結構ノイズ(分散値)の強めの画像なんですが悲しい事にほとんど違いがわかりません。

さあ、とりあえず最初のノルマは達成したので次なにしようか考えます。
DXT1 をさらに圧縮して GPU Decoding。OpenCL Encoding。GIの計算を減らす方向に。テクスチャサイズを減らす方向に。タイル化して Quad tree 的な Adaptive Light Map、とりあえず思いつくのはこんなところ。
やることは色々あるような気もするんだけど、基本的な考え方は全部90年代のラジオシティと Density Estimation なのでやるべき価値があるかどうか非常に怪しい。

きゃろりんが日本に来てて明日会うので多少は相談しようかとは思いますが、奥さんも一緒に来てて観光が目的なのであまり KY すぎる事は出来ないのでとりあえず暇な時に見てもらえるように ppt にまとめようかな。

とりあえず暇つぶしでやっとく事。
http://developer.download.nvidia.com/compute/cuda/sdk/website/projects/dxtc/doc/cuda_dxtc.pdf
の Cuda のコードを OpenCL に移植する。
DXT1 圧縮はこだわりをもたなければ上からずらずらと(色の)ベクトル演算をしてくだけなので GPU で実装した方がうんと早いです。Real Time DXT Compression も完全にそっち系です。

あと、フォトントレースは全然早いのですが微妙に density estimation が遅いのでこれも GPU で何とかしたいです。photon を point sprite にして重ね合わせするのが一番早そうなのでそれをやってみます。


DXT1 でライトマップ圧縮・続
- 昨日の続き
OpenGLでちゃんと読めるところまでは行ってないのですが
とりあえず適当にテストしてみた。

nomeaning_dxt1_densityestimation1208.jpg

左がオリジナル、右がDXT1、真ん中が差分。サイズは64x64。
あんまり違いが出ない、むしろ綺麗にノイズを保持出来てた。
まあ、こんなんでうまくいったらびっくりするわけで。
適当にフィルターをかけないといかんですかね。

ちなみにフィルターをかけるというのは、各テクセルが周囲のテクセルに出張してフォトンをかき集めてるので、テクスチャマッピングの際にバイリニア補間をかけてしまうと近いフォトンを重複して(最大4倍)カウントしてしまう事になるのです。
テクスチャ補間は NearestNeighbor を使うのが的には正しいはず。
何にせよバイアスは問答無用で増えます、無茶苦茶増えます。

もし線形補間を使いたくで死にそうな場合は、フィルターを工夫する。
普通の kNN はコーンフィルターで近くのフォトンを重みを強くするのですが、近くのフォトンは重複してカウントされる可能性が高いので逆に重みを下げるとか。

ミップマップはもう少し難しい問題です。
ミップマップはそもそもテクスチャの理想解像度を知らないといけないので。
この話をしてるうちにどっかで考える場面が出てくるので、これは後回しにします。

badcase_dxt1_densityestimation1208.jpg

これは超極短な例、サイズが4x4の最小ブロック単位。
右の DXT1 では色も見事に消されてしまってる。
これはアルゴリズムの問題ですね。

上のはATIのやつだけども今実装してる Real Time DXT Encoding という題目通りDXT のエンコードの兆速化が目的なんだけども、そんな要求がこの世のどこにあるねんと思ってたけども間接光をデザイナーが手付けしたりする際はすぐに結果がプレビュー出来るという意味では悪くないのかも。

- I3D 2010
昨日きゃろりんと電話してたら昔の同僚が来年のI3Dに採択したよって話になって、中々渋いところに出すんだなと思ってネタを聞いたらGPUを使った超解像度系の技法だよって、へー、何か面白そうでテンションあがった。

- Larrabbeの開発中止
http://journal.mycom.co.jp/news/2009/12/07/047/?rt=na

最近CG系の人と飲んでこの系の話をしたらこの世の終わりみたいな顔をされたのでてっきり全く速度が出ないのが理由だと思ってたんですがひょっとしてこれをもう知ってたのか。

-空の境界 劇場版
TSUTAYAで大人借りをしたのですがどうも奈須大先生の感性は僕にはよく分らない。
とかいいつつ僕の感性はスターシップ3を見てバーホーベン先生は天才すぐる!
とか言う程度のモノなので人のことは言えないのですが。


Baked LightMap
フォトンマップのライトマップを作ってみた。

先日の日記のコーネルボックスの後ろの壁のライトマップです。
おなじみのkNNの染みが出てるんですが、これはkNNの数字が足りないからです。
見ようによっては死人の亡霊にも全く見えない左下の黒い部分は、ノッポの方の箱の影です。

lightmap1208.jpg

コレガッ!
圧縮をかけるとあら不思議、色の量子化がフィルターとなって分散ノイズが減るというわけです(脳内予定)

DXT1 圧縮は明日家に帰ってきて時間があったらやります。
といっても Real-Time DXT Compression をコピペするだけですけども。
http://cache-www.intel.com/cd/00/00/32/43/324337_324337.pdf

DXT1の(研究的に)いいところは圧縮率が固定(6:1)なところだと思う。
jpeg とか mpeg に落とし込もうとしても最終的にビットレートを決めなくちゃいけないし。

そういや Siggraph Asia 2009 で僕のお芋時代の先生が日本に来てるそうです。
金曜日に遊ぶかも。
後、Siggraph Asia で声かけれそうな人に声かけてくかもしれません。


久々のGI
久々にGIやりました。
フォトンマップ直接可視化。
フォトン200万個ぐらいでkNN=2000
結構時間かかった、2時間ぐらい。
kNNが思ったより遅かった、kNN=50にすると10秒ぐらい。

cornellbox_5m_kNN2000.jpg

Siggraph Asia 2009たぶん行きます。


突如湧き出てきたCG研究への情熱
:とりあえずの目的
- Global Illumination自体の計算の高速化
- ライトマップの圧縮、BC1圧縮のアルゴリズムでやる(たぶん汎用のでもOK)

:最終出力はBC1圧縮されたライトマップ
- 将来的にはHDR対応を考えないといけないけども最初は無視で
- BC1は4x4のブロックで量子化される
- Search Radiusをブロック単位で行うべき?
-- 横のブロックと(ラジオシティ的な)色が劇的に変化するのを防ぐ為に隣接ブロックまでSearch Radiusをのばしてもいい

:ライトマップをどうするか
- KD-Treeで切ってくのはそんなに悪くないっぽい
-- ETCを作ったSony Erricsonの研究者が最近KD-Treeで法線マップを圧縮してた

:そのうちの目的
- OpenCL Computingでデコードしやすいフォーマットまで持っていく
-- 逆量子化をCPUで、inverse DCTやinverse waveletをGPUでやるみたいなノリ

:まったく関係ない独り言
- APUってFushionのことなのね、昨日の日記でDSPって書いたけど間違いみたい

とりあえず Bee さんの Stochastic Progressive Photon Mapping のコード読みながら勉強してます。
Bias Compensation for Photon Mappingは昔実装した記憶があるので何となくは理解出来てると思ふ。

とりあえず実験を始めるために実装すること
- フォトントレースして、各ライトマップテクセルでkNNしてライトマップを書き出す
- BC1に圧縮して、OpenGLでライトマップで可視化する


GPU Computing 勉強
: OpenCLお勉強
色々と言葉の定義の勉強から。

- プラットフォーム
ATI Stream とか CUDA とかそんなの。
OpenCL が動く低レイヤーのデバイスドライバみたいな感じ。
clGetPlatformIDs 関数を使ってプラットフォームの数とかそのリストも手に入る
clGetPlatformInfo 関数でプラットフォームの情報が参照出来る、どこ製のどんな名前のプラットフォームなのかとか。

- デバイス
並列演算を行う人
Radeon とか GeForce とかららびぃぃぃぃとかそんなの。
とか思ってたんだけど、普通に CPU と GPU が出てきた。
AMD の CPU は認識出来るという噂を聞いたけど、僕のIntel製だけど認識された。
clGetDeviceIDs でデバイスの数がわかる、CPU と GPU と DSP の数がわかる。
clGetDeviceInfo でデバイスのスペックが分る、演算機の数とか。

僕のマシンでは Core2 Quad CPU で演算機数は4。まあこれは 4コア だからそのまんま。
Radeon HD 5870 の演算機は10になってた、1SIMD-Coreが 80=16x(4+1) のスカラー演算機だからたぶん合ってる。
後、Radeonの CL_DEVICE_NAME は Juniper ってなってた、調べたら Radeon HD 5700 番以降のコードネームらしい。

CPUも思う存分、並列処理を考慮出来るわけですね。

: 私信
> 僕の中ではエラー=バイアス+分散(ノイズ)なので,バイアスにエラーがでるという表現で混乱してました.

あ、すいません、こっちが正しい日本語です。
圧縮のメカニズム(DCT or wavelet)とバイアスと分散の関係性(Beeさんの手法とかBias Compensation for Photon Mapsとか)
の考察から無理矢理因果関係がつくれたらいいなあとか、そんな感じですね。

: Rendering from Compressed High Dynamic Range Textures on Programmable Graphics Hardware (I3DG 07)
http://www.liyiwei.org/
DXT5圧縮テクスチャ を 2枚使ったHDRの圧縮、16ビット浮動小数を使う3倍の圧縮。
Halo3 で使われてるの?かもしれない。
ちゃんと読みます。




Copyright © バーチャルネット右翼きも19歳. all rights reserved.

上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。