コンピューターグラフィックス

trichoplaxの質問のスタイルで、もう1つのウィキペディアの記事であるラジオシティ（コンピューターグラフィックス）についてお話したいと思います。記事は述べています： ラジオシティはビューポイントに依存しないため、関連する計算が増えますが、ラジオシティはすべてのビューポイントで役立ちます。 この手法は、拡散サーフェスでのみ機能します。このようにして、フォームファクターは事前に計算され、ビューアーから独立しています。いくつかの光源が変更された場合のみ、照明を更新する必要があります。一方、テクニックが鏡面反射をサポートする場合、フォームファクターはビューアに依存します。フォームファクターと照明は、カメラが動いたときに常に更新する必要があります。 拡散サーフェスの制限により、計算はどのように増加しますか？拡散反射光サーフェスでは、すべての方向からの光を考慮する必要があります。これは、小さな鏡面ローブからのみ光を取り込むよりも複雑です。これはこの文章の意味ですか？それは私だけですか、それとも言い換えるべきですか？

8 radiosity 

閉まっている。この質問はトピックから外れています。現在、回答を受け付けていません。 この質問を改善してみませんか？ 質問を更新して、 Computer Graphics Stack Exchangeのトピックとなるようにします。 4年前休業。 私は、デモシーンが歴史的に新しい技術を導入したかどうか知りたいと思っています。それは長年にわたって多かれ少なかれ関連していますか？ 初期のデモのいくつかは、既知のハードウェアエラーを利用して、当時可能と考えられていたものを超えていることを知っていますが、私が興味を持っているのは、導入された新しい手法のいずれかが、研究者やプロのプログラマーによって採用されたかどうかです。物事の主流として受け入れられている方法の一部になる。

8 demoscene 

アンビエントオクルージョンとは、シーン内の各ポイントがアンビエントライティングにどの程度さらされているかを計算するために使用されるシェーディングおよびレンダリング手法です。 アンビエント照明はアンビエント照明とは何ですか？： ...照明は一定であり、位置から独立しています。それはアンビエント照明です。 アンビエントライティングに固定位置がない場合、ポイントをどのように多かれ少なかれそれにさらすことができますか？アンビエントライティングは、「全方向に一定量だけ光ります」。したがって、ライトがすべての方向から来る場合、すべてのポイントが同じファクターによってアンビエントライティングにさらされる必要があります。

8 shading  ambient-occlusion 

私は深度テクスチャを使用してOpenGLのシャドウマッピングをいじっています。深度テクスチャは細かいので、シーンにマッピングできますが、オブジェクトの裏側に奇妙なアーティファクトがあります。 私の質問は、これを引き起こしているものであり、どうすれば修正できますか？ 私が使用しているフラグメントシェーダーはかなり単純です（ここに青がない理由に疑問がある場合に備えて、簡単にするために色を取り除いています）。 in vec4 vShadowCoord; uniform sampler2DShadow shadowMap; out vec4 fragColor; void main() { float bias = 0.005; float visibility = 1.0; if (texture(shadowMap, vec3(vShadowCoord.xy, vShadowCoord.z / vShadowCoord.w)) < (vShadowCoord.z - bias) / vShadowCoord.w) visibility = 0.25; fragColor = vec4(visibility); } 編集：必要に応じて、上記のコードのみを使用する最低限の作業例のスクリーンショット（色なし）。

8 opengl  glsl  shadow-mapping  shadow 

