Чи можливі відкладені візуалізація / затінення за допомогою OpenGL ES 2.0?

Я запитав це в StackOverflow , але це може мати більше сенсу тут:

Хтось реалізував відкладене відображення / затінення під OpenGL ES 2.0? Він не підтримує MRT, тому лише з одним кольоровим буфером це не те, що можна реалізувати "звичайним" способом.

Зокрема, я досліджую iPad, iPhone4 (maaaybe iPhone 3gs) та Android. У додатку GLESView на iPad / iPhone4 / iPhone3gs присутнє розширення GL_OES_RGB8_RGBA8, і я ще не надто глибоко дивився, але з 8 біт / канал ця ідея цікава: http://www.gamedev.net/topic/ 562138-opengl-es-20-і-відкладене-затінення /

Будь-які інші ідеї? Це навіть варто робити, враховуючи продуктивність?

Так, можливо. Однак це не особливо варто.

По-перше, якщо ви не маєте доступу до розширення NV_draw_buffers (як випливає з назви, це лише NVIDIA. Отже, якщо ви не працюєте на Tegra, у вас її немає) об'єкти framebuffer під ES 2.0 можуть відображати лише одне зображення зараз. Отже, щоб генерувати ваші G-буфери, вам потрібно буде відображати свою сцену кілька разів, тим самим позбавляючи одне з переваг відкладеної візуалізації.

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

По-третє, апаратне забезпечення PowerVR насправді не призначене для подібних речей. Він оптимізує візуалізацію за допомогою обладнання для візуалізації на основі плиток. Тож відкладене відображення поверх цього було б менш корисним, ніж у традиційній архітектурі сканування-перетворення.

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

На iPhone 4 та iPad 1, наповнювач просто смішний. Єдиний пристрій IOS з хорошою заливкою - це iPad 2, але я сумніваюся, що його вистачає ... На андроїд, лише пристрої Tegra мають GL_NV_draw_buffers для використання MRT, але і рівень заповнення дуже низький. Малі 400, схоже, мають найкращий фултрат. Якщо ви хочете плакати, просто спробуйте заповнити кольоровий прямокутник з роздільною здатністю на повноекранному екрані 4 рази ... Багато пристроїв не можуть це зробити 60 кадрів в секунду.

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

У WebGL є кілька прикладів (той же API), що не є обмеженням API.

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

Я б перейшов до наступного формату GBuffer:

• Повторно використовуйте буфер глибини для проходу освітлення, не впевнений, наскільки широко це підтримується на мобільних пристроях, але це вільна текстура глибини.
• Єдину текстуру GBuffer, усередині неї я б зберігав: Normal U, Normal V, Param 0, Param 1. Кодування Ламберта-Азимуталу виглядає дуже нормально для нормалей і стискає їх лише на два компоненти, відносно дешеві для кодування та декодування.
• Двох параметрів для змінних освітлення дуже багато, вони можуть використовувати один як перерахунок для декількох функцій освітлення, якщо апаратне забезпечення добре поєднується з динамічним розгалуженням.

Відкладене освітлення подібне до відкладеної візуалізації, за винятком того, що ви показуєте сцену двічі:

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

Про збереження результатів освітлення. Мені подобалося зберігати розсіяне забарвлення та дзеркальну яскравість, так що буфер накопичення повинен мати лише стандартну 32-бітну кольорову текстуру. Ви можете оцінити окулярний колір, обчисливши кольоровість розсіяного кольору та поєднуючи його із дзеркальною яскравістю.

Однак найважливішою частиною буде використання буфера глибокого трафарету якнайповніше, переконайтесь, що ви не надаєте жодного освітлювального коду там, де він не потрібен. Я б навіть пішов так далеко, щоб додати деякі твердження про відкидання у фрагменти шейдерів за умовами, які знижують видимість світла нижче діапазону відображення пристрою (1e-3, як правило, є безпечним відсіченням).

Розглянемо відкладене освітлення. Коротше кажучи, відкладене освітлення - це техніка, яка використовує зменшену версію відкладеного затінення для обчислення світлової карти екрана. У другому проході геометрія відображається знову, використовуючи світлу карту екрану як інформацію про освітлення.

Ця методика застосовується для зменшення розміру буфера G, оскільки потрібно менше атрибутів. Це також купує вам перевагу в тому, що буфер G-буфера та світлова карта екрану можуть мати меншу роздільну здатність, ніж екран.

Я реалізував суворий рендерінг на основі GLES 2.0 (хоча і експериментальний), і мені вдалося звести G-буфер до однієї текстури RGBA (так, я використав text2D замість рендербуфера). Він містив звичайну карту простору екрану + буфер глибини в альфа-каналі (наскільки я пам’ятаю стиснутий за допомогою логарифму).

Атрибути позиції ( тут називається світ ) можна обчислити під час проходження освітлення, використовуючи той факт, що в перспективній проекції .xy розбивається на .z , так що:

Я зблизив атрибут позиції xy , зробивши:

Примітка: мені довелося зробити додаткові коригування залежно від налаштувань матриці проекції.

Також варто зазначити, що я зміг опустити компонент .z нормальних векторів, оскільки я міг реконструювати .z з .xy, оскільки нормальний вектор нормалізується так, що:

Використовуючи цю техніку, я зміг звільнити інший канал у моєму RGBA G-Buffer і застосував це для зберігання екранного екрана specular-map (або глянцю, якщо хочете).

Так, це абсолютно можливо. Частота заповнення не є такою проблемою, оскільки мобільні графічні мікросхеми розроблені для роботи з екранами з дуже високою роздільною здатністю. Насправді, відкладене відображення допомагає в цьому, тому що ваш розрахунок освітлення не залежить від складності сцени, тому перевитрата не спричиняє уповільнення. Ось моя реалізація на iPad четвертого покоління: http://www.youtube.com/watch?v=K4X1oF6b4V8

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

Мобільні графічні мікросхеми надзвичайно добре відкладають візуалізацію через те, як вони обробляють текстуру візуалізації. На відміну від відеокарт ПК, які, як правило, отримують величезне враження від продуктивності, коли ви починаєте рендерувати текстуру замість контексту вікна, мобільна графіка призначена для цього. Таким чином ви отримуєте масштабованість відкладеного рендерінгу, без початкового штрафу за продуктивність, який ви відчуваєте на настільній графічній карті.

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