OpenGL/OpenGL ES 入門: グラフィックス API と用語分析

OpenGL に初めて触れたとき、Apple の父親の放棄の問題にも注意を払いました.Apple の父親は OpenGL/Open LG ES を放棄したので、これを学んで何の役に立つのでしょうか?

1. Apple 自身のシステムが Metal に移行するのに 4 年かかりました. 2. Metal がリリースされる前に、Apple は OpenGL ES と高度に統合され、対応するレイヤーと GLKit と協力して、開発者が OpenGL を迅速に使用できるように支援しました. ES 3 と OpenGL ES の非推奨は、Apple の内部システムの基礎となる API への依存のためだけのものであり、iOS 開発者が OpenGL ES を決して使用しないという意味ではありません。ただ役割がサードパーティーになっただけで、やはりクロスプラットフォームで安定性が高いので既存の開発は諦めきれず、これらの点が現在のMetalでは難しいプロジェクトチームはすでに非常に大規模であり、とりあえずMetalに移行する予定なので、Metalだけを学ぶだけでは不十分. 5.したがって、OpenGL -> OpenGL ES -> Metalと段階的に学習する必要がある. これも個人的な経験であり、試してみた. GPUImageやOpenGL ESを学びたいけど使い方しか知らないけど原理がわからないので、まずは基礎をしっかり固めないといけない

この記事の目的

  • Graphics API の概要

  • OpenGL の専門用語をすばやく理解する

1. グラフィック API

1.1 グラフィック API の紹介

  • OpenGL (Open Graphics Library): クロスプログラミング言語およびクロスプラットフォーム プログラミング グラフィックス プログラム インターフェイスであり、コンピュータ リソースを OpenGL オブジェクトとして抽象化し、これらのリソースに対する操作を OpenGL 命令として抽象化します。

  • OpenGL ES (OpenGL for Embedded Systems): OpenGL 3D グラフィックス API のサブセットであり、携帯電話、PDA、ゲーム コンソールなどの組み込みデバイス向けに設計されており、多くの不要で低パフォーマンスの API インターフェイスが削除されています。

  • DirectX: 多くの API で構成されており、DirectX は純粋なグラフィックス API ではありません。最も重要なことは、DirectX が Windows 上のマルチメディア処理 API であることです。Windows 以外のプラットフォームはサポートしていないため、クロスプラットフォーム フレームワークではありません。性質によって分類すると、表示部、音声部、入力部、ネットワーク部の4つの部分に分けることができます。

  • Metal: Apple は、3D グラフィックスのレンダリング パフォーマンスを 10 倍高速化する、ゲーム開発者向けの新しいプラットフォーム テクノロジを発表しました。Metal は、Apple が 3D レンダリングを解決するために導入したフレームワークです。

1.2 グラフィック API の目的は何ですか?

簡単に言えば、グラフィックの根底にあるレンダリングを実現することです

  • たとえば、ゲーム開発では、ゲーム シーン/ゲーム タスクのレンダリング

  • たとえば、オーディオおよびビデオの開発では、ビデオのデコード後のデータ レンダリングに使用されます。

  • たとえば、マップ エンジンでは、マップ上のデータ レンダリング用に

  • たとえば、アニメーションでは、アニメーション描画を実現するために

  • たとえば、ビデオ処理では、ビデオにフィルター効果を追加します

本質: グラフィックス イメージを効率的にレンダリングするために GPU チップを使用することです.グラフィックス API は、iOS 開発者が GPU に近づく唯一の方法です.

2. OpenGLにおける専門用語の分析

2.1 OpenGL コンテキスト コンテキスト

  • アプリケーションが OpenGL 命令を呼び出す前に、OpenGL コンテキスト コンテキストを作成する必要があります。このコンテキストは、OpenGL 命令実行の基礎でもある OpenGL のさまざまな状態を保存する非常に大きなステート マシンです。

  • OpenGL 関数がどの言語に含まれていても、C 言語に似たプロセス指向の関数です. 本質的には、OpenGL コンテキストの巨大なステート マシン内の特定の状態またはオブジェクトで動作します. もちろん、最初にこのオブジェクト 現在のオブジェクトとして設定します。したがって、OpenGL 命令をカプセル化することで、OpenGL 関連の呼び出しをオブジェクト指向グラフィックス API にカプセル化することができます。

  • OpenGL コンテキストは巨大なステート マシンであるため、コンテキストを切り替えると大きなオーバーヘッドが発生することがよくありますが、異なる描画モジュールでは完全に独立した状態管理を使用する必要がある場合があります。したがって、複数の異なるコンテキストをアプリケーション プログラムで作成し、異なるコンテキストを異なるスレッドで使用でき、テクスチャやバッファなどのリソースをコンテキスト間で共有できます。このような解決策は、コンテキストを繰り返し切り替えたり、レンダリング状態を大量に変更したりするよりも合理的で効率的です。

