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


40

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

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

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


14
Что если вы хотите зеркало на двери между двумя комнатами?
Superbest

Ответы:


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

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


На 3 .: Большинство (более старых) игровых движков FPS использовали алгоритмы деления пополам (например, знаменитый «движок портала», используемый DOOM), которые уже выполняют отсечение (скорее всего, четырехугольных) полигонов для отбора видимости. Такие двигатели могут легко протолкнуть четырехугольное «зеркало» в качестве смотрового портала в комнату за зеркалом, не беспокоясь о зеркальной геометрии за пределами зеркала.
Дронус

@ Dronus Что? Чем заняться созданием "зеркала" на первом месте? Просто откройте дыру в стене.
С. Тарык Четин

Поскольку реальная геометрия не может оставить пространство за зеркальной стеной, как и у настоящего зеркала, не нужно иметь место позади для работы.
Дронус

29

Нет, вы не правы - зеркала 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 по-прежнему используются «настоящие» зеркала. Если вы ожидаете, что люди будут приближаться к зеркалу, и вы можете гарантировать, что не будет слишком много отражающих поверхностей одновременно (например, благодаря дизайну уровней), портальные зеркала по-прежнему очень привлекательны.


По-видимому, причина того, что Duke Nukem 3D работал таким образом, заключается в том, что в реальных планах уровней пространство за зеркалом столь же велико, как и пространство, которое оно отражает, хотя движок рендеринга на самом деле этого не требует.
Random832

Кроме того, не-зеркальные порталы, ну, в общем- то, не отражают вещи, поэтому я не знаю, как «нет зеркал для обработки кода».
Random832

5
@ Random832 Это было своего рода требование - были некоторые визуальные артефакты, если какой-то сектор появился в том месте, где должна была быть зеркальная комната. Это одна из тех частей, где в основном безвредные предположения имеют большое значение для производительности. Если вы когда-нибудь играли с Build, вы могли заметить, что когда два сектора пересекаются на одной высоте, они не будут хорошо отображаться. Что касается зеркалирования, оно работает так же, как и в реальных зеркалах. Вы когда-нибудь задумывались, почему зеркала только «переворачивают» на оси Y? По той же причине вам не нужно переворачивать портал, который соединяет вас с той же комнатой.
Луаан

Дело в том, что обычный портал, ведущий в комнату, обращенную в противоположном направлении , должен поворачивать вещи на 180 градусов, а не отражать их. Поэтому способность не делать этого считается специальной обработкой зеркал. (Отсутствие возможности сделать это будет означать, что порталы не работают как порталы и подходят только для зеркал, и в этом случае вся система специально обрабатывает зеркала). И да, я знаю, почему зеркала «только« переворачивают »по оси Y». На самом деле, они переворачиваются на оси Z. Но тот факт, что они переворачивают нечетное количество осей, отличает их от порталов.
Random832

@ Random832 Зависит от того, что вы называете осью Y, конечно :) И да, вы правы, есть особая обработка. Но это очень интересно - он переворачивает визуализированные данные, а не геометрию (и спрайты и все ... довольно много работы, на самом деле). Фрейм портала переворачивается, портал отображается как обычно, а затем все отображается в обратном порядке, строка за строкой.
Луаан

3

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

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

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


1

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

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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.