SSLR

スクリーンスペースローカルリフレクション(SSLR)実装してるんですが・・・。なんとなくでるところまではいったけど・・・。
うまくいかないわー。もーいやわー。

スクリーンショット 2014-10-07 10.28.12

 

レイトレースのfragシェーダ。だいぶ簡素化してあります。おかしいと思われる原因がありすぎて・・・ちょっと寝かせよう・・・。


vec4 RayTrace(in vec3 startP,in vec3 endP){

    vec4 startSSP = uProjectionMatrix*vec4(startP,1.0);
    startSSP.xy /= startSSP.w;
    startSSP.xy = startSSP.xy *  0.5 + 0.5; 

    vec4 endSSP = uProjectionMatrix*vec4(endP,1.0);
    endSSP.xy /= endSSP.w;
    endSSP.xy = endSSP.xy *  0.5 + 0.5; 

    vec3 vecSS = (endSSP.xyz - startSSP.xyz);
    vecSS.z=endP.z-startP.z;
    vecSS*=length(texelSize)/length(vecSS.xy);

    vec3 sampleP = vec3(0.0);
    float sampleDepth = 0.0;
    float diffZ = 0.0;
    vec4 color = vec4(0.0);

    for (int i = 1; i < 100 ; i++){
        sampleP.xy = startSSP.xy + vecSS*i;
        sampleP.z = startP.z + vecSS.z*i;

        if(sampleP.x < 0 || sampleP.x > 1 ||
	    sampleP.y < 0 || sampleP.y > 1 ||
	    sampleP.z < 0 || sampleP.z > uNearFar.y ){
	    break;
        }

        sampleDepth =linearizeDepth(texture(depthTexture, sampleP.xy).r, uNear,uFar);
        diffZ = sampleP.z - sampleDepth;
        float error = length(vecSS);

        if (diffZ>=0&& diffZ<error)
        {
            color = texture(colorBufferTexture, sampleP.xy);
            break;
        }
    }
    return color;
}

Source Han Sansで3Dリアルタイムレンダリングはじめます

ようやく仕事がおちついてきたので、openframeworksを弄ります。ここ半年、ASばっかりやってたので、var:とかがなかなか抜けない。あるある。 ofも最新にアップデードしたし、しばらくタイポグラフィとDeferred Renderingで遊んでいこうと思っています。いいタイミングで、Source Han Sansっていうオープンソースの書体がリリースされたので、こちらを主に使わせていただきます!Heavyはいい太さで、3D化しても見応えがありますね。 さっそくレンダリングします。Bulletを組み込んだので、ガチャガチャ動かすぜーとか思ってましたが・・・、 スクリーンショット 2014-09-24 18.38.34 一部おかしくなってますね・・・。法線を表示してみます。 スクリーンショット 2014-09-24 18.38.46 法線が裏返っています・・・。ポリゴンの形状は正しいようです。ofx3DFontっていうライブラリ内部で3D化する際に法線を生成しているのでそのあたりを疑ってみます。表示がおかしくなる文字を取り出してワイヤーフレームを表示。どうやら三角形分割に使っているpoly2triが効いていません。 スクリーンショット 2014-09-24 18.19.55 ポリゴンで表示。あっちでは法線が壊れていたのにちゃんと表示されている(謎)。 スクリーンショット 2014-09-24 18.20.46 フォントのアウトラインを表示。 スクリーンショット 2014-09-24 18.06.50

ひとととりデバッグしてみたところ、表示が崩れるグリフの共通の条件が判明しました。

スクリーンショット-2014-09-24-18.06

ポリゴンのアウトラインに接点がある場合、poly2trでエラーが発生するためバックアップ用途にしているof標準テッセレータでテッセレートされるんですね・・・。poly2triはきれいな3角形分割をしてくれるので気に入ってるんだけど。というわけでpoly2triに渡す際の前処理をこれから書いて見ようと思います・・・。

SMAA、FXAAのofExample

