🌘 📡 🏐 OpenGL ES 3.0のSSAO 🐯 📥 😲

ある日、効果のある次のデモを見て、疑問が生じました：モバイルデバイスでSSAOを作成して、見た目が遅くならないようにすることは可能ですか？
Galaxy Note 3 n9000（mali T62）がデバイスとして採用されました。目標はFPSが30以上であり、品質は上の図のようになります。

この効果については詳しく説明しませんが、読者は他のソース（ wikiまたはsteps3d ）から効果について学ぶことができると想定されています。この記事ではモバイルプラットフォームへの適応に重点を置いていますが、「Varieties of SSAO」セクションで簡単なレビューが行われます。

SSAOはパフォーマンスの面で非常に大食いの効果であると同時に、平均的なユーザーにはまったく見えないので、モバイルデバイスではまだ見ていません。さらに、それを加速するには、 MRTサポートが必要です。これは、OpenGL ESバージョン3.0でのみ登場しました。

SSAOの種類

アルゴリズムの主なアイデアは、空間内のサーフェスポイントのシェーディングを決定することです。特定の半径内のこのポイントのシャドウイングの程度を決定するために、オブジェクトの存在がチェックされ、オブジェクトの近くにあるほど、ポイントがシェーディングされます。

もちろん、3次元空間のサーフェス上の各ポイントのシェーディングを計算することは不可能であるため、アルゴリズムのすべての作業は画像空間で実行されます（そのため、 画面空間アンビエントオクルージョンと呼ばれます）。つまり、画面上のピクセルは表面上の点として機能します（実際、必ずしも画面上ではなく、SSAOバッファーのサイズは画面サイズよりも小さいことが多いため、フレームまたはフレーム内のピクセルを言う方がより正確です）。また、近隣の空間のすべてのポイントの値を処理することは不可能です。したがって、通常は、問題のポイントから特定の半径内のランダムなポイントの小さな選択に制限されます。

最も単純な実装では、深度バッファはシェーディングを計算するのに十分です-そのため、問題のピクセルのz座標は、この差に基づいてサンプルのピクセルのz座標と比較され、シェーディングが考慮されます。

ただし、上の図を見ると、ポイントの下のサーフェス自体もシェーディングに独自の（「役に立たない」）貢献をしていることがわかります。その結果、画像はグレートーンで取得されます。つまり、シェーディングがないはずです。次のようになります。

これを回避するには、深度に関する情報に加えて、この時点での法線に関する情報も必要です。これを行うには、シーンのレンダリング中に、色に加えて、別の通常のバッファーにも書き込まれます。それらを指定すると、サンプルからポイントの位置を変更して、「有用な」貢献をすることができます。これは、問題のポイントの法線とサンプルのポイントの法線との間の角度に基づいて行われます。角度（角度）が90°より大きい場合-サンプルの法線が反転し、それに基づいてポイントが再計算されますアルゴリズムのこのような変更は、必要な場所にのみシェーディングを提供しますが、深刻な欠点があります-サンプルからの各ポイントについて、深度バッファーからの読み取りに加えて、法線のテクスチャからの追加読み取りが表示されます。また、SSAOのボトルネックはさまざまなバッファーからの大量の読み取りであり、これらの読み取りはランダムな順序で行われます。これはキャッシュを強制終了します。特にモバイルデバイスで。

別の修正は、球体を近傍として使用するのではなく、サンプルからの点が位置する半球を使用することを意味します。この場合、検討中のポイントの法線に沿ってこの球を方向付ける必要があります。

この場合、サンプルから各ポイントの法線を読み取る必要はありません。すべてのポイントが既にあるはずなので、問題のポイントの法線を取得するだけで十分です。

私の意見では、これが最良の修正であり、適用可能です。

実装

まず、法線、深度、色を保存するためのバッファが必要です。 OpenGL ES 3.0のテクノロジー-複数のレンダーターゲットを使用し、複数のバッファーを作成して、同時に書き込みます。コードでは、次のようになります（テクスチャ作成は別の関数として作成しました）：

