問題タブ [opengl-4]

OpenGLの学習についていくつか質問があることは知っています。これが私が知っていることです：

• 3D の数学
• 三次元理論

私が知りたいことは次のとおりです: - OpenGL 4.0コア プロファイル(またはそれ以降) - Shader Language 400 (またはそれ以降) - 上記のすべての部分 (ベンダー間で機能しない場合でも、私は気にしません)

これが私が知りたくないことです - 修正された関数パイプライン (これまで使用しません!) - 古い OpenGL - 互換性プロファイル

チュートリアル、一連の記事、書籍など、より多くの情報のほうが好きです。

PS opengl 3.xコアプロファイルに関するリソースを知っている場合は、それらも投稿してください

OpenGLの新しいバージョン（3.0および4.0以降）では、gl_Vertexなどの組み込みの頂点属性は非推奨になっています。実際に何かをレンダリングする「新しい方法」は、位置や色などの独自の頂点属性を指定してから、これらのカスタム属性をバッファーにバインドすることです。

私の質問はこれです：レンダリングコードとシェーダーを密接に結合せずにこれを行うにはどうすればよいですか？頂点の位置として「position」を使用するシェーダーを作成する場合、シェーダーを使用するホストコードはそれを認識し、頂点データを「position」として渡す必要があります。「vertex_pos」で頂点データを取得するために作成された別のシェーダーを使用する場合は、最初にそのシェーダーを書き直すか、代わりに頂点データを「vertex_pos」として送信するようにホストコードを変更する必要があります。

すべてのシェーダーが使用する必要がある標準の頂点属性とフラグメント属性のベストプラクティス名のセットはありますか？または、あるエンジン用に作成されたシェーダーが変更なしで別のエンジンで動作できないように、バルカニゼーションされたエンジン固有の標準がありますか？または、一般に、すべてのオブジェクトがカスタムシェーダーに一致する独自のカスタムレンダリングコードを必要とするような標準はまったくありませんか？

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テッセレーションシェーダー

ウィキペディアや他の情報源によるOpenGL4.0の説明で、私はこの機能について読みました。

CPUの介入なしに、OpenGLまたはOpenCLなどの外部APIによって生成されたデータの描画。

これは何を指しているのですか？

編集：

このように見えるのは、Draw_Indirectを参照している必要があります。これは、シェーダープログラムまたは相互運用機能からのプログラム（基本的にはOpenCL / CUDA）からのフィードバックを含むように描画フェーズを拡張すると思います。 2回目の実行を過ぎてもGPUで長時間使用できますが、可能であるはずです。

CPUなしで描画コマンドを使用する方法についてさらに情報を提供できる場合、または描画間接をより適切に説明できる場合は、遠慮なくそうしてください。よろしくお願いします。

glDrawElementsInstancedBaseVertexBaseInstanceに至るまでのDrawInstanceed/ Draw Indirect関数ファミリーがどのように連携するかを100％明確に把握していません。

OpenGL 4.0以降とOpenCL相互運用機能に対応したハードウェアとドライバーを使用して、GPUでジオメトリを変更しながら、間接描画（現在は複数描画間接）などのツールをどのように活用して、複数のフレームにわたってインスタンス化されたジオメトリを描画できますか？

たとえば、形状をテッセレーションしてから、openclを介して形状にフィルターを適用し、CPUが必要な場合にのみカリングする必要があるジオメトリを参照することはできますか？

*元の投稿は大幅に編集されています

OpenGL でのテキスト レンダリングについて、次のような質問がすでに多数寄せられています。

• GUI で OpenGL ライブ テキスト レンダリングを行う方法は?

しかし、ほとんどの場合、固定機能パイプラインを使用してテクスチャ付きクワッドをレンダリングすることについて説明しています。確かにシェーダーはより良い方法を作る必要があります。

私は国際化についてあまり心配していません。私の文字列のほとんどは、プロットの目盛りラベル (日付と時刻または純粋な数値) になります。ただし、プロットは画面のリフレッシュ レートで再レンダリングされ、かなりの量のテキストが表示される可能性があります (画面上のグリフ数は数千以下ですが、ハードウェア アクセラレーション レイアウトで十分です)。

最新の OpenGL を使用したテキスト レンダリングの推奨されるアプローチは何ですか? （このアプローチを使用している既存のソフトウェアを引用することは、それがうまく機能することの良い証拠です）

• 位置と向き、文字シーケンスなどを受け入れ、テクスチャ付きのクワッドを放出するジオメトリ シェーダー
• ベクター フォントをレンダリングするジオメトリ シェーダー
• 上記と同様ですが、代わりにテッセレーション シェーダーを使用します
• フォントのラスタライズを行う計算シェーダー

