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

コンピューターグラフィックスの研究者やプログラマーのためのQ&A

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

2
アンビエント照明とは何ですか?
ウィキペディアは言う: アンビエント光源は、シーン内のすべてのオブジェクトに等しく影響を与える、固定強度および固定色の光源を表します。 「すべてのオブジェクトに等しく影響を与える」とは、すべてのオブジェクトが同じ量の光を受け取ることを意味しますか?したがって、シーンに3つの家がある場合、すべてのオブジェクトが同じ量の光を受け取るように、アンビエントライトソースの特定の位置を計算する必要がありますか?もしそうでなければ、あなたは周囲の光源を持っていないでしょうか? 太陽からの「通常の」照明と環境照明の違いは何ですか?
11 lighting 

2
画面スペースのアンビエントオクルージョンはどのように実装されていますか?
ウィキペディアからの説明がわかりません。 画面上のすべてのピクセルについて、ピクセルシェーダーは現在のピクセルの周囲の深度値をサンプリングし、サンプリングされた各ポイントからオクルージョンの量を計算しようとします。 周囲のピクセルの深度値は、オクルージョンについて何かを伝えることができますか?閉塞は、あなたがオブジェクトBを参照してくださいすることができないように、オブジェクトAは、別のオブジェクトBの前に立ったとき、私は理解して、たまたましかし、なぜあなたは今の深さピクセルでなり、周囲のピクセル?つまり、これらのピクセルが見えるので、オクルージョンはありません。多分私は咬合が間違っていることを理解しました。 また、他のチュートリアルではカーネルという用語も理解していません。カーネルとは何ですか、なぜそれをssaoに使用するのですか? 私の質問に関して誰かがアルゴリズムの詳細な説明をすることはできますか?


1
シェーダープログラムを変更するときに、ユニフォームまたは属性を再バインドする必要がありますか?
シーンのレンダリングには通常、複数のシェーダープログラムが含まれます。私の場合、すべてが同じ属性を使用し、少なくともいくつかのユニフォームを共有しています。それらを適切に機能させるために、私は現在安全にプレイしています。つまり、シェーダープログラムを切り替えるたびに属性を再バインドし、適切な均一の場所を取得しています。したがって、基本的に各フレームで複数回実行することは、おそらく最善の方法ではありません。 では、シェーダープログラムを切り替えた後、(一般的に)属性とユニフォームを再バインドする必要がありますか?なぜ? もしそうなら、これをプログラムの開始時に一度行い、再びそれらに触れる必要がない方法はありますか?
11 opengl  glsl  shader 

3
ランバート反射板が傾いているとき、入射放射線のより少ない部分で照明されますか?
ウィキペディアでランバートの反射について読んでいるとき、私には次のフレーズ(太字)が見つかりましたが、私には正しく聞こえません。 コンピュータグラフィックスでは、拡散反射のモデルとしてランバート反射がよく使用されます。この手法では、すべての閉じたポリゴン(3Dメッシュ内の三角形など)が、レンダリング時にすべての方向に等しく光を反射します。実際には、法線ベクトルを中心に回転したポイントは、光の反射方法を変更しません。ただし、その領域は、入射する放射のごく一部で照らされるため、その点が最初の法線ベクトルから傾くと、光の反射方法が変化します。 段落で説明した状況を想像する方法では、光源から離れる方向に傾けるだけで、特定の領域に入射する光が少なくなります。一般に、最初の法線ベクトルから離れるように傾けると、光源の位置について何も言われないので、領域ごとに入射光が増加または減少する可能性があります。 私は文脈を誤解しましたか、またはこれはウィキペディアで書き直すべきものですか?
11 shading 