// ,        (  ),     GLenum buffers[] = {GL_COLOR_ATTACHMENT0, GL_COLOR_ATTACHMENT1}; GLuint fbo; GLuint colorBuff; GLuint normBuff; GLuint depthBuff; //     void createTexture(GLuint &id, int inFormat, int w, int h, int format, int type, int filter, int wrap, void* pix=NULL) { glGenTextures(1, &id); glBindTexture(GL_TEXTURE_2D, id); glTexImage2D(GL_TEXTURE_2D, 0, inFormat, w, h, 0, format, type, pix); glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, filter); glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, filter); glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, wrap); glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, wrap); } ... glGenFramebuffers(1, &fbo); //   glBindFramebuffer(GL_FRAMEBUFFER, fbo); // width  height -   createTexture(colorBuff, GL_RGB8, width, height, GL_RGB, GL_UNSIGNED_BYTE, GL_NEAREST, GL_MIRRORED_REPEAT); createTexture(normBuff, GL_RGB8, width, height, GL_RGB, GL_UNSIGNED_BYTE, GL_NEAREST, GL_MIRRORED_REPEAT); createTexture(depthBuff, GL_DEPTH_COMPONENT24, width, height, GL_DEPTH_COMPONENT, GL_UNSIGNED_INT, GL_NEAREST, GL_MIRRORED_REPEAT); //    ,        glFramebufferTexture2D(GL_FRAMEBUFFER, GL_COLOR_ATTACHMENT0, GL_TEXTURE_2D, colorBuff, 0); glFramebufferTexture2D(GL_FRAMEBUFFER, GL_COLOR_ATTACHMENT1, GL_TEXTURE_2D, normBuff, 0); glFramebufferTexture2D(GL_FRAMEBUFFER, GL_DEPTH_ATTACHMENT, GL_TEXTURE_2D, depthBuff, 0); int err = glCheckFramebufferStatus(GL_FRAMEBUFFER); if (err != GL_FRAMEBUFFER_COMPLETE) LOGE("Main framebuffer error: %i", err); glDrawBuffers(2, buffers);

さらに同様の方法ですが、1つのテクスチャを使用して、SSAOの下にバッファを作成する必要があります。

SSAOの下のバッファー

 glGenFramebuffers(1, &ssaoFbo1); glBindFramebuffer(GL_FRAMEBUFFER, ssaoFbo1); //     ,     ,    GL_R8 createTexture(ssaoBuff1, GL_R8, width/ssaoScaleW, height/ssaoScaleH, GL_RED, GL_UNSIGNED_BYTE, GL_LINEAR, GL_MIRRORED_REPEAT); glFramebufferTexture2D(GL_FRAMEBUFFER, GL_COLOR_ATTACHMENT0, GL_TEXTURE_2D, ssaoBuff1, 0); // glDrawBuffers   ,

このバッファは小さいかもしれませんが、今のところは画面解像度と同じにしましょう（私の場合は1920x1080）。

z-bufferについても言う必要があります。 SSAOで使用するには、最初に線形にする必要があります。そうしないと、中間およびバックグラウンドで精度が大幅に失われます。通常、このために、深度値は、通常の法線と一緒に、別のバッファに書き込まれます。ただし、追加のバッファーはパフォーマンスの点でうまく機能しないため、値を線形化して別のバッファーに書き込むのではなく、現在の標準深度バッファー（gl_FragDepth）に直接書き込みます。これにより、前景にアーティファクト（非常に近く、ほぼ正面のクリッピングプレーンの近く）が発生する可能性がありますが、基本的にこのようなバッファーは非常に正常に動作します。

シーンは通常どおりレンダリングされますが、唯一の違いは色のほかに法線も記録し、深度バッファをわずかに変更することです。シーンレンダリング用の頂点シェーダー：

 #version 300 es uniform mat4 matrixProj; uniform mat4 matrixView; uniform vec3 lightPos; layout(location = 0) in vec3 vPos; //   layout(location = 1) in vec3 nPos; //  layout(location = 2) in vec3 tPos; //     layout(location = 3) in vec2 tCoord; //   out vec3 light; out vec3 gNorm; out float zPos; out vec2 texCoord; void main() { vec4 p = matrixProj*matrixView*vec4(vPos, 1.0); gl_Position = p; texCoord = tCoord; //      ,           vec3 bitangent = cross(tPos, nPos); mat3 tbn = mat3(tPos, bitangent, nPos); light = normalize(lightPos-vPos)*tbn; zPos = pz; //  z-  -      vec4 n = (matrixView*vec4(nPos, 0.0)); //      gNorm = normalize(n.xyz); }