2.2 OpenGL ステートマシン

  • ステート マシンは、理論的には、ライフ サイクル中にオブジェクトが通過するさまざまな状態、状態間の遷移、遷移を送信する原因と条件、および遷移中に実行されるアクティビティを記述するマシンです。つまり、ステート マシンは動作であり、ライフ サイクル中のイベントに応答してオブジェクトが通過する一連の状態と、それらの状態イベントへの応答です。次の特徴があります。

    • メモリー機能付きで、現在の状態を記憶可能

    • 入力を受け取り、入力内容と元の状態に従って現在の状態を変更し、対応する出力を持つことができます

    • 特殊な状態(停止状態)に入ると、入力を受け付けなくなります。つまり、動作を停止します。

  • コンピュータは典型的なステートマシンと言える

    • コンピュータのメモリ(メモリ、ハードディスクなど)は、コンピュータ自体の現在の状態を記憶できます(現在コンピュータに格納されているソフトウェア、コンピュータに格納されているデータ、コンピュータの現在の設定などは、実際にはバイナリです。値と現在のステータスに属します)

    • コンピューターの入力デバイスは、入力 (キーボード、マウス、ファイル入力) を受け取り、入力内容と自身の状態 (主に実行可能なプログラム コードを指します) に応じて自身の状態を変更 (メモリ内の値を変更) し、次のことができます。出力を取得する (結果を画面に表示する)

    • 特殊な状態(シャットダウン状態)になると、入力を受け付けなくなり動作しなくなります

  • OpenGLに例えると、このように理解できます

    • OpenGL は、独自の状態 (現在使用されている色、ブレンド機能がオンになっているかどうかなど) を記録できます。

    • OpenGL は、glColor3f の呼び出しなど、入力を受け取ることができます (OpenGL 関数を呼び出すと、OpenGL が入力を受け取っていることがわかります)。つまり、OpenGL がこの入力を受け取った後、その「現在の色」の状態を変更します。

    • OpenGL が停止状態になり、入力を受け付けなくなる可能性があります。OpenGL は、プログラムが終了する前に常に動作を停止します

OpenGL はステート マシンであり、ユーザーが状態を変更するコマンドを入力しない限り、独自の状態を維持します。

【学習アドレス】:FFmpeg/WebRTC/RTMP/NDK/Androidの音声・動画ストリーミングメディアの高度な開発

[記事の特典]: より多くのオーディオおよびビデオ学習パッケージ、Dachang インタビューの質問、テクニカル ビデオ、学習ロードマップを無料で受け取ることができます (C/C++、Linux、FFmpeg webRTC rtmp hls rtsp ffplay srs など) 1079654574 をクリックして参加ます受け取るグループ〜

3. レンダリング

グラフィックス・画像データを 3D 空間イメージに変換する操作をレンダリング( Rendering)と呼びます。

4. 頂点配列 VertexArray と頂点バッファー VertexBuffer

  • 頂点:グラフを描画するときの頂点位置データを参照し、このデータは配列に直接格納するか、GPU メモリにキャッシュすることができます

  • OpenGL の画像はプリミティブで構成されています.OpenGL ES には、点、線、三角形の 3 種類のプリミティブがあります。開発者は関数ポインタを設定することを選択でき、描画メソッドを呼び出すと、頂点データがメモリから直接転送されます。つまり、データのこの部分は以前にメモリに格納されており、頂点配列と呼ばれます。より高性能な方法は、事前にビデオ メモリを割り当て、頂点データをビデオ メモリに事前に転送する方法で、ビデオ メモリのこの部分を頂点バッファと呼びます。