1
これはビールの法則を実装する正しい方法ですか?
ビールの法則(オブジェクトを通る距離での色の吸収)を実装すると、何らかの理由でそれが非常に良く見えることはありません。 オブジェクトの背後に色がある場合、調整した色を次のように計算します。 const vec3 c_absorb = vec3(0.2,1.8,1.8); vec3 absorb = exp(-c_absorb * (distanceInObject)); behindColor *= absorb; これにより、次のようになります(少しの屈折が適用されていることに注意してください)。 そしてここでは屈折なしです: これは、ここではシェーダートイとして実装されていることに注意してください。 これは、ビールの法則の機能の説明を満たしていますが、次のようなショットと比較すると、見栄えがよくありません。 鏡面ハイライトはさておき、私は違いを理解しようとしています。それは、私のジオメトリが単純すぎて実際にそれをうまく表示できないということですか?それとも間違って実装していますか?


1
フラグメントシェーダーでテクスチャ座標を計算すると、テクスチャへのアクセスがはるかに遅くなるのはなぜですか?
GLSLでテクスチャを使用する場合、頂点シェーダーで最終的なテクスチャ座標を計算し、varyings を使用してそれらをフラグメントシェーダーに渡すのが最善です。y座標の単純な反転の例: // Vertex shader attribute vec2 texture; varying highp vec2 texCoord; // ... void main() { texCoord = vec2(texture.x, 1.0-texture.y); // ... } // Fragment shader varying highp vec2 textureCoordinates; uniform sampler2D tex; // ... void main() { highp vec4 texColor = texture2D(tex, texCoord); // ... } Y座標の反転、またはvec2(0.5)テクスチャ座標への追加などのさらに単純な操作がフラグメントシェーダーで実行される場合、テクスチャアクセスは非常に遅くなります。どうして? 注意として、たとえば、2つのテクスチャをブレンドして、それらの加重和を使用すると、時間の点ではるかに安価であり、各ピクセルに対して実行する必要があるため、テクスチャ座標自体の計算はそれほどコストがかかるとは思われません。

4
OpenGLを学ぶかDirect3Dを学ぶかは重要ですか?
これら2つのAPIの違いはマイナーな実装の詳細ですか?それは、一度学んだらすべてに使用できるということですか?または、将来的に別のAPIを再学習する必要なく一般的に使用できるようにしたい場合、どちらか一方を学習する理由はありますか?どちらか一般的ですか? 特に、どのグラフィックスカードでも書き込めるようにしたいので、コードは特定のメーカーのカードや特定のモデルでのみ実行されるように制限されていません。また、グラフィックスカードがなくても動作するコードは記述できるようになりたいと思っています(遅いですが)。 異なるプラットフォーム(オペレーティングシステム/アーキテクチャ)間で移植可能なコードがどのようになるかには違いがありますか?これらと連携する他のライブラリーが入手可能かどうか、そしてどちらか一方が広い環境でのライセンス制限を減らすかどうかに興味があります。これらの1つが私を制限することなく私が学ぶ唯一のものであるかどうかに違いをもたらす測定可能なもの。
11 opengl  api  direct3d 

2
曲線形状のハードウェアアクセラレーションによる描画
曲線形状をすばやく描画する方法は? 「すばやく」私は、ハードウェア機能をできるだけ使用するべきだと思います 「湾曲した」とは、二次または三次ベジェ曲線のいずれかによって定義された境界を意味します 「形状」とは、「太い」ストローク(つまり、幅1px以上)または偶数/奇数/ゼロ以外の塗りつぶされた「2D湾曲ポリゴン」のいずれかで、おそらく穴がある(つまり、文字「O」) 私が知っているオプションにはいくつかの欠点があるので、私は尋ねています: 形状を三角形化してOpenGLに送信する-CPUで最も困難な作業を行い、使用する三角形が少なすぎる(つまり、もったいない/粗い) テクスチャアトラス-すべての変更(形状、スケール、回転など)でテクスチャを再計算/アップロードする必要があります 符号付き距離フィールド-大規模では、詳細がきれいに見えないか、テクスチャを再計算/アップロードする必要があります NV_path_rendering-それがNvidiaのカードでのみ機能していなかった場合、それである可能性があります OpenVG-それがモバイルでのみ機能していなかった場合、それである可能性があります ? *控えめに言っても、OpenVGは正確には前進していないようです。誰かがその将来の見通しについて何か知っていますか?今日から目を離さないのは全然価値があるのでしょうか? ** OpenGL 4+は、ポリゴンのオンザフライテッセレーションの手段を提供します。形状の境界を少なくとも「斜め」に見えないように、「三角形分割」オプションからメッシュをリファインするために何らかの方法で使用できますか?

