Почему современные игры используют рендеринг в текстуру для зеркал?

При взгляде на старые игры, такие как Mario64 или DukeNukem3D, все зеркала в игре - это, по сути, просто дыры в стене с зеркальной копией геометрии перед зеркалом, помещенным за ними. В случае DukeNukem3D можно даже активировать no-clip и войти в эту зеркальную комнату.

Напротив, современные игры используют рендеринг в текстуру для зеркал. Это приводит к тому, что зеркала становятся заметно неровными при приближении к ним. Одной из первых игр, в которых я заметил такой подход, был Luigi's Mansion, но, похоже, он используется почти во всех современных играх.

Какие изменения в оборудовании или движках сделали второй подход настолько доминирующим в наши дни и каковы его преимущества? С точки зрения чистой визуализации первый подход выглядит лучше, так как он не страдает от проблем пикселизации.

1. Использование RTT (рендеринга в текстуру) позволяет легко масштабировать качество рендеринга (разрешение, LOD, сложность освещения) для регулируемой производительности. RTT также облегчает замену поверхности кубической картой на определенном расстоянии, где трудно точно увидеть отражение.
2. Поскольку на выходе получается текстура, есть больше опций относительно того, что можно сделать с ней позже (освещение, затенение, смешивание, искажение и т. Д.).
3. Если зеркальная версия геометрии помещается в сцену, это потребует более сложной отбраковки, когда она пересекается с реальной геометрией и может быть видна за углом. В старых играх уровни были разработаны, чтобы избежать этого. Не говоря уже о том, что кто-то должен делать реальное зеркалирование.
4. Если геометрия не отражается вручную, рендеринг должен выполняться путем изменения матрицы вида и режима отбраковки (чтобы компенсировать инверсию пространства в матрице) и использования буфера трафарета для вырезания зеркала. Современные движки предпочитают создавать все состояния рендеринга заранее, поэтому возникнет небольшая проблема с копированием каждого состояния рендеринга сцены с необходимыми изменениями для зеркального рендеринга.

Таким образом, в основном использование RTT дает больше свободы каждому.

Нет, вы не правы - зеркала Duke Nukem 3D работают совсем не так.

DN3D использовал движок портала . Соединение между любыми двумя секторами было в некоторой степени произвольным, и когда механизм рендеринга пришел на портал, он знал, что должен начать рендеринг другого сектора в этом. Сектор за зеркалом был в основном заполнителем, чтобы справиться с причудой в двигателе - единственная точка сектора должна была быть больше, чем все, что вам нужно, «отражалось». Он не содержал никакой реальной геометрии. Фактически, он работал почти так же, как «порталы» в Portal, за исключением того, что Portal (сам по себе основанный на движке портала) создает порталы во время выполнения и имеет ограничение на количество повторений порталов (т. Е. A -> B -> A -> B -> A ...), в то время как Build (DN3D) просто потерпит крах, так как его стек переполнится, если вы направите зеркало на другое зеркало.

Понятно, как просто реализовать зеркало с этим - сделать портал, указывающий обратно в комнату. Это означало, что рендеринг зеркала будет стоить ровно столько же, сколько и рендеринг самой комнаты, обеспечивая высокую производительность и согласованность. Пока вы не указали зеркало на другое зеркало. Если вы посмотрите исходный код механизма сборки, то увидите, что в коде вообще нет зеркал для обработки кода - он не должен быть, потому что так работают порталы. ПРИМЕЧАНИЕ: на самом деле, есть код для переворачивания визуализированных пикселей - это просто не переворачивает геометрию и все различные спрайты и эффекты, Редактор должен был быть в состоянии сделать эти «поддельные» порталы, оглядываясь назад на себя. Если вы хотите узнать больше о довольно умном движке Build, Фабьен Санглард (Fabien Sanglard) может предложить вам отличный анализ внутренних компонентов движка Build . Весь движок был с открытым исходным кодом и портирован на современные платформы, хотя старый все еще работает безупречно на Windows 10 (проверено для вас: P). Многие игры, основанные на Build, также были с открытым исходным кодом и / или переделаны.

Почему это больше не используется? Ну, некоторые движки больше не предпочитают порталы, например. Сложно применять множество графических хаков и оптимизаций - я не могу указать вам на что-то конкретное, но большая часть пост-обработки зависит от хаков, которые не будут работать в реальном движке портала (они делают много предположений, которые больше не держу). Это в основном та же проблема, что и в играх со стереоскопическими изображениями - хаки больше не работают.

Самое главное, что зеркала стали более сложными. Они могут иметь сложные формы, текстуры, они могут быть на земле (также известные как «вода») и т. Д. Хотя все эти проблемы решаются в движке портала, RTT становится более простым выбором в некоторый момент, а графические процессоры достаточно быстры справиться с этим.

Однако, несмотря на это, существует множество игр с аппаратным 3D-ускорением, которые делают вещи «настоящими». Например, из более старых игр: Quake 3 или Alien vs. Predator. Насколько я знаю, в движке Source по-прежнему используются «настоящие» зеркала. Если вы ожидаете, что люди будут приближаться к зеркалу, и вы можете гарантировать, что не будет слишком много отражающих поверхностей одновременно (например, благодаря дизайну уровней), портальные зеркала по-прежнему очень привлекательны.

RTT был бы использован, если бы это было возможно, но конвейер аппаратного рендеринга был одним из способов.

Старое оборудование также имело ограничения, которые мешали рендерить текстуру. Запись в RAM означает, что она не может быть прочитана одновременно. Чтобы улучшить производительность рендеринга, целевой буфер был заблокирован только для записи, только дисплейное оборудование могло читать с него. Вы могли запросить чтение, но это заблокировало ОЗУ, и рендеринг должен был ждать снятия блокировки, прежде чем он сможет начать следующий кадр. RTT вызовет серьезное узкое место в трубопроводе, и поэтому будут использованы другие решения.

Вы обнаружите, что для аппаратных конвейеров рендеринга использовалась норма RTT, поскольку она обеспечивала способ уменьшить нагрузку рендеринга. 3D рендеринг спрайтам для обеспечения псевдо 3D контента. Рендеринг текстур был слишком дорогостоящим (ЦП), чтобы использоваться тогда, за исключением специализированных машин, которые были вне общего потребительского рынка.

Duke Nukem решает, что, перерисовывая геометрию за зеркалом, другие ответы частично верны. За зеркалами есть области, которые на самом деле не содержат геометрии (в файлах игровых данных), геометрия перерисовывается при воздействии времени выполнения, причина существования этих областей состоит в том, чтобы избежать случайного размещения там части уровня при редактировании уровня :

так как область помечена, вы случайно не поместите туда какую-либо геометрию.