OpenGL ES: 概要、アーキテクチャ、応用

OpenGL ESとは？

OpenGL ES（組み込みシステム向けOpen Graphics Library）は、モバイルデバイス、ゲームコンソール、組み込みシステムに適応したデスクトップOpenGL APIのサブセットです。仕様はKhronos Groupコンソーシアムによって開発され、すべてのメーカーに無料で提供されています。デスクトップOpenGLとは異なり、OpenGL ESは固定機能パイプラインのレガシー機能を削除し、プログラム可能なシェーダーパイプラインのみを残します。これにより、消費電力が削減され、ドライバーが簡素化されます。

OpenGL ESの主な適用分野は、リアルタイムグラフィックスのレンダリングです。このAPIは、モバイルゲーム（Unity、Unreal Engine）、ナビゲーションアプリ、ARCoreやARKitベースのARソリューション、さらにAndroidやiOSのシステムインターフェースで使用されています。StatCounter、2026によると、アクティブなスマートフォンのうちOpenGL ES 3.0+をサポートするデバイスの割合は92%を超えています。

OpenGL ESの主な利点はクロスプラットフォーム互換性です。OpenGL ESで書かれた同じアプリケーションは、最小限の変更でAndroid、iOS、Linux、Windowsで動作します。これにより、グラフィックスエンジンを書き換えることなく複数のプラットフォームを対象とするプロジェクトに最適なAPIとなっています。

固定機能 vs プログラム可能パイプライン

初期のOpenGLバージョン（2.0以前）は固定機能パイプラインを使用していました。これは、頂点とピクセル処理の事前定義された一連のステージです。開発者はパラメータ（光源の位置、マテリアルプロパティ、変換マトリックス）のみを設定できました。プログラム可能パイプラインはOpenGL ES 2.0で導入され、固定ステージをシェーダー（GPUで実行される小さなプログラム）に置き換えました。これにより、開発者はジオメトリのレンダリングを完全に制御できるようになりました。

プログラム可能パイプラインへの移行はモバイルグラフィックスにとって革命でした。開発者は複雑なエフェクトを実装できるようになりました：PBR（物理ベースレンダリング）、動的シャドウ、ポストプロセッシング、HDR。固定機能パイプラインはコード量が少なくて済みましたが、独自のビジュアルスタイルを作成することはできませんでした。最新のモバイルゲームは完全にプログラム可能パイプラインで動作しています。

OpenGL ESのアーキテクチャ：レンダリングパイプライン

グラフィックスパイプライン OpenGL ESは、頂点から画面上のピクセルに至るまでの経路で入力データを変換する、複数の連続したステージで構成されています。パイプラインアーキテクチャの理解は、エネルギーと熱の予算が限られたモバイルデバイスでのレンダリングパフォーマンスの最適化に不可欠です。

最初のステージである頂点シェーダーは、各頂点を独立して処理します。このステージでは、モデルのローカル空間からワールド空間、カメラ空間、そしてクリップ空間への変換が適用されます。変換は、カメラやオブジェクトが移動するたびに毎フレーム更新されるMVP（モデル-ビュー-プロジェクション）ユニフォーム行列を介して設定されます。

プリミティブの組み立て（点、線、三角形）の後、ラスタライゼーションが実行されます。これは、各プリミティブが画面のどのピクセルを覆うかを決定するプロセスです。ラスタライザーは、補間された属性（色、法線、UV座標）を持つフラグメント（潜在的なピクセル）を生成します。フラグメントの数は、画面の解像度とプリミティブの投影面積に直接依存します。

フラグメントシェーダーは生成された各フラグメントに対して実行されます。テクスチャ、光源、マテリアルを考慮して最終的なピクセル色を計算します。フラグメントシェーダーの出力は一連のフラグメント単位のテストを通過します：深度テストはフラグメントが可視かどうかを判定し、ステンシルテストはマスクによるレンダリングを制限し、ブレンディングはフラグメントの色をフレームバッファに既に書き込まれている色と混合します。

OpenGL ESコンテキストの状態

OpenGL ESはステートマシンとして動作します。すべての設定（現在のシェーダー、バインドされたテクスチャ、有効なテスト）はコンテキストのグローバル状態に保存されます。glEnable、glBindTexture、glUseProgramによる状態の変更は、後続のすべての描画コマンドに影響します。状態の切り替えはドライバーでオーバーヘッドを発生させるため、状態ごとに描画コールをグループ化することが主要な最適化手法です。

OpenGL ESのバージョンとその機能

OpenGL ES 1.0および1.1（2003〜2004年リリース）は固定機能パイプラインに基づいていました。変換、テクスチャリング、ライティング、ブレンディングをサポートしていましたが、シェーダーのプログラミングはできませんでした。このAPIは初期の携帯電話やSymbian、Windows Mobileベースのデバイスで使用されていました。現在これらのバージョンは非推奨とみなされており、最新のデバイスはサポートしていません。

OpenGL ES 2.0（2007年）は、GLSL ESによる頂点シェーダーとフラグメントシェーダーを備えたプログラム可能パイプラインを導入しました。このバージョンはAndroid 2.2+およびiOS 5+の標準となり、現在でも大多数のデバイスでサポートされています。OpenGL ES 2.0は、モバイルプラットフォームでUnity、Unreal Engine、Cocos2d-xを動作させるために必要な最小バージョンです。

OpenGL ES 3.0（2012年）は複数の重要な機能を追加しました：マルチプルレンダーターゲット（MRT）、トランスフォームフィードバック、インスタンシング、ETC2/EACによる任意フォーマットのテクスチャ。描画コールの数を削減することで、レンダリングパフォーマンスはバージョン2.0と比較して30〜50%向上しました。OpenGL ES 3.1（2014年）はコンピュートシェーダーとアトミックバッファ操作を導入し、GPUでグラフィックスだけでなくコンピュートタスク（ポストプロセッシング、布地シミュレーション、物理計算）も実行できるようになりました。

OpenGL ES 3.2（2015年）— 仕様の最新バージョン — はテッセレーションシェーダーとジオメトリシェーダー、さらに拡張されたフロートテクスチャとブレンドモードを追加しました。2016年によりモダンなVulkanがリリースされたにもかかわらず、OpenGL ES 3.2は膨大な既存コードベースとプラットフォーム間のアプリケーションポーティングの容易さから、今でも重要なAPIであり続けています。

OpenGL ESのシェーダー：GLSLとプログラム可能パイプライン

GLSL ES（組み込みシステム向けOpenGLシェーディング言語）は、C構文をベースに、ベクトルやマトリックスを扱うための追加型を備えたシェーダープログラミング言語です。各シェーダーは、アプリケーションの初期化時にGPUマシンコードにコンパイルされるプログラムです。CPUコードとは異なり、シェーダーは大量並列に実行され、数千の頂点やフラグメントが同時に処理されます。

頂点シェーダー

頂点シェーダーはメッシュの各頂点を処理します。その主な役割は、入力位置をMVP行列で乗算してクリップ空間での最終頂点位置を計算することです。さらに、頂点シェーダーは法線、UV座標、色を計算し、varying変数を介してフラグメントシェーダーに渡すことができます。各頂点シェーダーの呼び出しは独立して動作し、GPUは1フレームあたり数百万の頂点を処理できます。

// Simple vertex shader for OpenGL ES 3.0
#version 300 es
layout(location = 0) in vec4 a_position;
layout(location = 1) in vec3 a_normal;
layout(location = 2) in vec2 a_texCoord;

uniform mat4 u_mvpMatrix;

out vec3 v_normal;
out vec2 v_texCoord;

void main() {
    gl_Position = u_mvpMatrix * a_position;
    v_normal = mat3(u_mvpMatrix) * a_normal;
    v_texCoord = a_texCoord;
}

フラグメントシェーダー

フラグメントシェーダーは、画面上の各ピクセルの色を決定します。頂点シェーダーから補間されたvarying値を受け取り、バインドされたテクスチャからテクセルをサンプリングし、ライティングを適用します。正しいライティングには、拡散、鏡面、環境成分の計算を伴うフォンまたはブリン-フォンモデルが使用されます。各フラグメントシェーダーの呼び出しは1ピクセルに対応するため、呼び出しの総数は画面上のオブジェクトの投影面積と等しくなります。

// Simple fragment shader with texture and lighting
#version 300 es
precision mediump float;

in vec3 v_normal;
in vec2 v_texCoord;

uniform sampler2D u_texture;
uniform vec3 u_lightDir;

out vec4 fragColor;

void main() {
    vec4 texel = texture(u_texture, v_texCoord);
    vec3 normal = normalize(v_normal);
    float diffuse = max(dot(normal, u_lightDir), 0.0);
    fragColor = vec4(texel.rgb * diffuse, texel.a);
}

上記の例では、フラグメントシェーダーがUV座標で2Dテクスチャからテクセルをサンプリングし、法線と光の方向のドット積として拡散ライティングを計算し、テクセルの色にライティング強度を乗算しています。MediumpはモバイルGPUのフラグメントシェーダーに推奨される精度で、最小限の消費電力で十分な品質を提供します。

モバイルプロジェクトでOpenGL ESを始める方法

AndroidでOpenGL ESを使用するには、EGLコンテキスト（グラフィックスがレンダリングされるサーフェス）を作成する必要があります。iOSでは、GLKitフレームワークが提供するEAGLレイヤー（EGLに類似）が使用されます。どちらの場合も、初期化プロセスにはウィンドウサーフェスの作成、コンテキスト属性の設定、現在のレンダリングスレッドへのバインドが含まれます。

// OpenGL ES 3.0 initialization on Android
class MyGLRenderer : GLSurfaceView.Renderer {

    private val vertexShaderCode = "#version 300 es\n..."
    private val fragmentShaderCode = "#version 300 es\n..."

    override fun onSurfaceCreated(gl: GL10?, config: EGLConfig?) {
        GLES30.glClearColor(0.1f, 0.1f, 0.2f, 1.0f)
        GLES30.glEnable(GLES30.GL_DEPTH_TEST)
    }

    override fun onDrawFrame(gl: GL10?) {
        GLES30.glClear(GLES30.GL_COLOR_BUFFER_BIT or GLES30.GL_DEPTH_BUFFER_BIT)
        // bind VBO, set uniforms, draw elements
    }

    override fun onSurfaceChanged(gl: GL10?, width: Int, height: Int) {
        GLES30.glViewport(0, 0, width, height)
    }
}

コンテキスト作成後、開発者はバッファを設定する必要があります：頂点バッファ（VBO）には頂点座標、法線、UVが含まれ、インデックスバッファ（EBO）は三角形を形成するための頂点走査順序を定義します。VAO（頂点配列オブジェクト）はすべての属性設定を1つのオブジェクトに統合し、メッシュ切り替え時のAPI呼び出し回数を削減します。

EGLコンテキストのセットアップ

EGL（ネイティブプラットフォームグラフィックスインターフェース）は、OpenGL ESとウィンドウシステムの間の中間層です。Androidでは、EGLがレンダリングサーフェスの作成、フレームバッファ設定の選択（色深度、ステンシル、MSAA）、vsyncとの同期を管理します。一般的な設定では、24ビット深度バッファと8ビットステンシルバッファを備えたRGBA8888が要求されます。iOSでは、EGLの役割をEAGLがCAEAGLLayerと連携して果たします。

モバイルデバイスでのOpenGL ESのパフォーマンス最適化には、いくつかの重要なプラクティスがあります。多数の同一オブジェクトをレンダリングするにはインスタンシング（glDrawArraysInstanced）を使用します。これにより描画コール数が削減されます。テクスチャプールを適用し、描画コール間のテクスチャ切り替えを避けます。オブジェクトをシェーダー、テクスチャ、メッシュの順にソートします。この順序によりコンテキスト状態の切り替えが最小限になります。

OpenGL ES vs Metal vs Vulkan

MetalはAppleの低レベルグラフィックスAPIで、A7チップ以降のiOSおよびmacOSで利用可能です。Metalは最小限のドライバーオーバーヘッドでGPUへの直接アクセスを提供しますが、Appleデバイスでのみ動作します。WWDC 2024によると、Metalはランタイム状態チェックを削減することで、同じハードウェア上のOpenGL ESと比較して最大40%高いパフォーマンスを提供します。

VulkanはKhronos Groupによって開発されたOpenGL ESのクロスプラットフォーム後継です。Vulkanは明示的なリソース管理を使用します。開発者がメモリプールを割り当て、コマンドバッファを作成し、GPUアクセスを同期します。これによりパフォーマンスを最大限に制御できますが、Vulkanの初期化コードはOpenGL ESの3〜4倍の量になります。VulkanはAndroid 7+でのAAAゲームや要求の厳しいグラフィックスアプリケーションに推奨されます。

OpenGL ES、Metal、Vulkanの選択は、ターゲットプラットフォームとパフォーマンス要件によって異なります。OpenGL ESは、開発速度が重要なクロスプラットフォームプロジェクトに最適な選択肢です。Metalは最大のパフォーマンスを求めるiOS/macOSエコシステムに適しています。Vulkanは、1フレームあたりのミリ秒が重要で、開発予算が低レベルの最適化に投資できるプロジェクトの選択肢です。