Чому сучасні ігри використовують дзеркальний підхід до текстурування?

Якщо дивитися на старі ігри, такі як Mario64 або DukeNukem3D, то всі дзеркала в грі - це по суті лише отвори в стіні з дзеркальною копією геометрії перед дзеркалом, поставленим за ними. У випадку з DukeNukem3D можна навіть активувати беззахисний кліп і зайти в цю дзеркальну кімнату.

На відміну від сучасних ігор використовується дзеркальний підхід до текстури. Це призводить до того, що дзеркала помітно пікселюються при наближенні до них. Однією з перших ігор, яку я помітив у цьому підході, був особняк Луїджі, але він, здається, використовується майже у всіх сучасних іграх.

Які зміни в апараті чи двигунах зробили другий підхід настільки домінуючим в наші дні і які переваги від нього? Що стосується чистої візуалізації, то перший підхід здається вищим, оскільки він не страждає від пікселяції.

1. Використання RTT (текстура відтворення) дозволяє легко масштабувати якість візуалізації (роздільна здатність, LOD, складність освітлення) для регульованої продуктивності. RTT також полегшує заміну поверхні на кубічну карту на певній відстані, де важко точно побачити відображення.
2. Оскільки вихід є текстурою, є більше варіантів щодо того, що можна зробити з ним згодом (освітлення, затінення, змішування, спотворення тощо).
3. Якщо дзеркальну версію геометрії помістити в сцену, вона потребує більш складного відсікання, коли вона перетинається з реальною геометрією і її можна побачити за кутом. У старих іграх рівні були розроблені, щоб цього уникнути. Не кажучи вже про те, що хтось повинен зробити власне дзеркальне відображення.
4. Якщо геометрія не відображається вручну, рендерінг повинен здійснюватися шляхом зміни матриці подання та режиму відсікання (для компенсації інверсії простору в матриці) та використання буфера трафарету для вирізання дзеркала. Сучасні двигуни вважають за краще створювати всі стани візуалізації заздалегідь, тому виникне незначна проблема із створенням копій кожного стану візуалізації сцени з необхідними змінами для дзеркального візуалізації.

Тому в основному використання RTT дає більше свободи для всіх.

Ні, ви помиляєтесь - так зовсім не так працювали дзеркала Duke Nukem 3D.

DN3D використовував двигун порталу . Спільний зв'язок між будь-якими двома секторами був довільним до певної міри, і коли двигун візуалізації з'явився на порталі, він знав, що він повинен почати рендерувати інший сектор у цьому. Сектор за дзеркалом, по суті, був власником місця для вирішення химерності двигуна - єдиний пункт сектора повинен був бути більшим за все, що вам потрібно «відбивати». Він не містив реальної геометрії. Насправді, він працював майже так само, як "Портали" працюють на Порталі - за винятком того, що Портал (сам, що базується на двигуні порталу) створює портали під час виконання, і має обмеження, скільки разів портали можуть повторюватися (тобто A -> B -> A -> B -> A ...), тоді як Build (DN3D) просто руйнується, коли його стек переповнений, якби ви вказали дзеркало на інше дзеркало.

Очевидно, наскільки просто виконати дзеркало з цим - зробіть портал, який вказує назад у приміщення. Це означало, що надання дзеркала буде коштувати рівно стільки ж, скільки і надання самої кімнати, що дасть велику продуктивність та послідовність. Поки ви не вказували дзеркало на інше дзеркало, тобто. Якщо ви подивитесь на вихідний код двигуна Build, ви побачите, що взагалі немає дзеркал обробки коду - не повинно бути жодного, оскільки саме так працюють портали ПРИМІТКА. Насправді є код для перегортання відтворених пікселів - це просто не перевертає геометрію та всі різні спрати та ефекти. Редактор повинен був вміти робити ці "фальшиві" портали, хоча - озираючись на себе. Якщо ви хочете дізнатися більше про досить розумний двигун Build, є чудовий аналіз Фабієна Сангларда на внутрішніх системах двигуна Build . Весь двигун був відкритий і перенесений на сучасні платформи, хоча старий все ще працює бездоганно на Windows 10 (перевірено на вас: P). Багато ігор, заснованих на Build, також були відкриті та / або перероблені.

Чому це більше не використовується? Що ж, деякі двигуни більше не віддають перевагу порталам, наприклад. Застосовувати безліч графічних хакків та оптимізацій непросто - я не можу вказати вам на що-небудь конкретне, але багато постільної обробки залежить від хаків, які не працюватимуть у справжньому механізмі порталу (вони роблять багато припущень, що більше не тримати). Це в основному той самий вигляд, який мають ці ігри зі стереоскопічними зображеннями - хаки вже не працюють.

Найголовніше, що дзеркала стали складнішими. Вони можуть мати складні форми, текстури, вони можуть бути на землі (також відомі як "вода") тощо. Хоча всі ці проблеми вирішуються в портальному двигуні, RTT стає простішим вибором в якийсь момент, а графічні процесори досить швидкі. впоратися з цим.

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

RTT був би використаний, якби це було можливо, але трубопровідний конвеєр був одним із способів.

Старі апаратні засоби також мали обмеження, які перешкоджали візуалізації текстури. Запис в оперативну пам’ять означає, що її не можна читати одночасно. Для покращення продуктивності візуалізації буфер призначення був заблокований лише для запису, з нього могло читати лише апаратне забезпечення дисплея. Ви можете подати запит на читання, але це заблокувало оперативну пам’ять, і рендер повинен був дочекатися, коли замок очиститься, перш ніж він може запустити наступний кадр. RTT спричинив би велике вузьке місце для трубопроводу, і тому були використані інші рішення.

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

Герцог Нукем вирішує, що, переказуючи геометрію за дзеркалом, інші відповіді частково вірні. За дзеркалами є ділянки, які насправді не містять геометрії (у файлах даних про ігри), геометрія відтворюється під час фактичного запуску, причина цих областей - уникати випадкового розміщення шматочка рівня під час редагування рівня :

оскільки там позначена область, ви випадково не помістите геометрії.