いいえ、あなたは間違っています-それはデュークヌケム3Dのミラーの仕組みではありません。
DN3Dはポータルエンジンを使用しました。任意の2つのセクター間の結合はある程度任意であり、レンダリングエンジンがポータルに到達したとき、その中の別のセクターのレンダリングを開始する必要があることがわかりました。鏡の後ろのセクターは、基本的にエンジンの癖に対処するためのプレースホルダーでした-セクターの唯一のポイントは、「反映」する必要があるものよりも大きくすることでした。実際のジオメトリは含まれていませんでした。実際、Portalで「ポータル」が機能するのとほぼ同じように機能しました-ポータル（ポータルエンジンに基づいている）が実行時にポータルを作成し、ポータルが再帰できる回数（つまりA -> B-> A-> B-> A ...）。一方、ビルド（DN3D）は、ミラーを別のミラーに向けるとスタックがオーバーフローするため、単にクラッシュします。
そのポイントポータルを作る-それは簡単で、それはそれとミラーを実装する方法を明らかだ戻って部屋の中へ。つまり、ミラーのレンダリングには、ルーム自体のレンダリングとまったく同じコストがかかり、優れたパフォーマンスと一貫性が得られます。ミラーを別のミラーに向けていない限り、そうです。ビルドエンジンのソースコードを見ると、ミラーを処理するコードがまったくない ことがわかります-ミラーは必要ありません。ポータルがどのように機能するのかということに注意してください。ジオメトリとすべてのさまざまなスプライトとエフェクトを反転させません。ただし、編集者はこれらの「偽の」ポータルを作成できる必要がありました。非常にスマートなBuildエンジンについて詳しく知りたい場合は、Build engine internalsでFabien Sanglardによる優れた分析があります。エンジン全体はオープンソース化され、最新のプラットフォームにも移植されていますが、古いエンジンはWindows 10でも問題なく動作します（テスト済み：P）。Buildに基づいたゲームの多くは、オープンソース化および/またはリメイクされています。
なぜこれはもはや使用されないのですか？さて、一部のエンジンはポータルを好まなくなりました。多くのグラフィックスハックと最適化を適用するのは難しいです-特定のことを指摘することはできませんが、多くの後処理は、真のポータルエンジンでは機能しないハックに依存しています（もはや保持しません）。これは基本的に、これらのゲームが立体画像に関して持つ同じ種類の問題です-ハックはもはや機能しません。
最も重要なことは、ミラーがより複雑になったことです。これらの問題はすべてポータルエンジンで解決できますが、RTTはある時点でより簡単な選択になり、GPUは十分に高速になります。それを処理します。
ただし、それでも、ハードウェア3Dアクセラレーションを備えた「現実の」動作を行うゲームはたくさんあります。古いゲームの例として、Quake 3またはAlien vs. Predatorなどがあります。私の知る限り、ソースエンジンのゲームはまだ「実際の」ミラーを使用しています。人々が鏡に近づくと予想し、同時に反射面が多すぎないことを保証できる場合（レベル設計など）、ポータルミラーは依然として非常に魅力的です。