Відкладене затінення - це лише техніка "відстрочення" фактичної операції затінення на наступні етапи, це може бути чудово, щоб зменшити кількість проходів, необхідних (наприклад), щоб зробити 10 вогнів, для чого потрібно 10 проходів. Моя думка, незалежно від використовуваної методики візуалізації, є певні можливі оптимізації візуалізації, які зменшують кількість об'єктів (вершин, нормалей тощо), які потрібно обробляти вашим конвеєром візуалізації.
Існує не фактичний стандарт для оптимізації візуалізації, а скоріше цілий ряд методів, які можна використовувати взаємозамінно або спільно для досягнення певних характеристик продуктивності. Використання кожної техніки сильно залежить від характеру сцени, що відображається.
Відкладене відображення намагається вирішити проблему, коли кількість вогнів збільшується, що при подачі вперед може змусити кількість проходів вибухнути.
Ці методи безпосередньо не оптимізують відкладену затінювальну частину, але згідно з вашим описом, відкладена затіняюча частина НЕ є вашою проблемою. Ваша проблема, однак, полягає в тому, що ви подаєте всю сцену на надання конвеєра. Тож ваш двигун повинен обробляти (наприклад, всі 100 мільйонів вершин) у вашій сцені лише для того, щоб мати змогу подати результат у g-буфер, тоді як більшість тез у 100 мільйонів вершин можна тривільно видалити, а не подати до попередньо обробляють вершину та фрагменти.
У випадку прямого рендерінга вершина N буде оброблена стадією вершини як загальна сума, vertex count*lights countа стадія фрагмента як загальна кількість fragments count*number Lights, відкладене затінення ефективно зводить це лише vertex countдо стадії вершини та fragments countдля підрахунку фрагмента, перш ніж вирішити значення фактичне затінення. Але все-таки N може бути занадто багато для обробки, особливо коли більшість з них може бути тривіально знищена.
Це робить вимкнення більш ефективним у випадку передачі вперед / декількох проходів. Але майте на увазі, що більшість двигунів використовуватиме подвійний підхід рендерінгу, оскільки відкладене затінення одне не може вирішити прозорі об'єкти, це робить використання цих оптимізацій необхідним, я не знаю жодного комерційного двигуна, який не виконує їх усіх.
Куріння плоду
Тільки об'єкти, які повністю або частково включені у перегляд фрустуму, коли-небудь потрібно подавати в конвеєр рендерінгу. Це основна концепція відсікання фрустуму, на жаль, перевірка того, чи сітка знаходиться / виходить з поля зору, фрустум може бути дорогою операцією, тому натомість дизайнери двигунів використовують приблизний обмежувальний об'єм, як (AABB) Вирівнювання обмежувальної коробки з осі або обмежувальної сфери , незважаючи на те, що це може бути не так точно, як використання фактичної сітки, різниця в точності не варто перевіряти фактичною сіткою.
Навіть з обмежуючими обсягами вам не потрібно перевіряти кожен з них, або ви можете побудувати обмежувальну ієрархію томів, щоб зробити попереднє відсікання, використовуючи це, що сильно залежить від складності сцени.
Це хороша і проста техніка для меншого двигуна і майже використовується у кожному двигуні, який я коли-небудь використовував. Рекомендую використовувати "звичайний" показник обмеження об'єму / фрустуму без ієрархій, якщо ваш двигун не потребує візуалізації дуже складних сцен.
Відкидання спини обличчя
Це обов’язково, чому малювати обличчя, які все одно не будуть видні? API рендерингу надають інтерфейс для вмикання / вимкнення зворотного відключення обличчя. Якщо у вас немає вагомих причин, чому б не ввімкнути його, як і деякі програми CAD, які потребують малювання задньої поверхні за певних обставин, це обов'язково.
Виключення прикусу
За допомогою Z-буфера ви можете вирішити визначення видимості. Але проблема полягає в тому, що Z-буфер не завжди чудовий з точки зору продуктивності, оскільки Z-буфер може бути вирішений лише на більш пізніх стадіях конвеєра, об'єкти, що закриваються, повинні бути растеризовані і можуть бути записані в Z-буфер і Кольоровий буфер перед тим, як не вдатися до тесту Z.
Відключення оклюзії вирішує це, роблячи кілька ранніх тестів на вилучення оклюзійних предметів, які перебувають у плоді візуалізації. Одне практичне здійснення відключення оклюзії - це використання точкових запитів і перевірка того, чи певні об'єкти видно з певної точки зору. Це також можна використовувати для зменшення світла, яке не сприяє остаточному зображенню. Це особливо корисно у відкладеному рендері двигуна.
Чудовий приклад такої техніки в реальному світі - в GTA5, де хмарочоси стратично розміщуються в центрі міста, є не лише прикрасою, але вони також працюють як окклюдери, ефективно забиваючи решту частини міста і не даючи їй бути растровані.
Рівень деталізації
Рівень деталізації широко застосовується технікою, ідея полягає у використанні більш простої версії сітки, коли сітка менше сприяє сцені. є дві загальні реалізації; просто перемикає сітку на більш просту, коли вона більше не сприяє, сітка вибирається виходячи з деякого коефіцієнта, наприклад, відстані та кількості пікселів (площа в осипі), яку займає сітка. Інша версія динамічно тесселює сітку, це широко використовується в рельєфі місцевості.
Що робити, якщо все це не спрацювало?
Ну, це гарне запитання.
Перше, що вам потрібно зробити - це профілювати свою програму за допомогою графічного профілера та визначити, де знаходиться вузьке місце. Майте на увазі, що вузьке місце може змінюватися в міру зміни вмісту, що надається. Вузькі пляшки також можуть бути частиною коду, що працює на процесорі, тому вам також потрібно вимірювати це.
Після цього вам потрібно зробити деякі оптимізації на вузькому місці, майте на увазі, що на це немає правильної відповіді, і він буде відрізнятися від апаратного до іншого.
Деякі поширені прийоми оптимізації GPU:
- Уникайте розгалуження в шейдерах.
- Спробуйте різні вершинні структури, наприклад
{VNT}переплетені в одному масиві або {V},{N},{T}в різних масивах.
- Намалюйте сцену спереду назад.
- Вимкніть Z-буфер в деяких точках, наприклад, якщо для зображення не потрібно тестування Z.
- Використовуйте стислі текстури.
Деякі поширені прийоми оптимізації процесора:
- Використовуйте вбудовані функції для невеликих функцій.
- Використовуйте SIMD (Єдина інструкція з декількома даними), коли це можливо.
- Уникайте кеш-стрибок недружньої пам'яті.
- Використовуйте VBO з "правильним" обсягом даних. (залежно від обладнання), але зазвичай менше дзвінків на дзвінки краще.
Але що робити, якщо моє вузьке місце було в відкладеному затіненні?
У цьому випадку, оскільки відкладене затінення більше стосується освітлення, то найбільш очевидною частиною є оптимізація фактичних розрахунків затінення. деякі моменти, на які слід стежити:
- Візуалізуйте вогні, які фактично впливають на остаточне зображення. Іншими словами, зменшіть світло, який не сприяє. Це можна ефективно реалізувати, використовуючи відмінювання оклюзії, про яке я згадував раніше.
- Чи потрібні цьому світлу окуляри чи якісь інші компоненти? Можливо ні.
- Це світло кидає тінь? Деякі світильники не повинні кидати тіні.
- Чи можна заздалегідь обчислити цей легкий внесок? Якщо він не рухається, можливо, деякі аспекти можуть бути попередньо обчислені.