問題タブ [opengl-3]

OpenGL 4と3、特に3.1と4.1はかなり似ていることを理解しています。両方が本質的に一緒にリリースされているため、OpenGL 4.0/4.1の理論的根拠を理解するのは難しい場合があります。

OpenGLの以前のリリースでは、マイナーバージョンは、大幅な変更が新しいメジャーバージョンに蓄積されるまで上向きに増加します。OpenGL 3.xおよび4.xは下位互換性のないAPIの変更を導入し、OpenGL 3.2および3.3は、3.1が4.1+と互換性があるのに対し、上位互換性がない3シリーズのブラン​​チであると言われています。

OpenGL 4.1は、新しいメジャーバージョンに分類されることを保証するOpenGL 3.1と比較して、どのような主な違いがありますか？

ボーナス：GL3やアクセシビリティだけでなく、どのような状況でもパフォーマンスが向上する違いはありますか？

編集：回答に基づくいくつかの追加の調査結果

OpenGL 3.3は、OpenGL 4.0を補完して、古いハードウェアに可能な限り多くの機能を組み込むために作成されました。OpenGL 3と4、3.3のどちらかを選択する方が良い場合もあります。4.1では、GL ES 2.0との互換性と、いくつかの優れた機能が追加されています。

ワークフローの大きな違いの1つは、新しいテッセレーションシェーダーを介してパイプラインにGPUプログラミングステップが追加されることです。もう1つは、レンダリングする複数のビューポートです。新しいレベルの詳細機能は、私が使用しているワークフローを変更し、おそらく他のワークフローもかなり変更すると思いますが、この機能については詳しく調べていません。

誤解や改善すべき点があれば教えてください。

基調講演（メタを尋ねている間、明らかに回答から削除されました。実際の回答が何であったかを一時的に参照するためです。）

付録G- KOpenGL4.1機能からOpenGL4.1 機能まで

OpenGL4.0のKhronosGroupリリースは「読みやすい」かもしれません:)

• サンプラーオブジェクト
• インスタンス化された配列とシェーダー

• texture_cube_map_arrayおよびtexture_gather

• GLSL4.0と動的LOD

• shader_subroutineおよびsample_shading
• セパレートシェーダーオブジェクト
• テクスチャ/レンダーバッファに必要なサイズを増やします
• 64ビット浮動小数点頂点属性
• get_program_binary
• +2テッセレーションシェーダー

編集II：
現在のコードはうまく機能します！みんな、ありがとう。私は先に進み、参照用のシェーダーコードを下部に含めましたが、現時点では実際には何もしていません。

私はOpenGL4.1を使い始めようとしていますが、まだ開発の初期段階にあります。現在、このプロジェクトではまだ4.0の機能を実際に使用していません。したがって、これはOpenGL3の質問でもあります。

私が最初に取り組んでいた目標は、VAOとVBOを処理するための2つのクラスを作成することでした。私はいくつかの誤解を持っていましたが、最終的に空白の画面を通り過ぎました。

基本的には、この時点で画面に何かが表示されることを望んでいます。私はglfwとglewを使用しています。私はいくつかのことを完全に省略していますか、それとも何かを修正するだけで済みますか？申し訳ありませんが、現時点ではコードが多少壊れています。

base.vert

base.frag

ユーザーがズームしてスムーズにパンできる時系列ビューアを実装したいと思います。

以前にいくつかの即時モードopenglを実行しましたが、VBOを優先して非推奨になりました。私が見つけることができるVBOのすべての例は、すべてのポイントのXYZ座標を格納します。

パン中に「スムーズ」と呼ばれるフレームレートを取得するには、すべてのデータをVRAMに保持する必要があると思いますが、Yデータ（従属変数）しかあ​​りません。Xはインデックスから計算できる独立変数であり、Zは定数です。XとZを保存する必要がある場合、メモリ要件（バッファサイズとCPU-> GPUブロック転送の両方）が3倍になります。また、ユーザーがパンできる数千万のデータポイントがあるため、メモリ使用量は重要です。

インデックスが他の座標として使用される1-D頂点配列を描画するか、1-D配列を（おそらくテクスチャに）格納し、シェーダープログラムを使用してXYZを生成するためのテクニックはありますか？スケーリングと変換を実装するには、新しい固定機能のないパイプラインモデルの下で、とにかく単純なシェーダーが必要であるという印象を受けています。したがって、X座標とZ座標の生成と、Yのスケーリング/変換を組み合わせることができれば、理想。

これも可能ですか？これを行うサンプルコードを知っていますか？または、少なくとも、どのGL関数をどの順序で呼び出すかを示す擬似コードを教えていただけますか？

ありがとう！

編集：これを明確にするために、同等のイミディエートモードコードと頂点配列コードを次に示します。

v[]の2倍のサイズであることに注意してくださいy[]。

すべての頂点とインデックスを含むメッシュのサイズが (最適な) 頂点バッファー オブジェクトの上限 (~8MB) よりも大きい状況に遭遇しました。メッシュを複数の頂点バッファーに分割し、インデックスの有効性を維持できるかどうか疑問に思っていました。つまり、最初の頂点にインデックスがあり、最後の頂点にインデックスがある三角形 (つまり、別々の VBO)。