1
ボリュームレンダリングの基本的な概念と用語
ボリュームマテリアルとエフェクトのレンダリングに関する文献では、多くの数学的物理学用語を使用する傾向があります。サーフェイスレンダリングに関連する概念を適切に扱っているとしましょう。ボリュームレンダリングについて理解する必要がある概念は何ですか?(リアルタイムレンダリングとオフラインレンダリングの両方。) ボリュームレンダリングのコンテキストで光散乱とは正確にはどういう意味ですか?(そして、それがなぜ内部散乱と外部散乱に分かれているのですか?) 透過、減衰、吸収の関係は何ですか? フェーズ関数とは何ですか?ボリュームレンダリングでどのように機能しますか?(特に、Henyey-Greenstein位相関数。) ビールランバートの法則とは何ですか?それは光散乱とどのように関連していますか? 基本的に、このような図からどのように理解できますか?

3
アイスキューブをリアルに表示するにはどうすればよいですか?
氷を、水の屈折率を持つわずかに奇形の透明な立方体としてモデル化できますが、説得力がありません。それらは氷ではなくガラスの塊のように見えます。 実際のアイスキューブを見ると、いくつかの違いを直感的に説明できますが、それらに一致するように変更する物理的特性がわかりません。 アイスキューブは濡れています。鉱山は乾いたガラスのように見えます。 アイスキューブは、他の場所ではなく、場所で透明です。 アイスキューブには、分離していなくても目に見える亀裂があることがよくあります。 この例では、表面上で氷をモデル化しようとしています(水に浮かんでいない空気中)。 リアリズムを高めるためにどのようなテクニックを含める必要がありますか? 静止画を作るためだけに、リアルタイムのテクニックを探しているのではありません。氷を写実的にもクローズアップし、リアルなコースティックスとシャドウをキャストしたいです。 カーブしたエッジを使用し、氷を透明な材料の薄い層でコーティングして、水の溶けた層をシミュレートしてみましたが、濡れているような印象はありません。また、フォグエフェクトを使用して、キューブの半分のサイズの透明な球体をキューブの中央に埋め込んでみましたが、自然にキューブに溶け込むことはなく、埋め込まれたように見えます。フォグが徐々に増加する一連のネストされた球体でさえ、まだ正しく見えません。

2
サブピクセルアンチエイリアスルール
最近、テキストのサブピクセルアンチエイリアシングに問題がありました。これは非常に粗い色を生成し、それがどのように適切に行われるのかを不思議に思いました。 下のピクセルの3分の3を覆う黒いタイルの例をいくつか示しました。 色は私が見ているものと一致しますが、適切にアンチエイリアス処理されたテキストを見ると、結果はそれほど明るくなく、気を散らすものではありません。 良い光の強さと正しい色のバランスが必要だと思います。このような良い結果をもたらすサブピクセルアンチエイリアスにはどのような方法が使用されますか? 更新: 幅が3倍でマルチサンプリングの画像に白いティーポットをレンダリングしました。以下では、3つのピクセルごとの平均と、それぞれをRGBに割り当てることを比較しています。一部のケースでは色がまだ過度に明るいように見えます(特に、ここの上記の例と比較すると)。私の電話がそれらをうまく捉えているわけではありません。 よし、私のモニターには少しダスティングが必要だ

3
メモリに収まらないシーンをレイトレースするにはどうすればよいですか?
レイトレースするシーンをメモリに格納できない場合、マシンにRAMを追加しないと、シーンのさまざまな部分を1ピクセルあたり数回ディスクから読み込む必要があるため、実際のタイムスパンでレンダリングするのは現実的ではないようです。 。 これを回避する方法はありますか?メモリにロードする必要がある回数を減らすために、シーンの特定のサブセットを含む多数の計算を一度に実行するいくつかの方法を考えています。そのような場合に速度を向上させる他の方法はありますか?

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.