5.パイプライン

  • パイプライン: レンダリング パイプラインとして理解できます。実際には、元のグラフィックデータの束がパイプラインを通過し、さまざまな変更やプロセスを経て、最終的に画面に表示されるプロセスを指します。

  • OpenGL でのグラフィックスのレンダリングは、ノードを 1 つずつ通過します。そして、そのような操作はパイプラインとして理解できます。パイプラインとして想像することができ、各タスクはパイプラインのように実行され、タスク間にシーケンスがあります。パイプラインと呼ばれる理由は、グラフィックス カードがデータを処理する際に決まった順序で来て、この順序に厳密に従うためです。水がパイプの一方の端からもう一方の端までとどまるのと同じように、このシーケンスを破ることはできません。

  • 固定パイプライン: 単純に画像をレンダリングするプロセスとして理解すると、クラスの固定パイプライン効果を呼び出すことによってのみGLShaderManager、一連のシェーダー処理を実装できます。

  • プログラマブル パイプライン: グラフィックスを処理するプロセスとして簡単に理解できますが、カスタムの頂点シェーダーとフラグメント シェーダーを使用できます。OpenGL の使用シナリオは非常に豊富であるため、固定パイプラインまたはストレージ シェーダーはすべてのタスクを完了することができません. この時点で、関連する部分はプログラム可能になるように開かれています.

6. シェーダープログラム Shader

  • 固定レンダリング パイプライン アーキテクチャをプログラム可能なレンダリング パイプラインに変えます。そのため、OpenGL は、実際に描画関数を呼び出す前に、シェーダーによってコンパイルされたシェーダー プログラムも指定する必要があります。一般的なシェーダーには、主に頂点シェーダー、フラグメント シェーダー/ピクセル シェーダー、ジオメトリ シェーダー、およびテッセレーション シェーダーが含まれます。OpenGL ES3.0 までは、頂点シェーダーとフラグメント シェーダーの 2 つの最も基本的なシェーダーのみがサポートされていました。

  • OpenGL は、他のコンパイラと同じようにシェーダーを処理します。コンパイル、リンクなどを経てシェーダープログラム(glProgram)が生成され、シェーダープログラムにはバーテックスシェーダーとフラグメントシェーダーの両方の演算ロジックが含まれます。OpenGL で描画する場合、頂点シェーダーは最初に着信頂点データで動作します。Assembly by Primitives では、頂点がプリミティブに変換されます。次に、ラスター化を実行して、プリミティブなどのベクター グラフィックスをラスター化されたデータに変換します。最後に、計算のためにラスター化されたデータをフラグメント シェーダーに渡します。フラグメント シェーダーは、ラスター化されたデータの各ピクセルを処理し、ピクセルの色を決定します。

6.1 頂点シェーダー 頂点シェーダー

  • 一般的に、グラフィックスの各頂点変換 (回転/平行移動/投影など) を処理するために使用されます。

  • 頂点シェーダーは、頂点の属性を計算するために OpenGL で使用されるプログラムです。頂点シェーダーは頂点ごとのプログラムです。つまり、各頂点データが 1 回実行されます。もちろんこれは並列であり、頂点シェーダー操作中に他の頂点データにアクセスすることはできません

  • 一般的に言えば、計算する必要がある典型的な頂点属性には、主に頂点座標変換、頂点ごとのライティング操作などが含まれます。頂点座標を独自の座標系から正規化された座標系に変換する操作はここで行われます

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

  • 一般に、グラフィックスの各ピクセルの色の計算と塗りつぶしを処理するために使用されます

  • フラグメント シェーダーとは、OpenGL でフラグメント (ピクセル) の色を計算するために使用されるプログラムです. フラグメント シェーダーは、ピクセル単位で操作するプログラムです. つまり、各ピクセルがフラグメント シェーダーを実行します.も平行。

7、GLSL(OpenGLシェーディング言語)

OpenGL シェーディング言語は、OpenGL でシェーディング コーディングに使用される言語です, つまり、開発者によって記述された短いカスタム プログラムです. これらは、固定レンダリング パイプラインの一部ではなく、GPU (グラフィック プロセッサ ユニット) 上で実行されます. , さまざまなレベルでのプログラミングを可能にします.レンダリング パイプラインで。GLSL のシェーダー コードは、VertexShader (頂点シェーダー) と Fragment Shader (フラグメント シェーダー) の 2 つの部分に分かれています。

