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

この理由はどこにもありません。phongで使用される反射ベクトルは、物理学の基礎が単純です。しかし、blinnで使用されるハーフベクトルは、一見合理的な根拠がなく、適切な反映を構成していません。それにもかかわらず、いわゆる「物理ベース」のシェーディング機能すべてで使用されています。それに物理的な基盤があれば、知りたいのですが。 私が見つけることができたのはいくつかの理由です： それは速いです -これについてはさまざまな情報がありますが、それでも1998年には大きな理由だったでしょう。 これは90度よりも高い角度をより適切に処理します。これが唯一の理由である限り、フォンの用語が不適切に使用されているためです。反射とビューのドット積は、-1〜+1の角度を与えます。通常、この角度は0〜1に固定されており、これが90度問題の直接的な原因です。角度を固定するのではなく再正規化すると、180度の完全なカバレッジが得られます。私は、単純なx * 0.5 + 0.5の操作がグラフィックスの世界を40年間逃げていたとは信じません。 エッジをより適切に処理します -エッジの「問題」もblinnソリューションにわずかに存在します。主な原因は、ターミネーターでのエリア照明の不適切なシミュレーションです。これは、「物理ベースの」シェーダーに不可欠です。しかし、より単純な状況でも、シグモイド関数はソフトターミネーターラインを正しく近似できます。ランバート項への乗算は、鏡面反射項を不適切に減衰させるため不正確です。これにより、フレネル項がキャンセルされ、さらなるエラーが発生する可能性があります。 エッジに長い反射があります -異方性反射は現実的かもしれませんが、blinnはエッジにのみ表示されるため、それらを実装する正しい方法ではないようです。H項のエラーが偶然現実的に見えるのは、単なる幸せな偶然です。 これらの理由はどれも満足のいくものではありません。この狂気を整理したいと思います。 私はブリンとフォンの話ではないのですということを明確にしたい、特に、代わりにこれらのシェーダだけでなく、他の人のための基礎として使用されているベクトル成分HとR、程度。

22 shaders  fragment-shader  shading 

遅延レンダリングに関する資料を読んだので、その要点は理解できたと思います。しかし、私が理解していないのは、それがどのように影を達成するかです。私が知る限り、Gバッファは各ライトのシャドウマップの作成を含まないため、ライティングパスが各ピクセルがオクルードされているかどうかをどのように認識するかについて混乱しています。結局のところ、カメラの視点から見える特定のピクセルは実際には特定の光の視点からは見えない可能性があり、そのオクルージョンジオメトリはカメラの視点からは見えない可能性があるため、Gバッファーに何も書き込まれません。 。 シャドウマップのレンダリングを開始すると、フォワードレンダリングとほぼ同じように見えます。シャドウマップをレンダリングするために、すべてのライトに対してシーン内のすべてのジオメトリをレンダリングします。 では、遅延レンダリングは、フォワードレンダリングと同等のシャドウをどのように実現するのでしょうか。

12 3d  shadow-mapping  deferred-rendering  shading 

たとえば、フォンモデルとブリンモデルでは、カメラの距離に応じて光の強度は変化しません。何故ですか？

11 shaders  lighting  shading 

私は私がように参照する2つの位置の間を移動するための四角形を取得しようとしている_positionAとします_positionB。どちらもタイプVector3です。長方形はうまく動きます。ただし、到達_positionBしても、本来のように反対方向に移動することはありません。 コードをもう一度見てみました。オブジェクトが移動ifすると、コード内のステートメントは、rectsの位置がに等しいフレームを逃したという結論に達しました_positionB。rectsの位置がより大きいか等しい 場合は、コードを変更して方向を逆にすることにしました_positionB。私のコードは長すぎないので、以下に表示します。 using UnityEngine; using System.Collections; public class Rectangle : MonoBehaviour { private Vector3 _positionA = new Vector3(-0.97f, -4.28f); //Start position private Vector3 _positionB = new Vector3(11.87f, -4.28f); //End position private Transform _rect_tfm; private bool _atPosA = false, _atPosB = false; public Vector2 speed = new Vector2(1f, 0f); private …

9 unity  c#  vector  mathematics  vector  matrix  unity  c#  transformation  java  3d  terrain-rendering  shading  ios  opengl-es  opengl  rendering  optimization  python  scripting  minecraft-modding  modding  pc  3d-meshes  mesh  culling  point-cloud  networking  interpolation  mathematics  game-design  ai  game-mechanics  animation  unreal-4  skeletal-animation  3dsmax  unity  c#  3d  opengl  c++  textures  unity  ide  cocos2d  cocos2d-x-js  unity  c#  mono  il2cpp  c++  game-loop  timer  linux  flash  actionscript-3  java  glsl  c++  vector  entity-component  c++  directx11  windows  visual-studio  libgdx  mouse  unity  c#  architecture  storage  unity  c#  rotation  coordinates  quaternion  vrpn  movement  vector  unreal-4  unity  shaders  unity  gui  text  bug  shooter  3d  animation  rendering  voxels  c++  mmo  multithreading  linux  textures  procedural-generation  terrain-rendering  multiplayer  mmo  game-state  java  android  libgdx  opengl  procedural-generation  unity  gui  3d  animation  tools  geometry-shader  mobile  advertisements  unity  c#  animation  scripting  unity  animation  unityscript  coroutines  unity  shaders  lighting  camera 

しばらくの間、「標準的な」フォン＆ブリンシェーダーを書いた後、最近、物理ベースのシェーディングに手を出し始めました。私を大いに助けたリソースは、これらのコースノート、特にこのペーパーです。これは、ブリンを物理的にもっともらしいシェーディングにする方法を説明しています。 私はこの論文で提案されているブリンモデルを実装しました。提案されている最も重要な変更（imo）は、フレネル反射率を含めることであり、これも問題を引き起こす部分です。残念ながら、著者は拡散反射率を省略して鏡面部分のみに焦点を合わせることにしました。たとえば、ランバート拡散反射を考えると、それを「改善された」ブリンと組み合わせる方法がわからないだけです-拡散部分と鏡面部分を追加するだけではもはや正しくないように思えるからです。 一部のシェーダーでは、関与するメディアの屈折率に基づいて、範囲0〜1の浮動小数点「フレネル項」が使用されているのを見ました。シュリックの近似が毎回使用されます： float schlick( in vec3 v0, in vec3 v1, in float n1, in float n2 ) { float f0 = ( n1 - n2 ) / ( n1 + n2 ); f0 *= f0; return f0 + ( 1 - f0 ) * pow( dot( v0, v1 ), …

8 opengl  shading 

DirectXでのレイトレーシングにいくつかの問題があり、特にスペキュラに関する深刻なバンディングの問題があります。高い鏡面反射力（8以上）でバンディングが始まります。これがHDR / LDRの問題なのか、それとも法線や他のベクトルなど、他の何かに関連している可能性があるのでしょうか。 更新 更新については以下をご覧ください。 これは、球体上のブリンフォンに関連するシェーダーコードです。 float3 hitPoint = thisRay.origin + thisRay.direction * bestHit.hitT; float3 normal = normalize(hitPoint - spheres[bestHit.hitID].center); float3 toLight = pointLights[0].position.xyz - hitPoint; float d = length(toLight); toLight = normalize(toLight); float diffuse = max(dot(normal, toLight), 0.0f); float3 v = normalize(thisRay.origin - hitPoint); float3 h = normalize(v + …

8 normals  raytracing  hdr  shading