古いゲームからいくつかの古いジオメトリをレンダリングしています。彼らのクライアントは、近くにあるエリアを確認できるアルゴリズムを持っていましたが、私にはその能力がないため、不要なポリゴンをカリングすることを検討しています。現在、ゾーン全体のすべてのポリゴンを、表示できるかどうかに関係なく、視覚的な範囲内にあるかどうかに関係なくレンダリングしています。明らかに、これは完全に非効率的です。
どのタイプのカリングを使用することを検討する必要がありますか？
錐台にないポリゴンをカリングできることはわかっています。これにより、負荷の一部が軽減されますが、カメラから一定の距離にあるポリゴンをレンダリングしないことを選択できますか？これは何と呼ばれていますか？一部の地域でも霧を使用しています。同じ質問があります。霧の背後にある、見えない領域をすべてカリングできる方法を考え出すことはできますか？
考慮すべき2つの異なることがあります：あなたはそれを正しく見たい、すなわち隠面判定をしたいですか？次に、単純な深度テストがその役割を果たします。オーバーヘッドは、画面にまったく表示されないジオメトリを処理することです。ただし、それが（非常に）古いゲームである場合は、データを取得しました。すべてのアセットを含む完全なマップのポリゴン数は、画面いっぱいの最新のゲームで表示されるものよりも少ない可能性があります。その場合、パフォーマンスの問題は発生しません。
本当にパフォーマンスの問題が発生した場合は、費やしたい時間のバランスを見つけ、何が表示されているか（見えないか）を判断し、実際にレンダリングする必要があります。10年前でも、できるだけ多くのラスター化時間を節約するために、ほぼピクセルパーフェクトであることが重要でした。最新のGPUには非常に多くの予備力があるため、レンダリングに含めるものを大まかに選択するだけで十分です。
ただし、これらの計算は、OpenGLまたはその他の3DラスタライズAPI（Direct3Dなど）の範囲外です。これらのタスクは、高度なラスタライズ方法を使用して画面に三角形を描画するだけです。オブジェクト管理や上位レベルの機能はありません。したがって、これを実装するのはあなた次第です。
典型的なアプローチは、空間細分割構造を使用することです。最も人気のあるのは、Kd木、八分木、BSP木です。BSPツリーは空間的に非常に効率的ですが、計算が重くなります。個人的には、Kdツリーとoctreeのハイブリッド/組み合わせが好きです。これらは、シーンの動的な変化に合わせて簡単に変更できるからです。BSPツリーは更新するのが非常に重いです（通常は完全な再計算が必要です）。
このような空間構造を考えると、ポイントが特定の関心領域にあるかどうかを判断するのは非常に簡単です。平面などの幾何学的制約によってツリー内のノードを選択することも非常に簡単です。これにより、粗い錐台カリングの実装が非常に簡単になります。錐台クリッピング平面を使用して、平面内のツリーからすべてのノードを選択します。GPUの寿命を延ばすために、ノードを近くから遠くまで並べ替えることができます。ここでも、ツリーを再帰的に並べ替えることができるため、ツリー構造が役立ち、ほぼ最適なO（n log（n））の複雑さが得られます。
それでもレンダリングパフォーマンスを改善する必要がある場合は、ツリーによって定義された空間分割を使用して、テストされた境界によって制限されたサブツリーに戻る前に、オクルージョンクエリでテストジオメトリを（目に見えないように）レンダリングできます。
錐台にないポリゴンをカリングできることはわかっています。これにより、負荷の一部が軽減されますが、カメラから一定の距離にあるポリゴンをレンダリングしないことを選択できますか？これは何と呼ばれていますか？
これはすでに錐台自体によって行われています。遠方平面は、レンダリングされるオブジェクトへのカメラ距離制限を設定します。
glFrustumを見てください。