回答:
はい、たとえば、Unreal engine 3はBSPを使用しています。これは主に、CSGプロセス中に使用されるためです。Doom3 / id tech 4はポータルを使用しており、id Tech 5がBSPツリーに戻ったことを読んだと思います。オクトツリーを使用するゲームもいくつかあります。ゲームでは、UE3はオクルージョンクエリを使用したより動的なアプローチに移行したと理解していますが、BSPを使用して少なくともどの静的メッシュが見えているかを判断しないと驚くでしょう。他のゲームでは、ビューフラスタムカリング（文明化など）のみを使用する場合があります。実際にどのタイプのゲームを見るかによって異なります。
BSPやその他のものがまだ存在しているのは、あなたがもっとうまくやれないからです。静的なジオメトリがある場合、BSPは適切に構築すれば素晴らしいです。ただし、BSPビルダーを作成する必要がありますが、これは注意が必要です（ただし、CSGソリューションで使用する場合は無料で発生する可能性があります！）コストはかかりますが、レベルの（高価な）前処理は必要ありません。それはいくつかのゲームがやろうとしているトレードオフです（たとえば、Crytekはすべてをリアルタイムで実行したいので、静的な加速構造を構築するために処理時間を費やしません）。 CPUおよびCPUでのオクルージョンクエリの実行（これはFrostbiteエンジンによって使用されます。）
最新のアプローチについては、可視性クエリのミドルウェアであるUmbraをご覧ください。Webを少し検索すると、Umbraの初期の始まりを説明する修士論文がいくつか見つかります。
結論：BSP / Octree / no ASを使用するかどうかは、作成するゲームのタイプに大きく依存します。レベルの大部分が静的な場合は、それを利用して静的な加速構造を構築する必要があります。すべてが動的である場合、もちろん別のアプローチが必要です。
衝突検出については、BulletとPhysXおよびそれらの衝突検出アルゴリズムを見てみましょう。しかし、私の考えでは、物理学の解決策は以前よりも可視性にあまり関係していません-物理学の解決策はGPUベースのBVHを使用したいと思うかもしれません。
正直なところ、最近どのような次世代エンジンが使用されているのかわかりませんが、私が知っていることをお話しします。最適化と、その最適化を支援するために使用されるデータ構造とを混同するのは簡単です。ただし、以下で説明することはすべて最適化のためのものですが、具体的にはデータ構造がどれであるかを指摘します。
BSP：データ構造-動的に移動するオブジェクトと静的な世界のジオメトリの交差を検出します。以前は衝突の検出とジオメトリのzbufferなしでのレンダリングの両方に使用されていましたが、現在はzバッファに十分なメモリがあるため、レンダリングには使用されなくなりました。ただし、技術的にはわずかに異なる方法で生成されますが、同じツリータイプと見なされます。前処理が必要です。
OctreeまたはKd-Tree：データ構造-すべての動的オブジェクトでn ^ 2チェックを回避するために、同じ「セル」または領域にあるオブジェクトを判別するために使用されます。
これらは唯一のものではありませんが、おそらく最も一般的です。また、エンジンが一般的なジオメトリのレンダリングを回避できるようにする最適化も多数あります。ただし、次の例ではジオメトリを除外するだけで、通常はそれだけで使用されます。
ポータル：技術的にはデータ構造ではありませんが、カリングを行うには特別なものが必要です。ビューからのワールドジオメトリと動的オブジェクトジオメトリの可視性カリングに使用されます。世界を私が考える地域に分割する前処理が必要です。しかし、私は実際にこれを実装していないので、わかりません。
オクルージョンカリング：最適化-必要に応じて、おそらく動的オブジェクトの可視性カリングに使用されます。
通常のビューポートカリング：最適化-カメラのビューにないオブジェクトをカリングします。
より多くのビューポートカリング：最適化-通常のビューポートカリングは、octreeを使用してさらに最適化できます。カメラの背後にある、またはビューにないオクトツリーのセル全体を除外できます。これには、地形のパッチが含まれます（外にいる場合）。octreeによってカリングされないものはすべて、「通常のビューポートカリング」を実行します。次に、残っているものは何でもレンダリングします。
バックフェースカリング：最適化-ラスター化を防ぐために、カメラと反対側を向いているジオメトリをカリングします。通常、レンダリング状態が適切に設定されている場合、ハードウェアで行われます。
特殊なケースのデータ構造：
AABBツリーまたはSphereツリー：これらは、特殊なケースのデータ構造の一種です。凹面形状を凸面形状に変えます。たとえば、骨のあるキャラクターは技術的に凹型です。それを小さな凸状の断片に分割します。衝突検出、動的オブジェクトの可視性カリング（通常）の最適化として使用でき、凸型なので交差テストを簡単に実行できます。これらは通常、動的オブジェクトであるため、たとえばoctreeの内部に入ります。これらは、オクルージョンカリングの最適化を支援するためにも使用できます。
単一の構造を使用してすべてを表す必要がある理由はありません（シーングラフなど）。私の意見では、ある種の汎用ツリーを使用するのではなく、タスクごとに異なるデータ構造を使用した方が良いと思います。たとえば、現在作業中のエンジンでは、BSP / Octree / AABB Treeの組み合わせを、オクルージョンカリング、ビューポート、およびもちろんバックフェースカリングの最適化とともに実装する予定です。これは、1つのbspツリー、1つのoctree、およびおそらくそのoctree内に複数のaabbツリーがあることを意味します。
最適なデータ構造とアルゴリズム/最適化の選択は、おそらくエンジンでできる最大かつ最も有益なことです。