問題タブ [opengl-es-2.0]

OrangeBookブリックシェーダーをOpenGLES2.0に移植しようとしていますが、照明に問題が発生しています。照明がないとレンガが見えますが、照明があると形は真っ黒になります。

ヴェール

フラグメント

これが私のJavaです

OpenGL ES 1 には、画像の座標を設定するための次のような関数があります。

OpenGL ES 2.0 でこれに相当するものは何ですか?

クワッドは OpenGL ES 2.0 には含まれていませんが、1.1 には含まれていません。OpenGL ES 2.0 が提供するプログラム可能なパイプラインを使用して、テクスチャ (元は png ファイル) を 4 つの定義済みポイントに単純に描画するにはどうすればよいですか?

VBO は必要ですか? 透視行列を計算する必要がありますか? これらのことはすべて面倒です... 使用されているプラ​​ットフォームは iPhone です。

opengl es2 で頂点を回転させる方法

es1では、 glRotatef(transY, 0, 0, 1); を実行できます。

ただし、es2 ではクラッシュします

es2でも同じことが可能ですか

xcodeにiPhone SDKを使用する

だから、私はOpenGL ES 2.0アプリを持っています。これは、iPhone/iPad シミュレーター、実際の iPhone/iPad、および Imgtec のエミュレーター ライブラリ (つまりPVRVframe ) を使用する Windows でコンパイルおよび実行されます。

上記のアプリでは、クエリできるすべての状態 (ビューポート、深度テスト/ステンシル テスト/カリング/ブレンド オフ、フレーム バッファーの完了など) が適切に見えても、ターゲットにピクセルが書き込まれない特定の描画呼び出しが 1 つあります。 AFAICT 私は賢明な頂点データを提出しています。

この時点で私が求めているのは、Pix / GPADのようなツールです。これにより、シーンをステップスルーし、問題の描画呼び出しの時点で OpenGL から直接クエリできない状態を確認できます (実際の頂点/インデックス バッファーの内容など)。 ）。

PVRTraceもOSX 計測器も、この種の問題をデバッグするのに十分な状態をキャプチャしていないようです。特に、それらは頂点/インデックス バッファまたはテクスチャ データをキャプチャしません (OSX インストゥルメントはシェーダ ソースもキャプチャしません)。

gDEBuggerは、以前はスタック オーバーフローに関するこの種の質問に対する回答でしたが、バージョン 5.8 になりました。これは無料になりました。これは素晴らしいことですが、OpenGL ES 2 をサポートしなくなりました (Windows では、EGL を介して ES2 でレンダリング可能な構成は利用できません。 OSX では、シミュレーターまたは実際のデバイスで実行されているアプリにデバッガーをアタッチする方法はありません)。

明らかな何かが欠けていますか？私のオプションは何ですか？他の人は自分のシーンをどのようにデバッグしていますか?

OpenGL ES 2.0 の良い SkyBox の例を教えてください。OpenGL しか見つかりませんでしたが、うまくいきません。私はこのようにしています: 初期化:

スカイボックスの描画:

テクスチャの読み込みは機能しています。シェーダーは正しくコンパイルされ、次のようになります。頂点シェーダー:

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

しかし、立方体が見えません。私は何か間違ったことをしていますか？ありがとうございました

シェーダーをコンパイルし、シェーダーバイナリを保存し、glShaderBinaryを使用して後でiPhone / iOS（OpenGL ES 2.0）でシェーダーをロードする方法の例を誰かが持っていますか？

Analyzeインストゥルメントによって提供されるOpenGLAPI使用パフォーマンス警告のリストを調べてみると、フレームごとに複数の論理バッファーロードが生成されていることがわかりました。描画呼び出しによってバッファーが完全に上書きされるため、バッファーをクリアしていません。

直感に反して、これらのケースに呼び出しを導入glClear()すると、警告の場所が呼び出しに移動するだけglClear()です。Appleは実装GL_EXT_discard_framebufferしていますが、これを単独で使用するだけでは警告を停止するのに十分ではありません。glDiscardFramebufferEXT()後に続くaはglClear()警告を停止し、パフォーマンスを大幅に向上させますが、glClear()呼び出し自体はバッファーをクリアするのに時間がかかります。これは、このユースケースでは冗長な操作です。

他の人も、リロードコストを回避するために両方の関数を呼び出す必要があると思いますか、それとも何かが足りませんか？フレームバッファの内容が完全に上書きされようとしているので、タイルメモリにリロードする必要がないことをOpenGLに示唆する安価な方法はありますか？

重い 2D グラフィックスを使用するクロスプラットフォーム デスクトップ アプリケーションに取り組んでいます。頂点シェーダーが必要なため、OpenGL 2.0 仕様を使用します。シンプルでパワフルな 3.2+ コア API が好きです。将来的には 3.2+ コアが選択肢になる可能性があると思います。しかし、最近ではこの機能が一部のプラットフォームで利用できない可能性があるのではないかと心配しています (古いグラフィック カードと最新の Linux ドライバーの欠如 (?) を意味します)。おそらく、将来の移植を容易にするために、OpenGL ES 2.0 のような API を使用する必要があります。

3.2+ コア、カード、および Linux ドライバーの状況はどうなっていますか?

シェーダーに均一パラメーターを設定する直前に、glGetUniformLocationを使用してその位置を取得しています。最初に一度実行して、int位置の値を格納するのではありません。このような：：

それは私のパフォーマンスにかなり影響しますか？