問題タブ [opengl-4]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
ruby - RubyでOpenGL 3.xまたは4.xコンテキストを作成するには?
私はいたるところを見てきましたが、OpenGL 3/4 コンテキストの作成を可能にするルビ バインディングがないようです。
完全な OpenGL バインディング ライブラリである必要はなく、OpenGL コンテキストを作成する部分だけです。
更新: 絶望的な場合は、部分的な glfw ruby バインディングを ruby ffi で行います。だから、それから私を救ってください;)
c++ - 最新の OpenGL を学ぶ
過去数年間に同様の質問があったことは承知していますが、いくつかの調査を行った後でも、どこから何を学ぶべきかを決めることができません. また、より多くの C++ OOP とシェーダー アプローチを使用した最新の OpenGL プログラミングに関する現在の実際の見解も見てみたいと思います。そして、いくつかのことについての私の実際の理解が有効であることを確認してください。
それで...現在、OpenGL 4.2が出ています。どこかで読んだように、dx11ハードウェア(それはどういう意味ですか?)と、たとえばウィンドウを作成するための「サイド」ライブラリのセットが必要です。
私が非常に嫌いな最も一般的なGLUTがあります。主な理由の 1 つは関数呼び出しであり、メイン ループの作成方法に自由がありません。一部の人が言っていたように、それはゲーム用ではありませんでした。
GLFWもありますが、これは実際には非常に素晴らしく、私にとっては簡単です. 何らかの理由で、人々はGLUTでそれを使用します. (ウィンドウの初期化だけでなく、他のユーティリティも提供しますか?)
また、SFML と SDL ( SDL < SFML imo ) もありますが、どちらも OGL を操作するために奇妙なアプローチが必要な場合があり、場合によってはあまり高速ではありません。
また、拡張機能ロード ユーティリティである GLEW もあります... 待って... GLUT/GLFW は既に拡張機能ではありませんか? 興味を引く本当に重要な拡張機能があるなど、それを使用する理由はありますか?
これまで、ウィンドウの作成 (およびいくつかのユーティリティ) はありましたが、... OGL はテクスチャや 3D モデルの読み込みを処理しません。他にいくつのライブラリが必要ですか?
今、教育の部分に言及しましょう。(悪名高い) 有名な NeHe チュートリアルがあります。WinApi を使用して C で記述されており、非常に不明確なコードと時代遅れのソリューションを備えていますが、依然として最も人気のあるものです。2.x や 3.x などのバージョンに関連する Red Book のようなものがありますが、4.x に言及している (そして未完成の) チュートリアルはほとんどありません。
何と一緒に行きますか?
c++ - Opengl: アルファ チャネルとして単一チャネル テクスチャを使用してテキストを表示する
私がやろうとしているのは、テクスチャを単一チャネル データ配列からハードウェアにロードし、そのアルファ チャネルを使用してオブジェクトにテキストを描画することです。私はopengl 4を使用しています。
4 チャンネルの RGBA テクスチャを使用してこれを実行しようとすると、問題なく動作しますが、何らかの理由で 1 つのチャンネルだけを読み込もうとすると、画像が文字化けしてしまい、その理由がわかりません。次のコードを使用して、一連のグリフのテクスチャ ビットマップ データを 1 つのテクスチャに結合することにより、テクスチャを作成します。
次に、テクスチャ データの呼び出しをロードします。
私のフラグメント シェーダーは次のコードを実行します。
テクスチャから生成されたとわかる画像が得られますが、ひどく歪んでいて、その理由がわかりません。ところで、GL_ALPHA が Opengl 4 から削除されたため、GL_RED を使用しています。本当に混乱しているのは、グリフから 4 RGBA テクスチャを生成し、そのアルファ チャネルを使用すると、これが正常に機能する理由です??
opengl - (OpenGL 3.1-4.2)オブジェクトはすべての画面スペースを占有します
私の知る限り、OpenGLに関するすべてが3.1以降変更されており、レンダリングコンテキストのサイズを変更する方法がわかりません。
これを修正できる設定はありますか?または、数学をシェーダー自体に組み込む必要がありますか?
opengl - (OpenGL 3.1-4.2)動的均一配列?
人間とポニーの2種があるとしましょう。それらは異なる骨格系を持っているので、均一な骨の配列は種ごとに異なっている必要があります。各ボーン配列を適切にレンダリングできる2つの別々のシェーダープログラムを実装する必要がありますか、それとも均一な配列を動的に宣言し、代わりにその動的配列を反復処理する方法がありますか?
パフォーマンスを念頭に置いてください(すべてのシェーダーは、意思決定の分岐を回避するのに苦労しています)。
math - モデル空間での軽い計算
フラグメントごとのライティングが機能していますが、フラグメントシェーダーで以下のように法線にnormalModelMatrixを掛ける必要がないモデル空間で、ライティングの計算を維持するにはどうすればよいでしょうか。
シェーダー:ViewMatrix-カメラ変換、ModelMatrix-オブジェクト変換。ライトの位置-glm::vec4 lightPos(3.0f、2.0f、-30.0f、1.0f)
レンダリングループ:
バーテックスシェーダー:
フラグメントシェーダー:
math - フラグメントごとの照明とウィンドウからカメラへの変換
ウィンドウからカメラへの変換を使用して、フラグメントごとのライティングとライトの減衰を実装しました。
次に、lightPos と cameraPos を使用してライティングを計算します。lightPos は、ワールド空間で固定位置を持ちます。fps スタイルのカメラと ModelMatrix を処理する ViewMatrix があります。以前は、ウィンドウからカメラへの変換の代わりに頂点位置を使用していましたが、すべて問題ありませんでした。カメラを使用してオブジェクトの周りを移動すると、正しくない照明が得られるようになりました。フラグメント シェーダーにアップロードする前に、lightPos は ViewMatrix で乗算されます。
何が間違っているのかわかりません。
mesa - OpenGL 4.2ヘッダー、Mesa 3D、拡張機能-どのように組み合わせるのですか?
今、私はOpenGLヘッダーと拡張機能、および最新機能にアクセスする方法に関する情報を見つけるのに非常に苦労しました。OpenGL.orgはこれについては触れておらず、Mesa(2006年に更新されました!)も誰も触れていませんが、これを理解したいと思っているのは私だけではないと思います。
私はNvidiaドライバー(4.2をサポート)を使用してArchlinuxで開発していますが、OpenGLヘッダーは付属していないようです(とにかくリポジトリのヘッダーではありません)。ここから問題と混乱が始まりました。Mesa3Dヘッダーを使用する必要があることを読みました-現在OpenGL3.0をサポートしています。これは私が今インストールしたものです。
ここで、コアのOpenGL4.2ヘッダー(gl.h)がOpenGL1.2の機能のみを公開していることをどこかで読みました。残り(4.2まで)は拡張機能のロードを通じて利用できます-つまり、4.2に対して開発したとしても、これらの3.0ヘッダーは問題ありません-4.2のコア機能をすべて拡張機能としてロードするだけです。
gl.hヘッダーが実際に4.2と3.0の間で異なる関数を公開していることをどこかで読みました。古い記事がたくさんあり、確かな情報がないため、何も検証できません。
誰かがこれらすべてがどのように組み合わされているかを説明できますか?
opengl - glsl倍精度頂点バッファ
たとえば、倍精度の頂点バッファーを作成すると、次のようになります。
頂点シェーダーで倍精度データにアクセスするにはどうすればよいですか? 私はこれを行うことができるはずですか?
opengl - GLSL頂点シェーダーのアイスペースピクセル幅
glsl頂点シェーダーの現在の頂点位置にあるピクセルの投影ピラミッドのアイスペース幅を計算したいのですが、計算が正しくできないようです。これは明らかに間違った例です:
ただし、これはFOVまたはクリッピングプレーンを考慮していません。