タグ付けされた質問 「rendering」

オリジナルのTorrance-Sparrow BRDFのような単一散乱マイクロファセットベースの表面モデル、またはWalterらによる粗い誘電体表面のBSDFのような派生モデル。マイクロファセット間の光の相互反射を無視します。これにより、特に粗さの値が高くなると、エネルギー損失が発生して暗くなる原因となります。 この問題は、ファーネステストを使用して簡単に実証できます。次の画像は、0.2から1.0までの粗さパラメーターのスミスモデルとGGX分布を使用した導電性マイクロファセットBRDFの実装の動作を示しています（問題を見やすくするために、ここではフレネル係数を意図的に1に設定しています）。 0.2から1.0までの粗さパラメーターのスミスモデルとGGXマイクロファセット分布を使用した粗い誘電体（IoR 1.51）BSDFのファーネステスト： エリックハイツ他 は最近、光の相互作用を完全に解決することによって暗くなる問題を解決する多重散乱モデルを提案しましたが、LuxRenderフォーラムでHeitz自身が言及したように、その評価ルーチンの確率論的な性質に起因するパフォーマンスの問題があります。 単一散乱モデルの失われたエネルギーを回復するための既知の補償方法はありますか？必ずしも物理的に正しいわけではありませんが、少なくとも物理的な妥当性（ヘルムホルツの相反性とエネルギーの節約）を壊しすぎないようにします。理想的には、手動でパラメータを調整する必要はありません。 でディズニーBSDF、そこに端で暗くの補償のために使用することができる「光沢」と呼ばれるパラメータ化コンポーネント（基本的にはフレネルベースの光沢のある葉）があるが、彼らは彼らの中で言及してシーグラフ2015もちろん、それは非常にアドホックメソッドです。 「...これは非常に概算であり、他の粗さの値ではうまく機能しません...」 LuxRenderフォーラムでの前述の Eric Heitz のコメントも、補償ハックを使用することを提案していますが、残念ながら詳細については触れていません。 私の知る限り、より単純なハックを使用して、単一散乱モデルのエネルギー保存を改善できます（アルベドの微調整など）。ただし、これを行うと、BSDFの相反性を壊さずに、完全にエネルギーを節約する材料（たとえば、完全な白い粗いガラス）を得ることができません。

11 rendering  brdf  physically-based  microfacet 

私は多くの混乱を抱えており、いくつかの用語を明確にし、知識をまとめる必要があります。 エンジンがレイトレーサーである（つまり、レイトレーシングアルゴリズムを使用してシーンをレンダリングする）と言った場合、それは自動的に物理ベースのエンジンですか？つまり、レイトレーシングはその定義に基づいて物理的に基づいていますが、物理的に基づいていないレイトレーサーが存在する可能性があります。（そして対称的に、物理ベースの非レイトレーサーはありますか？） また、「物理ベース」は「光輸送方程式を解く」という意味でもあるのですか？

11 rendering 

フォンシェーディングを使用して単一の光源でシーンをレンダリングするには、マテリアルと光源の両方のアンビエント/拡散/鏡面反射光コンポーネントに基づいて、フラグメントシェーダーに渡される各フラグメントの最終的な色を計算できます。 これは、個々の光源をフラグメントに適用した結果を次のように追加することで、複数の光源に対応するように簡単に拡張できます。 final_color = (0, 0, 0, 1) for each light: final_color += apply_light(material, light) final_color = clamp(final_color, (0,0,0,1), (1,1,1,1)) ただし、光源の数が非常に多い場合、このプロセスは非常に遅くなります。でN点灯し、このアプローチが行われるシェーディングフォンのための計算が必要ですNフラグメントあたりの回。 非常に多数の光源（数百、数千など）でシーンをレンダリングするためのより良いアプローチはありますか？

10 rendering  shader  lighting 