フラグメントシェーダー：

 #version 300 es precision highp float; //      24- ,     ,     24 ,       uniform sampler2D texDiff; //   uniform sampler2D texNorm; //       layout(location = 0) out vec3 colorBuff; //    layout(location = 1) out vec3 normBuff; //   in vec3 light; in vec3 gNorm; in float zPos; in vec2 texCoord; const vec3 ambientColor = vec3(0.3); const float zFar = 40.0; //    void main() { vec3 n = normalize(texture(texNorm, texCoord).xyz*2.0-1.0); vec3 l = normalize(light); vec3 c = texture(texDiff, texCoord).rgb; float a = clamp(dot(n, l), 0.0, 1.0); colorBuff = c*(a+ambientColor); //   normBuff = normalize(gNorm)*0.5+0.5; //   gl_FragDepth = zPos/zFar; //       }

また、半球内のランダムポイントの配列（実際の選択）も必要です。シェーディングを美しくするために（いわば、より物理的に）-半球内のポイントの密度は、中央では高く、境界では低くする必要があります。つまり、正規分布の法則を持つことです。

 for (int i=0; i<samples; i++) { rndTable[i] = vec3(random(-1, 1), random(-1, 1), random(-1, -0)); //    ( ) rndTable[i].normalize(); //   rndTable[i] *= (i+1.0f)/samples; //  ( ) }

もちろん、サンプル内のポイントの数はそれほど多くありません。ここまでで10に等しくします。

ただし、このような擬似乱数値のサンプルでは十分ではありません。これらの値は同じフラグメント内でのみランダムであり、次のフラグメントはわずかなバイアスはありますが同じポイントを取ります。この欠点を解消するために、彼らは通常、疑似ランダム値を持つ小さなテクスチャー（約4x4ピクセル）を使用します。これで、各フラグメントで、このテクスチャから値を取得し、それに基づいて半球ポイントの回転行列をコンパイルできます。そして同時に、それらを法線に対して回転させます。これはすでに法線のテクスチャから読み取られます。したがって、結果のマトリックスでポイントを乗算し、それらを同時に法線に対して方向付け、疑似ランダムベクトルによって回転させます。このような行列の構築は、グラムシュミット過程と呼ばれます。

シェーダーでは、次のようになります。

 vec3 normal = texture(normBuff, texCoord).xyz*2.0-1.0; vec3 rvec = texture(randMap, texCoord*scr).xyz*2.0-1.0; vec3 tangent = normalize(rvec-normal*dot(rvec, normal)); vec3 bitangent = cross(tangent, normal); mat3 rotate = mat3(tangent, bitangent, normal);

また、空間内のポイントの座標を復元する必要があります。これを行うには、画像空間内のポイントの座標に透視変換の逆行列を掛けるか、またはより簡単に行うことができます：現在のピクセルを介してカメラから向けられたベクトル（光線）にこのピクセルのz座標値を掛けます。 Z座標は深度バッファーに格納され、カメラからのビームは視野角に基づいて構築されます。視野角は、透視行列（投影行列）の構築に使用されます-これはfovです。ユニフォームを保存することにし、この値を定数として頂点シェーダーに入力しました。

 #version 300 es const fov = 0.57735; layout(location = 0) in vec2 vPos; layout(location = 1) in vec2 tCoord; uniform float aspect; out vec2 texCoord; out vec3 viewRay; void main() { gl_Position = vec4(vPos, 0.0, 1.0); texCoord = tCoord; viewRay = vec3(-vPos.x*aspect*fov, -vPos.y*fov, 1.0); //   ,      }

ピクセルシェーダーでは、レイに基づくポイントの位置が次のように復元されます。

 float depth = texture(depthBuff, texCoord).x; //    ,   depth *= zFar; //  z- vec3 pos = viewRay*depth; //

回転行列とポイントの位置を受け取ったら、サンプルからシェーディング値を取得することができます。

 float acc = 0.0; for (int i=0; i<samples; i++) { vec3 samplePos = rotate*rndTable[i]; //  samplePos = samplePos*radius+pos; //        //          ,            vec4 shift = proj*vec4(samplePos, 1.0); shift.xy /= shift.w; shift.xy = shift.xy*0.5+0.5; //   z- float sampleDepth = texture(depthBuff, shift.xy).x*zFar; //       -      .     ,       ,   smoothstep,   -   float distanceCheck = smoothstep(0.0, 1.0, radius/abs(pos.z-sampleDepth)); //       -     .  - ,    step acc += step(sampleDepth, samplePos.z)*distanceCheck; }

結果はぼやける可能性があるため、ガウスぼかし用に別のバッファを作成します。サンプルの数を少なくし、最終的にはテクスチャの最上部にある単なる影にするため、アーティファクトはあまり目立たないはずです。ここで、キャッシュはすでに私たちの側にあります。SSAOでのランダムな読み取りの場合、キャッシュミスが常に発生する場合、テクスチャからのサンプルは適切にキャッシュされるはずです。

垂直ぼかしシェーダー

 #version 300 es precision mediump float; uniform sampler2D ssaoBuff; layout(location = 0) out float outColor; in vec2 texCoord; const float blurSize = 2.5/1920.0; void main() { float sum = 0.0; sum += texture(ssaoBuff, vec2(texCoord.x, texCoord.y - 2.0*blurSize)).r * 0.0625; sum += texture(ssaoBuff, vec2(texCoord.x, texCoord.y - blurSize)).r * 0.25; sum += texture(ssaoBuff, vec2(texCoord.x, texCoord.y )).r * 0.375; sum += texture(ssaoBuff, vec2(texCoord.x, texCoord.y + blurSize)).r * 0.25; sum += texture(ssaoBuff, vec2(texCoord.x, texCoord.y + 2.0*blurSize)).r * 0.0625; outColor = sum; }

水平ぼかしシェーダー

 #version 300 es precision mediump float; uniform sampler2D ssaoBuff; layout(location = 0) out float outColor; in vec2 texCoord; const float blurSize = 2.5/1080.0; void main() { float sum = 0.0; sum += texture(ssaoBuff, vec2(texCoord.x - 2.0*blurSize, texCoord.y)).r * 0.0625; sum += texture(ssaoBuff, vec2(texCoord.x - blurSize, texCoord.y)).r * 0.25; sum += texture(ssaoBuff, vec2(texCoord.x, texCoord.y)).r * 0.375; sum += texture(ssaoBuff, vec2(texCoord.x + blurSize, texCoord.y)).r * 0.25; sum += texture(ssaoBuff, vec2(texCoord.x + 2.0*blurSize, texCoord.y)).r * 0.0625; outColor = sum; }

結果を見ることができます：

左上隅の数字は、1秒あたりのフレーム数を示しています。あまりない。さらに、表面の縞模様にも注意してください。問題は、深度バッファを表す際に、表面が完全に滑らかではないことです。ここではすべてが完全に分離されており、表面は梯子のように見えるため、サンプルのポイントの一部はこれらの「ステップ」内にあるように見えます。

したがって、サンプルを作成するときは、ゼロのZ座標からではなく、たとえば0.1などの小さな値から開始することをお勧めします。この場合、半球は下から切り取られたようになります。

そして、サンプルからのポイントは「ステップ」に分類されません。写真は良くなります：

しかし、FPSはまだ高くありません。

最適化

明白で最も一般的な解決策は、サンプル内のポイント数を減らし、SSAOバッファーのサイズを小さくすることです。バッファーサイズを半分にすると、FPSが約150％増加します。ただし、バッファーのサイズを変更すると、オブジェクトの境界でアーティファクトが発生するため、大幅に削減することはありません。

アルゴリズムの結果を見てください。画像のほとんどが白で、シェーディングがまったくないことがわかります。ただし、アルゴリズムはピクセルごとに満たされます。不要な断片をカットできるようなマスクを作成するとよいでしょう。
このマスクは、より小さいバッファーのSSAOを大まかに計算することで取得できます。つまり、別のバッファーを作成します。たとえば、SSAOのバッファーの16倍の幅と高さです。サンプルの数を5に減らして、ランダムではなく、半球の中心から同じ距離に配置します。

 for (int i=0; i<samplesLow; i++) { float angle = DEG2RAD*360.0f*i/samplesLow; rndTableLow[i] = vec3(sinf(angle), cosf(angle), -0.1); }

シャドウがスムーズに移行しないマスクが必要なので、結果を非常に対照的にします-ピクセルは黒または白です：

 outColor = step(254.0/255.0, 1.0-(acc/float(samples)));

ブラーシェーダーも簡素化され、2つのフラグメントシェーダーではなく、正方形の角に4つのサンプルがあるシェーダーになります。

 #version 300 es precision mediump float; uniform sampler2D ssaoLowBuff; uniform float aspect; layout(location = 0) out float outColor; in vec2 texCoord; const float blurSize = 0.01; void main() { float sum = 0.0; sum += texture(ssaoLowBuff, vec2(texCoord.x - blurSize, texCoord.y - blurSize*aspect)).r; sum += texture(ssaoLowBuff, vec2(texCoord.x - blurSize, texCoord.y + blurSize*aspect)).r; sum += texture(ssaoLowBuff, vec2(texCoord.x, texCoord.y )).r; sum += texture(ssaoLowBuff, vec2(texCoord.x + blurSize, texCoord.y - blurSize*aspect)).r; sum += texture(ssaoLowBuff, vec2(texCoord.x + blurSize, texCoord.y + blurSize*aspect)).r; outColor = step(254.0/255.0, sum/5.0); }

このマスクを取得します。

それを使用して、SSAOを計算します（バッファーサイズを1.5倍に減らし、サンプル数を8に減らしました）。

その結果、FPSは品質を視覚的に損なうことなく3倍になりました。この方法には欠点があります-シーン内に多くの角度または他のシェーディング場所がある場合、マスクはほぼ完全に黒くなります。これは、そのような最適化の有効性が大幅に低下することを意味します。
完全なSSAOフラグメントシェーダーコード：

 #version 300 es precision highp float; //  24-   const int samples = 8; //   const float radius = 0.5; //   const float power = 2.0; //   const float zFar = 40.0; //    uniform sampler2D normBuff; //   uniform sampler2D depthBuff; //   uniform sampler2D randMap; //      uniform sampler2D ssaoMask; //  SSAO -  uniform vec2 scr; //    randMap,     SSAO uniform vec3 rndTable[samples]; //  uniform mat4 proj; //   layout(location = 0) out float outColor; //   in vec2 texCoord; //   in vec3 viewRay; //    void main() { //      ,    -   float k = texture(ssaoMask, texCoord).x; if (k==1.0) discard; //          -  float depth = texture(depthBuff, texCoord).x; if (depth==1.0) discard; depth *= zFar; vec3 pos = viewRay*depth; vec3 normal = texture(normBuff, texCoord).xyz*2.0-1.0; vec3 rvec = texture(randMap, texCoord*scr).xyz*2.0-1.0; vec3 tangent = normalize(rvec-normal*dot(rvec, normal)); vec3 bitangent = cross(tangent, normal); mat3 rotate = mat3(tangent, bitangent, normal); float acc = 0.0; for (int i=0; i<samples; i++) { vec3 samplePos = rotate*rndTable[i]; //  samplePos = samplePos*radius+pos; //        //          ,            vec4 shift = proj*vec4(samplePos, 1.0); shift.xy /= shift.w; shift.xy = shift.xy*0.5+0.5; //   z- float sampleDepth = texture(depthBuff, shift.xy).x*zFar; //       -      .     ,       ,   smoothstep,   -   float distanceCheck = smoothstep(0.0, 1.0, radius/abs(pos.z-sampleDepth)); //       -     .  - ,    step acc += step(sampleDepth, samplePos.z)*distanceCheck; } outColor = pow(1.0-(acc/float(samples)), power); //   }

テクスチャ付きオブジェクトとのスクリーンショットの比較

デモ付きのビデオ（SSAOサイズは画面の2倍）：

（SSAOサイズは画面の1.5倍です）：

微妙

その過程で、私はいくつかの興味深いことに出くわしましたが、少し話題に合わないので、ネタバレの下に隠しました。

バイトオーダー

テクスチャとモデル用のコンバーターを作成したとき、ARMプロセッサーではバイト順が x86 と異なるという事実に直面しました。したがって、バイナリファイルに書き込む場合、1バイトを超える長さのすべてのデータタイプでは、後でデバイスでこれを行わないように、バイト順を逆にすることをお勧めします。
このために、私は関数を使用しました：

uint32_t htonl（uint32_t hostlong）;
uint16_t htons（uint16_t hostshort）;

たとえば、バイト順が変更されたいくつかの値のファイルへの出力（Qtを使用）：

 #include <netinet/in.h> ... QDataStream out(&file); out << htons(s); //     unsigned short out << htonl(*((unsigned int*)&f)); //     float

分数セパレーター

地域の設定とオペレーティングシステムに応じて、sscanf関数は浮動小数点数の解釈が異なる場合があります。ドットを使用して小数部と整数部を区切ることができ、どこかでコンマを使用できます。
例：

 readed1 = sscanf("float: 1,5", "float: %f", &f); readed2 = sscanf("float: 1.5", "float: %f", &f);

readed1とreaded2の値は、システムによって異なる場合があります。通常、これらの設定はオペレーティングシステムの地域設定で設定されます。これは、たとえば* .objファイルのパーサーを作成する場合に考慮する必要があります。

ログオーバーフローブレーキ

logcatを使用する場合は、Androidのログをクリアすることを忘れないでください。少なくともNote 3 n9000では、大量の情報がログに出力されると（毎秒、現在のフレームレートをそこに書き込んだ）、すべてがひどく遅くなり始めます。長い間、ログを消去するまで（adb logcat -cコマンド）、何が起こっているのか理解できませんでした。

異なるGPU

シェーダーを作成したら、異なるGPUを持つ複数のデバイスでテストするとよいでしょう。上記のSSAOシェーダーコードはmaliでは正常に機能しますが、adreno（特に320および330）ではバグがあります。（少なくともes 300シェーダーバージョンでは）adrenoが正しく機能しなかったことがわかりました。これ以上正確に言うことはできませんが、カウンターはインクリメントされますが、同じ反復がサイクルで機能するようです。シェーダーコードを少し変更し、ループを取り除く必要がありました。

 ... float getSample(in int i, in mat3 rotate, in vec3 pos, in vec3 rnd) { vec3 samplePos = rotate*rnd; samplePos = samplePos*radius+pos; vec4 shift = proj*vec4(samplePos, 1.0); shift.xy /= shift.w; shift.xy = shift.xy*0.5+0.5; float sampleDepth = texture(depthBuff, shift.xy).x*zFar; float distanceCheck = smoothstep(0.0, 1.0, radius/abs(pos.z-sampleDepth)); return step(sampleDepth, samplePos.z)*distanceCheck; } void main() { ... float acc = 0.0; acc += getSample(0, rotate, pos, rndTable[0]); acc += getSample(1, rotate, pos, rndTable[1]); acc += getSample(2, rotate, pos, rndTable[2]); acc += getSample(3, rotate, pos, rndTable[3]); acc += getSample(4, rotate, pos, rndTable[4]); acc += getSample(5, rotate, pos, rndTable[5]); acc += getSample(6, rotate, pos, rndTable[6]); acc += getSample(7, rotate, pos, rndTable[7]); outColor = pow(1.0-(acc/float(samples)), power); }

ひどいように見えますが、そのような奇妙な振る舞いの理由を誰かが知っている場合は、コメントまたはPMに書いてください。

NDKプロジェクトのIDEとしてのQtCreator

個人的には、特にNDKで書いているので、EclipseやAndroid StudioよりもQtCreatorが好きです。したがって、通常Eclipseでプロジェクトを作成し、QtCreatorに転送します。誰かが興味を持っている場合、プロジェクト転送プロセスは次のとおりです。
Qt Creatorを開き、[ファイル]-> [新しいファイルまたはプロジェクト...]-> [プロジェクトのインポート]-> [既存のプロジェクトのインポート]

スクリーンショット

次に、プロジェクトの名前を入力し、作成済みのプロジェクトへのパスを示します。コマンドラインから Eclipseでプロジェクトを作成し、 NDKのサポートを追加する公式ドキュメントで、Android用のプロジェクトを作成する方法について読むことができます。

スクリーンショット

その後、プロジェクトツリーに表示するファイルを選択し、実際にプロジェクトを作成します。 Qt Creatorはこれらのファイルを自動的に作成します。
MyProject.config-ここでは、コンパイル用の差分を指定できます。たとえば、NEONをサポートするために、＃define __ARM_NEON__という行を追加しました
MyProject.files-プロジェクトツリーに関連するすべてのファイル
MyProject.includes-ここでは、プロジェクトで使用されるライブラリインクルードへのパスを指定する必要があります。次に例を示します。

 /home/torvald/android-ndk-r9/sources/android/cpufeatures /home/torvald/android-ndk-r9/sources/cxx-stl/stlport/stlport /home/torvald/android-ndk-r9/sources/cxx-stl/gabi++/include /home/torvald/android-ndk-r9/toolchains/arm-linux-androideabi-4.6/prebuilt/darwin-x86_64/lib/gcc/arm-linux-androideabi/4.6/include /home/torvald/android-ndk-r9/toolchains/arm-linux-androideabi-4.6/prebuilt/darwin-x86_64/lib/gcc/arm-linux-androideabi/4.6/include-fixed /home/torvald/android-ndk-r9/platforms/android-18/arch-arm/usr/include /home/torvald/android-ndk-r9/toolchains/arm-linux-androideabi-4.6/prebuilt/linux-x86_64/lib/gcc/arm-linux-androideabi/4.6/include/ /home/torvald/android-ndk-r9/toolchains/arm-linux-androideabi-4.6/prebuilt/linux-x86_64/lib/gcc/arm-linux-androideabi/4.6/include/-fixed

プロジェクトのコンパイルとデプロイメントを制御する小さなスクリプトを作成することもできます。

 #!/bin/sh case "$1" in clean) ndk-build clean && ant clean ;; deploy) adb install -r bin/MainActivity-debug.apk > /dev/null 2>&1 & # && adb logcat -c && adb logcat -s "SSAOTest" #      Qt Creator -    ;; run) #adb shell am start -n com.torvald.ssaotest/com.torvald.ssaotest.MainActivity > /dev/null 2>&1 & ;; *) #kill $(ps aux | grep "adb logcat" | grep -v "grep" | awk '{print $2}') > /dev/null 2>&1 & ndk-build NDK_DEBUG=0 -j9 && ant debug ;; esac

[プロジェクト]タブで、このスクリプトは適切なアクションに割り当てられます。

スクリーンショット

以上で、標準のQt Creatorツールを使用してプロジェクトをクリーンアップし、ビルドしてデバイスにアップロードできます。構文強調表示、オートコンプリート、およびGLSLおよびC ++のその他の機能。

デモ

AndroidにOpenGL ES 3.0を搭載したデバイスがある場合は、アプリケーションを実行してみてください。 GUIで時間を無駄にしないことに決めたので、特別な設定はなく、制御は画面上の条件付き領域によって実行されます。

スライドアップ/ダウン-ズームイン/ズームアウト
出力バッファーを変更します（ssao、low ssao、ssao + color、colorのみ）
オン/オフぼかし
シーンの変化

無料の画面領域-カメラの回転

設定したパラメーターは次のとおりです。

サンプル数= 8。
ssaoおよびblurバッファーのサイズは、画面の解像度の1.5倍です。
削減されたssaoのサンプル数= 5。
縮小ssaoバッファーのサイズは、画面解像度の16倍小さくなります。

ソースコード -パスを変更することを忘れないでください
apk -Note 3 n9000（mali T62）、Note 3 n9005（adreno 330）、Nexus 5（adreno 330）、HTC One（adreno 320）でテスト済み

参照資料

このプロジェクトで役立つさまざまなリファレンス：steps3dの
Screen-Space Ambient Occlusion。SSAOを作成する方法はいくつか
のOpenGL ES 3.0 APIリファレンスカード -への簡単なガイドをOpenGL ESの3.0 SPECA
半球状のスクリーン空間アンビエントオクルージョン -半球状のSSAO実装する1つの方法
ストーンブリッジ3Dモデルを -私は、デモで使用されることを橋のモデル
ジョン・チャップマン・グラフィックス：SSAOチュートリアル -私の意見では、半球SSAOの最適な実装
SSAO |
デプスバッファーのゲームレンダリング攻撃 -
ゲーム開発者向けの zバッファー線形代数のさまざまなビュー
SSAOアーティファクトを知る -SSAOのアーティファクト/ジャム/不正確性およびそれらの除去方法

OpenGL ES 3.0のSSAO

SSAOの種類

実装

最適化

微妙

デモ

参照資料

More articles: