ofx3Dfont使ってみた

レンダリングエンジンに入れてみたところ、ちゃんと表示されてるみたい。ただ、このライブラリはtexcoord作ってくれないので、適当に自前で貼ってみたけど、押し出しの側面のこと考えるの難しいな・・・。下のやつはごまかしで貼ってあるのでカメラが近づくとおかしいのがバレる(前後同じ座標で伸びてるだけ)。”大草原不可避”は最近覚えたての単語w

スクリーンショット-2014-01-25-01.51

ofx3Dfontは去年ひっそり公開したofAddonデス・・・。説明書いてないけど、動的にofMesh作ったり、ofTrueTypeFontみたいに直接文字列をDrawしたりできます。ofTryeTypeFontUL2っていうのも必要。こっちはharfbuzzをincludeしたTypoGraphyの強化モジュール。ほとんどofTrueTypeFontと同じだけど、カーニングペア、リガチャ、フォントスクリプト、日本語プロポーショナル、TextAligmentなど、いろんな拡張ができる。ちゃんとしたTypoGraphyが必要なときは少し役に立つかもしれません・・・。

スクリーンショット 2013-12-03 00.28.38

スクリーンショット 2013-12-03 01.55.07

さぁようやく次はインタラクティブ化だ。

 

ポストプロセスアンチエイリアス実装(FXAA,SMAA)

Defferdの課題の一つ、アンチエイリアスを実装してみた。AAについて小一時間調べた結果、試したのはFXAAとSMAA。調べてみるとこの辺りはOpenGLでの実装実績も多く、思ったよりも簡単に実装ができた。最近の高解像度化でギザギザはあんまり気にならないんだけど。

スクリーンショット 2014-01-23 23.48.10これは拡大しないとわからないけど、No AA

まずはFXAA。

fastというだけあってとにかく高速。1PassだしFPSへの影響は3%ぐらい。下記の出力画像はちょっと例題としては良くないけど、AA自体はかなり綺麗に入ってる。ブラー効果が強いとは色々なとこに書かれていたが、確かに強い。木目のDetailとか、マテリアルの細かい陰影など、特にカメラに近づいたもので、はっきり見えるはずの部分が潰れてしまうことがあった。遠くに細かいオブジェクトをたくさん出すと、Dofっぽくていい感じになってる。

実装については、元ネタはこのあたりのようだけど、Processingに含まれてるコードが簡単に移植できた。ちなみにポストAAってどのタイミングでかければいいのか悩んだけど、とりあえず一番最後すべてのプロセスが終わったあとにRGB8のFboを用意して出力するようにしてみた。MSAAほどではないけど、簡単にできるのでオススメです・・・。

スクリーンショット 2014-01-23 23.47.55FXAA (Fast Approximate Anti-Aliasing)

次に、SMAA。

FXAAはソース読むと理解できたんだけど、SMAAは深く読んでない。けど、3passで出力結果のイメージを見た感じ、pass1 でエッジ抽出(ベクトル)。 pass2で1のエッジのなかでAAやるかどうか判定(強さ)、step3 で2の情報つかって実行みたいなかんじ?読んでないから適当だけど、pass2 の結果をみるとかなりエリアを絞っているので、AAがかかるべきところをより厳密に決定しているようだった。結果は評判通り、画質に関してはすごくいい感じ。ただし、全体の処理コストの中ではそれほど大きくないが、FXAAの倍近く負荷がありそう。

実装についても少し書いておくと、ソースはこれ。HLSLとGLSL両方でつかえるっていう斬新なコードでした・・・。

・・・ちょっと長くなりそうなので、ここらで一旦寝ます・・・w(続き)

スクリーンショット 2014-01-23 23.48.03Subpixel Morphological Antialiasing

結論:

ポストプロセスのAAはいわゆる画像処理なわけだけど、画像処理でここまで出来るということに普通に驚いた。ジャギった画像に対してAAできるわけだから、3Dだけじゃなくていろんな応用ができそう。そういえば、写真を2値化したりエッジ抜いたりするときにジャギるの、綺麗にしたかったんだよなぁ・・・。試してみよう。

最近のメモ

年明けてからほぼコード書いてない。

変化するLight Probeの実装イメージ見たくて探してたらwebGLでやってる。
http://codeflow.org/entries/2012/aug/25/webgl-deferred-irradiance-volumes/
これ、WebGLのDefferd Rendering調べてた時にメモってたやつだけど、なにげにすごいことやってるなぁ。

で、最近出たComputer Graphics Gems JPにもLight Probeが取り上げられてたので買ってみた。