私の基本的な理解から、頂点バッファーオブジェクトは次のように機能します（擬似コード）。 通常、正方形を描くと言いたい場合は、線の描画コマンドを発行できます。 line (0, 0) -> (1, 0) line (1, 0) -> (1, 1) line (1, 1) -> (0, 1) line (0, 1) -> (0, 0) VBOを使用すると、私が正しく理解していれば、頂点をVBOにロードします。 define VBO load (0,0) -> VBO load (1,0) -> VBO load (1,1) -> VBO load (0,1) -> VBO load (0,0) -> VBO その後、1つの描画コマンドを発行できます。 …

10 performance  rendering  vertex-buffer-object 

完全な反射の場合、表面にG2連続性が必要なのはなぜですか（クラスA表面）？ 数学的な答えをお願いします。

10 rendering 

シャドウマッピングのしくみはわかっていますが、シャドウニキビの原因がわかりません。誰でも簡単にシャドウニキビの原因を教えてもらえますか？それはデプスマップの解像度とどのように関連していますか？

10 opengl  raytracing  rendering  shader  transformations 

今四半期はコンピュータグラフィックスコースを受講しています。私たちのラボプロジェクトの1つは、ソフトウェアのラスタライズに関するものです。 現在、私はプロジェクトの提案を計画しており、それを現代のゲーム開発において他の人々に役立つようにする方法を考えています。 少し調べた後、ソフトウェアオクルージョンカリングと呼ばれる手法を学びました。さまざまな解像度のバッファでソフトウェアラスタライズを行います。また、階層zバッファーを使用してオクルージョンを照会できます。 私の質問：ソフトウェアオクルージョンカリング以外の最新のゲームエンジンでのソフトウェアラスタライゼーションの使用法は何ですか？

9 rendering 

64ビットのワードアドレス指定可能なコンピューターがあり、バイナリイメージのビットマップとして格納されている5x7文字（下図のような）をメモリマップディスプレイに出力するようにプログラムしたいとします。 1文字あたり5 x 7 = 35ピクセルなので、1つの単語に35ビットを使用して文字を格納できます。最下位ビットがワードの左側から始まり、上記のように画像の各ピクセルがn番目のビットで表される場合、上記の数値「3」は、01110100010000100110000011000101110としてメモリに格納され、その後に29が使用されません。ビットは0に設定されています。 これは、キャラクターが古い/現代のコンピューターにどのように保存されているのですか？または、代わりにピクセルごとに1バイト/ワードを使用しますか？ これらがこの方法で格納されている場合、アセンブリ/マシンコードのルーチン（コンピューターの命令セットアーキテクチャーからのビット単位、算術、およびデータ転送操作などの基本命令のみを使用）は、このデータをディスプレイはこんな感じ？それは次のようなものでしょうか？ 更新する現在のピクセルのxおよびy表示座標を特定のレジスタに格納します。 選択した2つのRGB値（この場合、緑の場合は0、255、0、黒の場合は0、0、0）を他の2つの別のレジスタに保存します。 さらに2つのレジスターを5および7に初期化されたカウンターとして機能させ、レンダリングされるイメージの現在の行と列を追跡します。 列レジスタが0ではないかどうかをテストします。そうでない場合は、ビットマップのLSBが1に設定されているかどうかをテストし、結果に応じてそれぞれのRGB値レジスタとxおよびy座標レジスタをANDで結合し、その結果をMOVしますディスプレイ出力レジスタに。 行カウンタレジスタを1だけデクリメントして、0かどうかをテストします。0の場合は、それを5に戻して、y座標を1だけインクリメントし、列カウンタを1だけデクリメントします。 ビットマップを保持するレジスタを1ビット左にシフトします。 JMPから命令へ4。 これを行うためのより簡単またはより効率的な方法はありますか？単一の小さなテキスト文字をレンダリングするような単純なものでさえ、かなりの数の操作を必要とし、約200 CPUサイクルを要するようです。 最後に、マシンレベルのコードにゼロから画像を表示するための優れた書籍やリソースはありますか？この特定の主題について光沢があるか、コードが高級言語で記述されているか、またはマクロを使用するアセンブラ。これらはすべて「不正行為」であり、基本的に最下位レベルで行われていることを説明していません。