前回の続き。SMAAの実装の紹介。

ソースは最新のこっちにした。
https://github.com/iryoku/smaa

SMAAで3回分のシェーダが必要なんだけど、shader3つも作るのはナンセンスだから1つにまとめてみた。でも、これだと1passはrgチャンネルしか使わないのでbit数の最適化ができてない。まぁいいか・・・。

バーテックスシェーダ

#include "../common/version.glsl"

/* uStep
 * 0:Edge Detection
 * 1:Weight Calculation
 * 2:BlendingWeight
*/
uniform int uStep=0;

layout(binding=0) uniform sampler2D uInpTex;
vec2 texSize = vec2(textureSize(uInpTex, 0));
#define SMAA_RT_METRICS vec4(1.0/texSize,texSize)
#define SMAA_INCLUDE_PS 0
#define SMAA_GLSL_4 1
#define SMAA_PRESET_ULTRA 1
#include "SMAA.hlsl"

noperspective out vec2 texcoord;
noperspective out vec2 pixcoord;
noperspective out vec4 offset[3];

layout(location=0) in vec3 position;

void main(){
 texcoord = position.xy * 0.5 + 0.5;
 if(uStep==2){
 SMAANeighborhoodBlendingVS(texcoord, offset[0]);
 }else if(uStep==1){
 SMAABlendingWeightCalculationVS(texcoord, pixcoord, offset);
 }else{
 SMAAEdgeDetectionVS(texcoord, offset);
 }
 gl_Position = vec4(position.xy, 0.0, 1.0);
}

ピクセルシェーダ

#include "../common/version.glsl"

/* uStep
 * 0:Edge Detection
 * 1:Weight Calculation
 * 2:BlendingWeight
*/
uniform int uStep=0;

layout(binding=0) uniform sampler2D uInpTex;
layout(binding=1) uniform sampler2D uInpTex2;
layout(binding=2) uniform sampler2D uInpTex3;

vec2 texSize = vec2(textureSize(uInpTex, 0));
#define SMAA_RT_METRICS vec4(1.0/texSize,texSize)
#define SMAA_INCLUDE_VS 0
#define SMAA_GLSL_4 1
#define SMAA_PRESET_ULTRA 1
#include "SMAA.hlsl"

noperspective in vec2 texcoord;
noperspective in vec2 pixcoord;
noperspective in vec4 offset[3];
layout(location = 0) out vec4 fOut;

void main(){
 if(uStep==2){
 fOut = SMAANeighborhoodBlendingPS(texcoord, offset[0], uInpTex, uInpTex2);
 }else if(uStep==1){
 fOut = SMAABlendingWeightCalculationPS(texcoord, pixcoord, offset, uInpTex, uInpTex2, uInpTex3, ivec4(0));
 }else{
 fOut = vec4(SMAAColorEdgeDetectionPS(texcoord, offset, uInpTex),0.0,0.0);
 }
}

多分こんな感じ。GLSLは410以降が必要。
作業用のFBOはアルファチャンネルも使うのでRGBAが必要。あと、テクスチャ用のヘッダファイルがあるのでofTextureとして登録。


ofFbo::Settings defaultSetting;
 defaultSetting.numSamples=0;
 defaultSetting.textureTarget=GL_TEXTURE_2D;
 defaultSetting.height=768;
 defaultSetting.internalformat=GL_RGBA;
 defaultSetting.useDepth=false;
 defaultSetting.useStencil=false;
 defaultSetting.width=1024;
 defaultSetting.wrapModeHorizontal=GL_CLAMP_TO_EDGE;
 defaultSetting.wrapModeVertical=GL_CLAMP_TO_EDGE;
 defaultSetting.numSamples=false;

fboRender_.allocate(defaultSetting); //入力用
 fboAA_.allocate(defaultSetting); // AA結果表示用
 fboSmaaWk_.allocate(defaultSetting); //作業用