まだ途中までしか読んでないけどGBuffer(MTRコスト)の最適化?みたいな頁もあった。

あと、年末になんか調べてたら出てきたスライド、ずいぶん前に公開されてた資料だけど、すごい良かった。
リンク先の資料とかもいろいろ見て見とこうと思う。

いや、年明けてからほぼコード書いてないわけだけど・・・。

Deffered RenderingとofFbo

現状ではofFboのバグのため、Deffered RenderingのためのG-Bufferを作ることすらできないのでちょっと残念である。(現時点でバグのためのPull Requestは出ている) とはいえofFboの設計思想についてはMTR(Multi Target Rendering)を想定して設計されているようだ。

これは実際に作っているDeffered Renderingのデバッグビュー

一例であるが、下記のようにDeffered RenderingのGbufferが構成できる。

ofFbo::Settings gSetting;
gSetting.textureTarget=GL_TEXTURE_2D;
gSetting.depthStencilAsTexture=true;
gSetting.depthStencilInternalFormat=GL_DEPTH_COMPONENT; //depth
gSetting.height=height;
gSetting.internalformat=GL_RGB;
gSetting.maxFilter=GL_NEAREST;
gSetting.minFilter=GL_NEAREST;
//これが現在バグっている(of0.8.0)↓↓
gSetting.colorFormats.push_back(GL_RGB); //diffuse
gSetting.colorFormats.push_back(GL_RGB); //specular
gSetting.colorFormats.push_back(GL_RGBA);//Normals + SSAO.
gSetting.colorFormats.push_back(GL_RG8); //velocity
gSetting.useDepth=true;
gSetting.useStencil=false;
gSetting.width=width;
gSetting.wrapModeHorizontal=GL_CLAMP_TO_EDGE;
gSetting.wrapModeVertical=GL_CLAMP_TO_EDGE;
gbuffer.allocate(gSetting);	

個人的に加えて欲しいのがMTRのためのテクスチャのアタッチメントだ。ofFboではFboオブジェクトがテクスチャを内包するような設計のため、内部テクスチャを他のFBOにアタッチすることができない。いや、実際は下記のようにすればできるわけだから、窓口が用意されていないだけか。

//bind a velocity buffer to HDR Buffer
ofTexture &velTex=gbuffer.getTextureReference(3);
mFboHDR.begin(false);
glFramebufferTexture2D(GL_FRAMEBUFFER,GL_COLOR_ATTACHMENT0+1,velTex.texData.textureTarget,velTex.texData.textureID,0);
mFboHDR.end();

例えば、ライティングを必要としない光源や環境マップをHDRレイヤーに直接レンダリングする際、G-Bufferに書き込みはしないが、Velocity bufferを更新する必要がある。このようなケースではGbufferのVelocity textureをHDRレイヤーのFBOにもアタッチしておけば、余計なレンダリングパスを増やさなくてすむことになる。

とまぁ実装しててcoreの色々足りないところが出てきている。
例えばofTextureについてはcube Textureはiblのために必要だし、1D textureも使えた方がいい。これらはofTextureを継承してofxCubeTexture、ofxTexture1Dみたいに実装している。

また、遅延レンダリングをするには、シェーダーを含めたマテリアルの管理システムが必要になってくる。of標準のofMesh,ofMaterialクラスでは限界があるのでこの辺りはもうちょっと拡張していく必要がありそう。assimpも含めてマテリアル情報を正確に取り込み、レンダリングする仕組みを作らなければならないだろう。これは今後の課題。

とまぁいろいろやってみると、どんどんopenframeworksの使いやすさからかけ離れていきそうなので、完全に独立したレンダリングエンジンになっていきそう・・・。

2014年

昨年は下半期、アンビエントオクルージョンを目標にしていたんだけど、かなり時間かかったけど達成できたのでよかった・・・。アンビエントオクルージョンて1000回ぐらい言った気がする。響きがいいよ。

今年の目標は、実用的なシャドウマッピング。LiSPSMを軸に改良していこうと思っている。そして去年からやってるレンダリングシステムの完成。これらを使って、いい感じの作品を作りたい。iPhoneアプリの新作も作りたいなー。

スタンフォードバニーとかティーポッドばっかでいい感じのキャプが取れないからブログも書く気しないんだよなぁ・・・。今年はまず昨年度実装したレンダリングシステムをまとめてから、シャドウの実装にとりかかっていこうと思う。

がんばろ。

あ、あとアフターエフェクトつかえるようになりたいわ・・・。