8. ラスタライズ

  • ラスタライズは、頂点データをフラグメントに変換するプロセスです。グラフをラスターで構成された画像に変換する機能があります。フラグメントの各要素は、フレームバッファのピクセルに対応します

  • ラスタライゼーションは、実際には、ジオメトリ プリミティブを 2 次元イメージに変換するプロセスです。このプロセスは 2 つの部分で構成されています。作業の最初の部分: ウィンドウ座標内のどの整数グリッド領域がプリミティブによって占められているかを決定し、作業の 2 番目の部分: 各領域に色の値と深度の値を割り当てます。ラスタライズ プロセスでフラグメントが生成される

  • オブジェクトの数学的記述とオブジェクトに関連する色情報を、画面上の対応する位置のピクセルとピクセルを塗りつぶす色に変換するプロセスは、ラスタライズと呼ばれ、アナログ信号を離散信号に変換するプロセスです。

9.テクスチャ

テクスチャは絵として理解できます。グラフィックスをレンダリングするときは、画像をエンコードして塗りつぶす必要があります.シーンをよりリアルにするために、ここで使用される画像はしばしばテクスチャと呼ばれます. OpenGL では、画像ではなくテクスチャを呼び出す方が一般的です。

10. ブレンディング

  • テスト フェーズの後、ピクセルがまだカリングされていない場合、ピクセルの色は、フレーム バッファ内の色に関連付けられている色とブレンドされます。ブレンディングアルゴリズムはOpenGLの機能で指定できます。ただし、OpenGL が提供するブレンディング アルゴリズムには限界があります. より複雑なブレンディング アルゴリズムが必要な場合は、通常、ピクセル シェーダーを介して実装できます. もちろん、パフォーマンスは元のサウンド ブレンディング アルゴリズムよりも悪くなります.

  • ブレンディングとは、2 つの色を混ぜ合わせることです。具体的には、特定のピクセル位置の元の色と特定の方法でペイントする色を混ぜ合わせて、特殊効果を実現することです。

11. 変換行列 変換

グラフィックを移動、拡大縮小、回転する場合は、変換マトリックスを使用する必要があります

12. 射影行列射影

3D座標を2Dスクリーン座標に変換するために使用され、実際の線も2D座標で描画されます

13. 画面上での描画・スワップバッファ SwapBuffer

レンダリング バッファーは、通常、ウィンドウなどのシステム リソースをマップします。ウィンドウに対応するバッファに画像を直接レンダリングすると、画像を画面に表示できます。ただし、ウィンドウごとにバッファが 1 つしかない場合は、描画プロセス中に画面が更新され、ウィンドウに不完全なイメージが表示される可能性があることに注意してください。

通常の OpenGL プログラムには、少なくとも 2 つのバッファーがあります。画面に表示されているものをスクリーンバッファ、表示されていないものをオフスクリーンバッファと呼びます。バッファがレンダリングされた後、画面上のバッファと画面外のバッファを交換することによって、画像が画面に表示されます。

ディスプレイのリフレッシュは通常、行ごとに実行されるため、バッファーのスワップを防ぐために、画面の上部と下部の画像は 2 つの異なるフレームに属します。表示が更新され、表示が 2 回更新される間隔のインターチェンジ、この信号は垂直同期信号と呼ばれ、この技術は垂直同期と呼ばれます。

ダブルバッファと垂直同期技術を使用した後、次のフレームをレンダリングする前に常にバッファ交換を待機するため、フレームレートがハードウェアで許可されている最高レベルに完全に到達できない.この問題を解決するために、3つのバッファが導入されています. 、垂直同期を待機している間、2 つのオフスクリーン バッファーを交互に前後にレンダリングし、垂直同期が発生すると、スクリーン バッファーと最近レンダリングされたオフスクリーン バッファーを交換して、ハードウェアのパフォーマンスを十分に活用するという目的を達成します。

元のリンク: OpenGL/OpenGL ES 入門: グラフィックス API と専門用語の分析 - ナゲット

おすすめ

転載: blog.csdn.net/irainsa/article/details/130034858