//SMAAテクスチャ
 texSmaaArea_.allocate(AREATEX_WIDTH,AREATEX_HEIGHT,GL_RG8,false);
 texSmaaArea_.loadData(areaTexBytes,AREATEX_WIDTH,AREATEX_HEIGHT,GL_RG);
 texSmaaArea_.setTextureMinMagFilter(GL_LINEAR,GL_LINEAR);

texSmaaSearch_.allocate(SEARCHTEX_WIDTH,SEARCHTEX_HEIGHT,GL_R8,false);
 texSmaaSearch_.loadData(searchTexBytes,SEARCHTEX_WIDTH,SEARCHTEX_HEIGHT,GL_RED);
 texSmaaSearch_.setTextureMinMagFilter(GL_NEAREST,GL_NEAREST);

処理はこんな感じ。blendモードとかちゃんときっておかないと動かない。

 glDisable(GL_BLEND);
 glClearColor(0,0,0,0);

shaderSmaa_.begin();
 fboAA_.begin(false);
 glColorMask(GL_TRUE,GL_TRUE,GL_FALSE,GL_FALSE);
 glClear(GL_COLOR_BUFFER_BIT);
 shaderSmaa_.setUniform1i("uStep",0);
 shaderSmaa_.setUniformTexture("uInpTex",fboRender_,0);
 ssObj.draw();
 glColorMask(GL_TRUE,GL_TRUE,GL_TRUE,GL_TRUE);
 fboAA_.end();

 fboSmaaWk_.begin(false);
 glClear(GL_COLOR_BUFFER_BIT);
 shaderSmaa_.setUniform1i("uStep",1);
 shaderSmaa_.setUniformTexture("uInpTex",fboAA_,0);
 shaderSmaa_.setUniformTexture("uInpTex2",texSmaaArea_,1);
 shaderSmaa_.setUniformTexture("uInpTex3",texSmaaSearch_,2);
 ssObj.draw();
 fboSmaaWk_.end();

 fboAA_.begin(false);
 shaderSmaa_.setUniform1i("uStep",2);
 shaderSmaa_.setUniformTexture("uInpTex",fboRender_,0);
 shaderSmaa_.setUniformTexture("uInpTex2",fboSmaaWk_,1);
 ssObj.draw();
 fboAA_.end();
 shaderSmaa_.end();

Openframeworksのサンプルコードはこちら(vs2012のみー)

ちなみにこのなかのofShaderHelperは、#includeとか使うために適当に作ったやつだから信用できないwGLSL4系だと結構モジュール化とかやりやすくなってるから需要あると思うので、ちゃんとしたやつをofShaderの中で強化してもらえるといいなぁ。

サンプルではFBOへの出力を単純にポストプロセスでAAかけてて、汎用的に使えると思う。最適かどうかはおいておいて、FXAA,SMAAを比較することで、メリット、デメリットが見えてくるう。SMAAは画質重視で重い。FXAAはディテールの破壊があるが高速。カメラワーク、オブジェクトの動きが激しいシーンではFXAAにスイッチするとかして使い分けるのもいいかもしれない。てかDofとか入れるとほとんどAA不要な気がする。

スクリーンショット 2014-02-04 12.01.35

ところでSMAAなんだけど、MacbookAir(Intel HD 4000)でどうしてもうまく動いてくれないのだ。なんでだろー。わからーん。

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値化したりエッジ抜いたりするときにジャギるの、綺麗にしたかったんだよなぁ・・・。試してみよう。

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の使いやすさからかけ離れていきそうなので、完全に独立したレンダリングエンジンになっていきそう・・・。

HarfBuzzのStaticライブラリを作る。winとmac。

これも結構ハマったのでメモ。Staticである理由は特に無いのだが、個人的にはこっちのほうが好き。(ライセンスによってはDynamic利用だけフリーとかが結構あるので注意。)

まずはgithubから最新のコードを取得。

https://github.com/behdad/harfbuzz

僕の開発環境はVisualStudioがメインなので、いろいろコンパイルを試みるが、エラーだらけでどうにもならない。ファイルを色々読んでみたらどうやらmakeして生成するヘッダが存在してる。ならばMACでやることにする・・・。

ドキュメントに従ってターミナルでやってみる・・・。
pkg-config と ragelが必要らしい。これはyumとかmacportsで入れとけばいい。
configureするときにfreetypeオプションをつけるとhb-ht関連が含まれるようだ。その場合freetypeも事前に入れとく。–enable-staticを指定すれStaticで作れる。

$ ./autogen.sh
$ ./configure --with-freetype=yes --with-glib=no --enable-static CXXFLAGS="-arch i386 -arch x86_64" CFLAGS="-arch i386 -arch x86_64" LDFLAGS="-arch i386 -arch x86_64"
$ ./make

少しこの辺りの補足を。XCodeではOSX Deployment targetでビルドアーキテクチャが選択されているようだがopenframeworksのデフォルトターゲットは10.6(i386)となっている。marvericksで指定する場合はx86_64となるが、今のところこの設定では一部でエラーが出る。こういったアーキテクチャの差異に対応すべくstaticライブラリはuniversal化しておく必要がある。./configureのオプションでFLAGS=”-arch i386 -arch x86_64″とするだけでuniversalライブラリを生成することができるようだ。依存するfreetypeなどもuniversalで用意しておく必要がある。出力されたものをfileコマンドで確認すると下記の通り。i386、x86_64が構成されていることが分かる。

$ file *.a
libharfbuzz.a: Mach-O universal binary with 2 architectures
libharfbuzz.a (for architecture i386):	current ar archive random library
libharfbuzz.a (for architecture x86_64):	current ar archive random library

make intallはしなくてもいい。makeした時点で src/.libsにharfbuzz.aが生成されている。macの方はこれを使う。ヘッダは下記がコピーされるのでincludeディレクトリに入れておく。

hb-blob.h, hb-face.h, hb-ot-layout.h, hb-shape-plan.h, hb.h,
hb-buffer.h, hb-font.h, hb-ot-tag.h hb-shape.h,
hb-common.h, hb-ft.h, hb-ot.h, hb-unicode.h,
hb-deprecated.h, hb-glib.h, hb-set.h, hb-version.h

次はWindowsへ移動。

macでmakeしたのでいろいろソースが書き換えられていて、vsでもコンパイルが通る。余談だが、ライブラリをビルドするVisualStudioのバージョンは高い方が良いようだ。下位バージョンでビルドしたライブラリを新しいバージョンで使うことはできないが、その逆、上位バージョンでビルドした場合は下位のVisualStudioで利用可能になってそう。(確かな情報ではなく、僕の経験した範囲では。Dynamicも事情は違ってそう)よって最近はライブラリのコンパイルを行う場合はVisualStudio2013を利用している。

話をもどして、VisualStudio2013でコンパイル手順。
まずは Win32プロジェクト-スタティックライブラリで新しいプロジェクトを作成する。SDLチェックオプションを有効にするとエラーになる部分が2箇所あるのでこのチェックは外しておく。プログラム全体の最適化を有効(/GL)にしている場合vs2010の時は利用側で警告がでていた。2012以降は出てないのでデフォルト(有効)で良さそう。

追加するソースについては、必要機能で良い。今回はこんな構成。glib,icu,test関連を省いている。(必要な場合は依存を解消してコンパイルすれば良い。)

スクリーンショット-2013-11-20-19.47

ソースフォルダと、ビルドしてエラー表示された部分にパスを通しておく。
コンパイルオプションについては、重要なポイントとしてプリプロセッサの定義が要る。

HAVE_OT
HAVE_UNISCRIBE

指定した機能を有効にしてコンパイルされる。

諸々調整を行い、うまく行けば libharfbuzz.libが作成される。(デバッグはlibharfbuzzd.libとする)
これを現在作成中のTypographyのライブラリに追加してみる。

そしたら、下記のエラーが。UNISCRIBEを追加したため、関連するDLLの読み込みが発生しているようだ。


エラー 6 error LNK2001: 外部シンボル "_ScriptShape@40" は未解決です。 D:\Dropbox\project files\openframeworks\addons\ofxTrueTypeFontUL2\example\libharfbuzz.lib(hb-uniscribe.obj) emptyExample
エラー 5 error LNK2001: 外部シンボル "_ScriptPlace@36" は未解決です。 D:\Dropbox\project files\openframeworks\addons\ofxTrueTypeFontUL2\example\libharfbuzz.lib(hb-uniscribe.obj) emptyExample
エラー 8 error LNK2001: 外部シンボル "_ScriptItemize@28" は未解決です。 D:\Dropbox\project files\openframeworks\addons\ofxTrueTypeFontUL2\example\libharfbuzz.lib(hb-uniscribe.obj) emptyExample
エラー 7 error LNK2001: 外部シンボル "_ScriptFreeCache@4" は未解決です。 D:\Dropbox\project files\openframeworks\addons\ofxTrueTypeFontUL2\example\libharfbuzz.lib(hb-uniscribe.obj) emptyExample
エラー 9 error LNK2001: 外部シンボル "__imp__UuidCreate@4" は未解決です。 D:\Dropbox\project files\openframeworks\addons\ofxTrueTypeFontUL2\example\libharfbuzz.lib(hb-uniscribe.obj) emptyExample

Rpcrt4.lib;usp10.lib;をリンクする必要があるらしい。
この場合こちらのプロジェクトの設定でリンクしてもいいのだが、libでやってしまうのがスマート。やり方は、ライブラリアンの追加の依存ファイルでlibを指定する。利用する側はほんの少し(笑)楽になる。

スクリーンショット 2013-11-20 19.40.53

以上が今回やったライブラリの作成手順。手探りでやってるので正しいのかはわからないけど。ようやくwindowsで開発していたものを両方で動かすための環境が整った。
VisualStudioは毎度こういうので疲れる・・・\(^o^)/

harfbuzzでAlabia語レンダリング

今回はRTLのレンダリングをやってみた。右寄せではなく、Right to Left、つまり右から左に書くarabia語などのレンダリングなど。(「はちにんこ」、みたいな。)

普通に hb_buffer_set_direction( buffer, HB_DIRECTION_LTR ); でやればいいだけなんだけど。この指定を行った場合、普通にイテレーションすると、文末から順番に表示されることになる。普段のLTRのロジックでレンダリングした場合は左寄せになる。改行もいれると、文末から文頭へと表示されて、一応RTLになってるんだけど、基準点によるレンダリングが難しい。(boundingboxを計算しているが2回計算することになり効率が悪い。)

そこで、レンダリングロジックでリバースイテレーションすると、右寄せになり、改行順も正しくなる。注意点はレンダリングとペンの位置の計算順。

LTRの場合は :  レンダリング( PenX+OffsetX ) -> ペン移動( PenX += AdvanceX )
の順で描画を行っていくが、リバースの場合はAdvanceXが示す値がそのキャラクター自身のPEN移動となる。
よってRTLの場合は :  ペン移動( PenX -= AdvanceX ) -> レンダリング( PenX+OffsetX )
このようにレンダリングすることで右寄せとなり、正確に表示された。

ここまででharfbuzzのLTRは完了。日本語や英語についてはリガチャも含めて綺麗に表示された。次にアラビア語を入れてみる。表示結果は以下のとおり。アラビア語でググって出てきた文章なのでなんて書いてあるかは知らない(過激な言葉だったらどうしよう)そして、これがぜんぜん正しいのかも分からないけど、元のタイポグラフィと比べるとおかしい。

スクリーンショット-2013-11-15-11a.46

テキストレイアウトでは色々必要とされる機能があってそれが各言語によって用意されている。これらはiso15924のタグで用意されていて、harfBuzzでもこのコードからスクリプトを適用することができる。
http://www.microsoft.com/typography/otspec/scripttags.htm
アラビア語を指定する場合は
hb_buffer_set_script(buffer,HB_SCRIPT_ARABIC);
これは、hb-common.hで定義されている。この指定を行うと、下記の通り。バラバラだった文字が組み合わされ、それっぽくなった。これは単純なリガチャではなく、合字のような機能だと思う。スクリプトは標準ではLatin用とかになってるのかなー。

スクリーンショット-2013-11-15-11.46

hb_buffer_guess_segment_propertiesみたいなのもあるんだけどうまくは行かなかった。
それで、今回は混合フォントのレンダリングクラスを書いているんだけど、フォント毎に”arab”とかiso15924を調べて指定するのはなんか面倒。なんとかフォントファイルからscript tagを調べられないかと、色々試行錯誤してみた。

まずはどこにタグがあるのかを調べる。
http://kanji-database.sourceforge.net/fonts/opentype.html
これによると
GSUB、GPOS、JSTFの第一層にある。まだ、頭のなかにopentypeの構造がぼんやりとしかイメージできていないので、どこやねんそれと思いながら試行錯誤してみた。結果、こんなかんじでよさげだなぁと。自信はないけど。

unsigned int cntGSUB = hb_ot_layout_table_get_script_tags(face, HB_OT_TAG_GSUB, 0, NULL, NULL);
hb_tag_t* listGSub = NULL;
listGSub = (hb_tag_t*) malloc(cntGSUB * sizeof(hb_tag_t));
hb_ot_layout_table_get_script_tags(face, HB_OT_TAG_GSUB, 0, &cntGSUB, lstGSub);
hb_script_t script = hb_script_from_iso15924_tag(*lstGSub);
free(listGSub);

大概のフォントは複数のスクリプト値が入っている。秀英体とかだと6ことか入ってたりする。で、どれを初期値にするのかというのが問題になるんだけど、どうやら一番はじめのものがデフォルトレイアウトとして使えそう。アラビア語の traditional arabicフォントも一番目に HB_SCRIPT_ARABIC が入っていた。上の例はHB_OT_TAG_GSUBだけだけど、GPOSのみということもありえるのでJSTFも含めて調べておく必要がある。それで取れなければHB_OT_TAG_INVALIDとかにしておけば、上手いことやってくれそうな気がした。

リガチャー処理 (harfbuzz + freeType)

リガチャーが実装できた。

freeTypeありきで実装していたから色々勘違いがあったが、ようやく理解できた。手順をおさらいしておく。

簡単に言うとFreeType自体はあくまでFontFaceを弄るものだから、文字の組み合わせによって整形されるリガチャーの判断はできるわけがなく。文章を表示する場合harfbuzzでグリフのコードポイントを取得することになるのであるが、この時点でリガチャのコードポイントが返ってくる。よってFreeTypeにおいてはhb_glyph_info_t から取得したグリフ位置で表示を行えリガチャ表示が可能となる。

リガチャはデフォルトで有効になっているようだが、下記のように指定できる。
hb_feature_t feature= {HB_TAG(‘l’,’i’,’g’,’a’),1,0,static_cast<unsigned>(-1)};

リガチャーキャラクタは複数文字をひとまとめにして表示するため、hb_buffer_get_lengthが戻す値は実際の文字長よりも短くなる。カーニング値も2文字(or 3文字)分のアドバンスが確保される。リガチャの判断は次のhb_glyph_info_tポインタ のcluster値がジャンプするかどうかで行える。混合フォントを設計していたため、文字のポインタが取りづらく処理が複雑になったが、クラスタをもとにカウンティングを行うことで実現できた。

いざ自分でやってみると、普段何気なく見ているPC上のテキストがだいたいリガチャー効いててスゲーってなった。先は長い・・・。