昔々、> が < より速かった頃... えっ、何? 質問する

昔々、> が < より速かった頃... えっ、何? 質問する

私は素晴らしい OpenGL チュートリアルを読んでいます。本当に素晴らしいです。信じてください。私が現在取り組んでいるトピックは Z バッファです。それが何であるかを説明する以外に、著者は GL_LESS、GL_ALWAYS などのカスタム深度テストを実行できることに言及しています。また、深度値の実際の意味 (どれがトップでどれがそうでないか) もカスタマイズできることも説明しています。ここまでは理解できました。そして、著者は信じられないことを言います。

zNear の範囲は、zFar の範囲よりも大きくなる場合があります。その場合、ビューアーから最も近いか最も遠いかという観点から、ウィンドウ スペースの値が逆転します。

先ほど、ウィンドウ空間の Z 値 0 が最も近く、1 が最も遠いと言われました。ただし、クリップ空間の Z 値が否定された場合、深度 1 がビューに最も近くなり、深度 0 が最も遠くなります。ただし、深度テストの方向を反転すると (GL_LESS から GL_GREATER など)、まったく同じ結果が得られます。つまり、これは単なる慣例です。実際、Z の符号と深度テストを反転することは、かつて多くのゲームにとって重要なパフォーマンス最適化でした。

私の理解が正しければ、パフォーマンスの点では、Z の符号と深度テストを反転することは、<比較を比較に変更することにすぎません>。したがって、私の理解が正しければ、そして著者が嘘をついたりでっち上げたりしていなければ、変更すること<は多くのゲームにとって重要な最適化>でした。

著者がでっちあげているのか、私が何かを誤解しているのか、それとも、本当に once の方が(著者が言うように、極めて<)遅かったのでしょうか。>

この非常に興味深い問題を明確にしていただきありがとうございます。

免責事項: アルゴリズムの複雑さが最適化の主な原因であることは十分承知しています。さらに、今日ではそれが何の違いも生まないだろうと私は考えていますし、私は何かを最適化するためにこれを尋ねているわけではありません。私はただ、非常に、痛ましく、おそらく法外なほど好奇心が強いだけです。

ベストアンサー1

私の理解が正しければ、パフォーマンスの点では、Z の符号と深度テストを反転することは、< 比較を > 比較に変更することと同じです。したがって、私の理解が正しければ、そして著者が嘘をついたり作り話をしたりしていなければ、< を > に変更することは、多くのゲームにとって重要な最適化でした。

それほど重要ではなかったので、特にうまく説明しませんでした。ただ、興味深い雑学として付け加えておくといいと思っただけです。アルゴリズムについて具体的に説明するつもりはありませんでした。

ただし、コンテキストが重要です。< 比較が > 比較よりも高速であるとは言っていません。覚えておいてください。ここでは、CPU ではなく、グラフィックス ハードウェアの深度テストについて話していますoperator<

GL_LESS私が言及していたのは、1 つのフレームを[0, 0.5] の範囲で使用する特定の古い最適化です。次のフレームでは、 GL_GREATER[1.0, 0.5] の範囲でレンダリングします。フレームごとに文字通り「Z の符号と深度テストを反転」しながら行ったり来たりします。

これにより、深度精度が 1 ビット失われますが、深度バッファをクリアする必要がなくなりました。これは、かつてはかなり時間のかかる操作でした。深度クリアは、現在では無料であるだけでなく、この手法よりも実際に高速であるため、人々はもはやこれを行いません。

おすすめ記事