WebGLのOpenGL4の機能の一部（具体的には、テッセレーションシェーダーと新しいシェーダー言語バージョン）を使用したいと思います。これは、標準に準拠した方法またはハック的な方法のいずれかで可能ですか？たとえば、gl.FRAGMENT_SHADERの代わりに、テッセレーションシェーダーをコンパイルするように基になるGL実装に指示するために使用できる魔法の値はありますか？

glLineStipple最新の OpenGL API では廃止されました。それは何に置き換えられますか？交換しない場合、どうすれば同様の効果を得ることができますか? (もちろん、互換性プロファイルは使いたくない...)

I'm sorry but this will require a little bit of explanation. I'm trying to make it as simple as possible.

What I want to do: I'm visualizing height fields. A height field may have multiple patches. A patch is a smaller texture that alters the height field.

I'm using OpenGL 4.0, mainly the tesselation shaders. However for this problem this should be irrelevant.

What is working allready. I have the visualisation for the height field (without patches) working. The interessing parts in regard to the problem are the tesselation evaluation shader and the fragment shader.

The tesselation evaluation shader fetches for each vertex its height from the height field sampler.

The fragment shader uses the reative height of the vertex belonging to the fragment at hand to access a 1D height palett texture. Please ignore the height gradient for now. It's used to calc the normals. This works completely fine.

Includes before each shader is the following code. It contains mainly all uniform and helper functions.

The problem
The shaders described and pasted above are all working correctly as long as I don't access the Patches uniform.

The idea behind the sampler2D[] is to have a sort of array while each texture of this array may have a different size. I'm aware of the fact that each of this constuct uses (in this case) 20 texture units. This limitation of fine.

The moment I access the Patches uniform the fragment shader only outputs black pixels. The tessellation evaluation shader is working correctly, that I know, because I can see hills in the height field, that arn't part of it.

I'm very thankfull for any suggestions. Regarding this problem.

I know I could use a sampler2DArray, but then each element (texture) has to have the same size. But I need the patch size to be flexable. Cutting patches into textures of a fixed size and stiching them back together in the shader, whould be an alternative, but I don't want to implement this organisation overhead unless I really have to.

Infolog

状況

2 つのビューを持つ高さフィールド エディターを実装しています。メイン ビューには、高さフィールドが 3D で表示され、トラックボール ナビゲーションが可能になります。編集ビューには、高さフィールドが 2D 画像として表示されます。
この高さフィールドの上に、その外観を変更する新しい画像を適用できます (穴を開けたり、特定の領域を低くしたり、高くしたりします)。これはパッチと呼ばれます。
高さフィールドとパッチの両方が 1 チャネルのグレースケール png 画像です。

視覚化には、視覚化ライブラリフレームワーク (c++) と OpenGL 4 を使用しています。

タスク
実行時にこのパッチを (個別の画像として) 作成する、2D 編集ビュー (正投影) で使用可能な描画ツールを実装します。

重要事項・制約事項

• 高さフィールドの画像は、スケーリング、回転、転置することができます。
• パッチは高さフィールドと同じスケールを持つ必要があるため、パッチ内の 1 つのピクセルが高さフィールド内のピクセルを正確にカバーします。
• スケーリングの結果として、フレームバッファ ピクセルのサイズは、ハイト フィールド/パッチ イメージ ピクセルのサイズより大きくなったり小さくなったりする場合があります。
• シーンには、パッチに表示されるべきではないオブジェクト (例: 矢印) が含まれています。

質問 このタスクへの正しいアプローチは何ですか? これまでのところ、次のアイデアがありました。

• ある種の QT キャンバスを使用してパッチを作成し、それを高さフィールド イメージ プロポーションにマップして、新しいパッチとして保存します。これは、ユーザーが描画を開始するたびに行われます。この方法では、元に戻すの実装が簡単になります (最後に作成されたパッチを削除します)。
• ニュートラルカラーの画像を textre バッファオブジェクトと組み合わせて使用​​して、ある種のキャンバスを自分で実装します。このようにして、ユーザーが描画を停止するたびに、キャンバスの内容が高さフィールドにマップされ、パッチとして保存されます。次の描画のためにキャンバスをリセットします。
• フレーム バッファ オブジェクトを使用した例をいくつか示します。ただし、このアプローチが私のニーズに合っているかどうかはわかりません。open gl を使用してサブ イメージをフレーム バッファに描画すると、結果のイメージにすべてのデータが含まれませんか?