9 rendering  2d  bitmap-graphics 

マイクロファセットBRDFモデルを実装しようとしています。セバスチャンラガルドのスライドを読んでいます。コードに数式を実装しましたが、結果の画像が間違っていると思います。 黄色は素材のベースカラーです。鏡面色は正しく見えるように赤です。 私のコード： // Fragment Shader #version 330 core in vec3 Position; in vec2 TexCoord0; in vec3 Normal; in vec3 Tangent; out vec4 FinalColor; uniform vec3 uCameraPosition; // init value: vec3(0, 0, 5) #define PI 3.1415926f #define EPSILON 10e-5f #define saturate(value) clamp(value, 0.0f, 1.0f); float BRDF_Lambert(float NdotL) { return NdotL; …

9 rendering  glsl  shading  specular 

1986年にKajiyaによって導入されたレンダリング方程式が、直接/解析的に解決できないのはなぜですか？

9 raytracing  rendering  lighting  brdf  global-illumination 

私は最新のOpenGL（3.1以降）を使用してレンダラーを作成していますが、今ではユニフォームを処理する効率的で柔軟な方法を作成しようとしています。私は、均一なバッファオブジェクトと、これらを使用するための「一般的な」アプローチとは何かを調べてきました（後者は、残念ながら、期待していたほど多くの結果が得られませんでした）。 OpenGL API呼び出しを減らし、連続したメモリにデータを保存するために、GPUにアップロードする必要がある各データ構造に対して複数の大きなバッファーを作成することを検討しています。各バッファの最大サイズは16kbです（私が理解しているところによると、これはUBOで使用できることが保証されています）。オブジェクトがユニフォームをGPUにアップロードできるようにしたい場合、まだいっぱいではない、アップロード対象のタイプの最初のバッファーをフェッチし、そのバッファー内で次に使用可能なインデックスを取得します。オブジェクトが描画されると、UBOがバインドされ（まだバインドされていない場合）、UBOの要素インデックスがアップロードされます。 これにより、次のような結果になります。 layout(std140) uniform ModelData { mat4 model_matrix[kNumInstancesPerModelUbo]; } uniform int u_ModelDataIndex; layout(std140) uniform SkeletonData { mat4 bone_transforms[kNumInstancesPerSkeletonUbo][kMaxBones]; } uniform int u_SkeletonDataIndex; ただし、次のことも検討しています。 layout(std140) uniform MeshData { mat4 model_matrix[kNumInstancesPerMeshUbo]; mat4 bone_transforms[kNumInstancesPerMeshUbo][kMaxBones]; } uniform int u_MeshDataIndex; いくつかの点で、これは、アップロードされるメッシュに関連するすべてのデータにアクセスするために単一のインデックスを必要とするという点で、はるかにきれいに感じられます。一方、これは手に負えない可能性があります（16kbより大きいバッファーサイズ、無関係なデータ（スケルトンのないメッシュなど）へのハンドル）、またはモデルマトリックスのアップロード中にボーンを言うためのアクセスが許可されていないため、同期の問題も発生します）これがGPUのメモリレイアウトにどのように影響するかはわかりません。 率直に言って、私はここで立ち往生しているように感じ、UBOを高速で柔軟に処理する方法の具体的な例を見つけることができません。 ここで私を助けることができるアドバイスやリソースはありますか？

8 opengl  rendering  glsl  c++  uniform-buffer-object 