現在のところ、シーンをレンダリングするとき、およびシーングラフを反復処理するとき、各ノードのモデルマトリックスは、親のモデルマトリックスとシーンノードのポーズから計算されます。これは非常に単純で、行列の乗算の数をノードとフレームごとに1回の乗算にすでに減らしています。 しかし、これらのすべての行列乗算は、シーンノードの（複数の連続した）動きを非常に高速に実行できるように、CPUとすべてのフレームで実行する必要があります。ただし、GPUは多くの行列乗算を実行するのに適しているため、CPUですべてを計算するのではなく、複数の部分モデル行列を頂点シェーダーに送信することを検討しています。 この場合、すべての計算がすべてのノードではなくすべての頂点に対して行われるため、実際にはパフォーマンスが低下するため、GPUにすべてのパーツ（したがって、すべてのノードのポーズ）を送信することはおそらく意味がありません。しかし、多くの子を持つシーンノード、または（親に対して）移動しない子のみを持つシーンノードは、モデルマトリックスを分割し、乗算をシェーダーにシフトする場所になる可能性があります。 では、部分モデルマトリックスをシェーダーに送信して、乗算をGPUに移動するのはどのような場合に適していますか？それともこれは単に悪い考えですか？

8 opengl  performance  transformations  scene-graph 

シェーダーのユニフォームをどのように構成するかに基づいて、パフォーマンスに影響があるかどうか知りたいのですが。たとえば、4つのfloatを渡すことは、単一のvec4を渡すよりも悪いですか？

8 performance  glsl  shader 

De Casteljauのアルゴリズムのtおかげで、ベジエ曲線をいくつかのパラメーターで2つの部分に分割することは簡単です。 NURBSカーブに同様のアルゴリズムはありますか？NURBSカーブを分割する方法は？

8 nurbs 

任意の三角形メッシュが与えられた場合、そのUVマッピングを自動的に生成することは可能ですか？その場合、それはどのように行われますか？

8 uv-mapping 

Boidsのようなシミュレーションモデルは、小規模な鳥の群れや魚群に良い結果をもたらしますが、膨大な数の場合、すべてのメンバーをリアルタイムでシミュレーションすることは非現実的です。鳥の密度だけが見える距離で群れをモデル化する方法はありますか？処理する変数の数がはるかに少ない、変化する密度勾配を流したいのですが。 私ははるかに小さな母集団を使用して、各ボイドをガウス密度のぼやけた領域として表示し、それらが重なり合うと密度が相互作用を介して上下するようにしてみました。これはかなり安価ですが、空間的または時間的に密度が急激に変化することはなく、均一に見えすぎます。 個人の数をもっと少なくする方法はありますか？または、レンダリング前に現実的な結果を得る唯一の方法は何ですか？

8 real-time 

コンピューティングシェーダーを使用してOpenGLテクスチャを生成する最善の方法を理解しようとしています。これまでのところ、ピクセルバッファーオブジェクトは非ブロッキングCPU-> GPU転送に適していること、およびコンピューティングシェーダーは、どのようにバインドされているかに関係なく、バッファーを読み書きできることを確認しました。理想的には、できるだけ多くのコピーを避けたいと思います。つまり、GPUにバッファーを割り当て、圧縮されたテクスチャデータをGPUに書き込み、そのバッファーをシェーダーのテクスチャオブジェクトとして使用します。 現在、私のコードは次のようになります。 GLuint buffer; glGenBuffers(1, &buffer); glBindBuffer(GL_SHADER_STORAGE_BUFFER, buffer); glBufferStorage(GL_SHADER_STORAGE_BUFFER, tex_size_in_bytes, 0, 0); glBindBuffer(GL_SHADER_STORAGE_BUFFER, 0); // Bind buffer to resource in compute shader // execute compute shader glBindBuffer(GL_PIXEL_UNPACK_BUFFER, buffer); glCompressedTexImage2D(GL_TEXTURE_2D, 0, fmt, w, h, 0, tex_size_in_bytes, 0); これは正しいです？同期の保証についてもどこかで読みました。バッファオブジェクトからコピーする前に、コンピュートシェーダーが実行を完了させるために何を追加する必要がありますか？

8 opengl  texture  compression  compute-shader 