頂点配列オブジェクト内でこれを維持しながら。私の考えでは、手間を省いて、このようなメッシュ (messes :P) には必要なサイズ (> 8MB) を使用するだけです。それが私が今していることです。しかし、理想的には、現時点で私のバッファー マネージャー (wip) は最適なサイズを使用しています。その場合、特別なケースを作成する必要があるかもしれません。

何か案は？

注:どちらがより適しているか確信が持てなかったので、これをgamedev stackにもクロスポストしました(部分的には設計上の問題です)。

glGenerateMipmap を実装しようとしているので、レンダリングしたキューブの各レベルの色を変更できますが、プログラムがコンパイルされず、エラーが発生します。

「エラー C3861: 'glGenerateMipmap': 識別子が見つかりません」

「#include」を含めましたが、ヘッダー内に定義が存在しているように見えます（ただし、IFステートメント内ですか？以下を参照）。プログラムがコンパイルまたは実行されるように、何らかの方法で再定義/配置する方法があるかどうか疑問に思っていました.そうでない場合は、ミップマップを自動的に生成する別の方法がありましたか?

どうもありがとう、クリス

ここで奇妙な問題が発生しました。1秒間に数回作成される潜在的に大きな（最大500mbのような）3Dテクスチャがあります。テクスチャのサイズが変更される可能性があるため、古いテクスチャを毎回再利用することはできません。メモリ消費を回避するための論理的な手順は、テクスチャが使用されなくなるたびに（glDeleteTextureを使用して）テクスチャを削除することですが、プログラムはすぐに読み取りまたは書き込みアクセス違反でクラッシュします。テクスチャを更新するために使用するバッファで呼び出された場合、glDeleteBufferでも同じことが起こります。

私の目には、glDelete *関数はかなりフェイルセーフであるため、これは起こり得ません。対応するオブジェクトではないglハンドルをそれらに与えると、それらは何もしません。

興味深いのは、テクスチャとバッファを削除しないと、最終的にグラフィックカードのメモリがなくなるまでプログラムが正常に実行されることです。

これは、Windows XP 32ビット、266.58erドライバーを搭載したNVIDIA Geforce 9500GTで実行され、プログラミング言語はVisualStudio2005ではc++です。

アップデート

明らかに、影響を受ける関数はglDeleteだけではありません。他のいくつかの方法で違反が発生しました（昨日はそうではありませんでした）...ここで何かが壊れているようです。

アップデート2

これは失敗するべきではありませんか？

失敗する：

最良の推測：プログラムメモリを台無しにする何か？

このテーマは、他の最適化問題と同様に、多くの話題に上りますが、私が欲しい (と思う) ものを見つけることができませんでした。

多くのチュートリアル、さらには SO の質問にも同様のヒントがあります。一般的に以下をカバーします：

• GL 顔カリングを使用する (シーン ロジックではなく、OpenGL 関数)
• 1 つのマトリックスのみを GPU (projectionModelView の組み合わせ) に送信するため、MVP の計算が頂点ごとからモデルごとに 1 回に減少します (あるべき姿)。
• インターリーブされた頂点を使用
• 可能な限り多くの GL 呼び出しを最小限に抑え、必要に応じてバッチ処理します

そしておそらくいくつか/多くの他の人。私は (好奇心のために) いくつかの頂点バッファーを使用して、アプリケーションで 2,800 万個の三角形をレンダリングしています。上記のすべての手法を (私の知る限り) 試しましたが、パフォーマンスの変化はほとんどありませんでした。

私の実装では約 40FPS を受信して​​いますが、これは決して問題ではありませんが、これらの最適化の「ヒント」が実際にどこで使用されるのかについてまだ興味がありますか?

私の CPU はレンダリング中に約 20 ～ 50% アイドル状態になっているため、パフォーマンスを向上させるために GPU に依存していると思います。

注:現在、gDEBugger を調べています。

ゲーム開発に投稿されたクロス

GeForce 9400 グラフィックス カードを搭載した MacBook Pro を使用しています。ウィキペディアによると、このカードは OpenGL 3 をサポートしています。

しかし、OS X 10.6 に同梱されているヘッダーとライブラリは OpenGL 2 のみのようです (ファイルは で確認しました/usr/X11/include/)。

OpenGL 3 プログラミングを行う必要があります。現在使用しているハードウェアと OS で実行できますか? 何を入手してインストールする必要がありますか?

私はここで基本的な指示に従いました：

http://www.opengl.org/wiki/Tutorial:_OpenGL_3.1_The_First_Triangle_%28C%2B%2B/Win%29#Rendering_Context_Creation

私が微調整した唯一のことは、コンテキストを 3.2 または 3.3 に作成することです。

そして、コンテキストの作成後 (成功の場合は TRUE を返します)、次の方法でバージョンを確認します。

ただし、pszGLVersion は NULL であり、glVersion[0] と glVersion[1] はどちらも初期化されていません。

OpenGL 3.2 & 3.3 コンテキストの作成は成功するのに、バージョン情報の取得に失敗するのはなぜですか?

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

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