最近、従来のシャドウマッピングのシャドウニキビ問題の解決を模索しながら、指数シャドウマップを実装しました。トリックはありましたが（ニキビはまったくありません）、同時に他の許容できないエラーが発生しました。 深度マップのぼかしには、最小のsigma = 1のガウスぼかしを使用します。 シャドウマップのテスト： float occluder = texture(shadowMap lightCoords.xy).r; float c = 5000.0; float receiver = lightCoords.z; float shadow = exp(c*(occluder-receiver)); shadow = clamp(shadow, 0.0, 1.0); 小さなc係数c=100.0： 許容できない光のにじみ 高いc係数でc=5000.0： 光のにじみはありませんが、高周波の細部が「腫れ」ているように見えます。 最適なcを見つけることができません-でも光のにじみが現れc=3000.0、高周波のシャドウエラーが既に発生しています。デプスマップをぼかすことは役立ちませんが、エイリアシングが発生します。 そして私の質問は、このテクニック（ESM）をどのように改善できるか、または別のテクニックを探す必要があるかどうかです。ウィッチャー3やフォールアウト4などの最新のゲームで見られるように、優れたパフォーマンスを備えた高品質のシャドウは間違いなく可能だと思います。

8 rendering  shadow 

私はGPUのハードウェアレベルで実際に何が起きているのかを少し掘り下げていたところ、少なくとも緑色のボックスについては、パイプラインをかなりよく説明する三角形の NVidiaのLifeを見つけました。私が明確にしていないことの1つは、同じ頂点がさまざまな三角形の束に使用されている場合に、インデックス付きメッシュで何が起こるかです。データは通常、ストリームプロセッサで必要以上に永続化されないため、頂点はラスタライズされた後に破棄されるだけで、新しい三角形に表示されるたびにフェッチされ、頂点シェーダーを再び通過すると思います。誰でもこれを確認できますか？また、ラインストリップモードまたはトライアングルストリップモードではどうなりますか？これらの場合、2つまたは3つの関連プリミティブがラスタライズされるまで、GPUは変換された頂点データをどこかに保持しますか？

8 rendering 

これが教科書でのレンダリング方程式の書き方です L （p 、ω ）=Le（p 、ω ）+ ∫f（p 、ω私、ω ）L （p ∗ 、−ω私）cosθdω私L(p,ω)=Le(p,ω)+∫f(p,ωi,ω)L(p∗,−ωi)cos⁡θdωiL(p,\omega) = L_e(p,\omega) + \int f(p,\omega_i,\omega) \, L(p*,-\omega_i)\cos \theta \, d\omega_i この方程式のどのコンポーネントがシャドウイングを処理しますか？

8 rendering  shadow 

ジオメトリとコンピューティングシェーダーのプログラミングの経験はありますが、フラグメントシェーダーを実際に使ってみたことはありません。現在、私はそれらがどのように機能するか、そしてそれらの可能性をよりよく理解しようとしています。私が複数の場所で読んだことの1つは、フラグメント（スクリーンピクセル）がフラグメントシェーダー内でそれ自体を超えて拡張できないことです。つまり、反復される特定のフラグメントは、それ自体にのみ影響を与えることができます。 したがって、私は学習のために、次のことが可能かどうか（可能であれば、一般的にはどのようにして達成できるか）を知りたいと思います。簡単にするために、2つの頂点のみからなるポイントメッシュ（3Dワールド空間に配置）があるとします。これらの2つの頂点のそれぞれが画面上のWorldToViewportの正確な位置に描画されるようにシェーダーをプログラムできますか。また、radius = Rの各頂点を囲む円も、それらが延長されている場合でも周囲のピクセルに描画されます。シェーダーがアタッチされている元のメッシュを超えていますか？下の図のように（円の中心にある赤い四角形が画面に描かれた頂点を表します）： それが可能であれば、頂点を超えて延びるこれらの円が互いの色（RGBA）に影響を与えるように、シェーダーをプログラムすることもできますか？下の図のように： 私が言ったように、これらが可能であるなら、私はそのようなことを達成する方法の少しを概念的または実際的な面で聞きたいです。フラグメントシェーダーで行われますか、それとも頂点シェーダーまたはジオメトリシェーダーで前に計算する必要がありますか？メッシュボディが占めるフラグメントを超えて「追加のフラグメント」を計算して渡す方法は？

8 rendering  shader  pixel-shader  drawing