画面が異なれば、ピクセルジオメトリも異なり、赤、緑、青のコンポーネントが異なるパターンで配置されます。サブピクセルレンダリングを使用して見かけの解像度を高くすることは、ピクセルジオメトリがわかっている場合にのみ可能です（あるタイプのモニターで明瞭度を向上させると、別のタイプのモニターでは状況が悪化します）。 モバイル画面ではさまざまなピクセルジオメトリが非常に一般的であるため、デスクトップ/ラップトップとモバイル画面の両方でアプリケーションを実行する必要がある場合、これは特に重要です。 ユーザーに質問することなく、画面が実行時に使用するジオメトリを決定する方法はありますか？これが一般的に可能かどうかに興味がありますが、理想的には、WebGLでJavaScriptを使用するときに可能かどうかを知りたいです。

8 webgl  javascript 

どうやら、バイキュービックピクセル補間は、（リアルタイムかどうかに関係なく）画像を拡大または縮小するのに適しています。 ダウンサイジングする前にローパスフィルターを使用することをお勧めしますか、それともバイキュービックサンプリングはエイリアシングの問題をまったく処理しますか？

8 texture 

非グラフィック計算（人工生命シミュレーション）にGPUを使用したいと考えていますが、理想的には、これを一度に数週間、1日24時間実行したままにしたいと考えています。 これを試す前に考慮すべきことはありますか？GPUは、連続使用により過熱したり、寿命が短くなったりしますか？ コンピューター全般についてはどうですか（私の場合はラップトップですが、このためにデスクトップコンピューターを購入する価値がある場合の違いに興味があります）。GPUをノンストップで実行すると、コンピューターの接続部分に負担がかかりますか？これに起因する既知の問題はありますか？

8 gpu 

次のように、カメラまでの距離に基づいてフォグとサーフェイスカラーをブレンドするglFogを知っています。 方程式はドキュメントにも記載されています。しかし、霧はカメラの前ですぐに適用されます。私は水面をレンダリングしようとしていて、それをある程度の深さにしたいと思っています。たとえば、 現時点では、以下のように水面をアルファブレンディングでレンダリングしています。私が必要なのは、水面から水底までの距離に基づいた霧を作ることです。この距離を取得するにはどうすればよいですか？今のところ、カメラは常に水上にあると想定しています。

8 opengl  fog  depth-map 

直感的には、空気の流れが遅い場所では、ほこりが表面に付着する割合が高くなります。これは、表面にほこりの層が集まる代わりに、コーナーに多くなることを意味します-部屋/棚のコーナー、表面上のオブジェクトの配置によって形成されるコーナー、表面の凹み。 ほこりの厚さ/密度をオブジェクトからの距離に応じて減少させ、壁を含むいくつかのオブジェクトにその効果を組み合わせるだけで、現実感を増すことができます。これにより、予想される厚さの順序が自然に得られます。床のエッジには中央よりも多くのほこりがあり、エッジが交わるコーナーには、中央よりも多くのほこりがあります。ただし、順序を正しくすることによるリアリズムの増加には、比率を正しくするという問題が残っています。ほこりが多いと予想される場所にはほこりが多くありますが、必ずしも適切な量ではありません。 サーフェス上の異なるポイント間の現実的な厚さの比率を概算する確立された方法はありますか？私はこれを完全に物理的に正確にする必要はありません（塵が蓄積するのにかかる長い時間の間に環境を移動するオブジェクトを考慮する必要があります）。私は人間の目には信じられないような平均的な行動を探しています。 オンラインで検索したところ、表面へのダストの堆積をモデル化する方法ではなく、浮遊ダストの大気モデルがほとんど見つかりました。 私の試み-線形および指数分布 以下は、Python（PILフォーク）を使用したPython 3のコードで、私が試したいくつかのディストリビューションを示しています。 from PIL import Image from math import exp def linear(distance, scale): return max(0, 64 - distance * scale) def exponential(distance, scale): return 64 * exp(-distance * scale) def exponential_squared(distance, scale): return 64 * exp(-distance * distance * scale) def gamma_corrected(value): corrected_value = int((value/255)**(1/2.2)*255) …

8 distribution