Графік сцени для відкладеного рендерінга

Як навчальну вправу я написав механізм відкладеного візуалізації. Тепер я хотів би додати графік сцени до цього двигуна, але мені трохи спантеличено, як це зробити.

У звичайному (двигуні рендерінга) я просто додав би всі елементи (Усі реалізуючі IDravable та IUpdateAble) до свого графіку сцени, ніж спочатку проїжджав би поперек ширини сцени і зателефонував Draw () скрізь.

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

Ще одне інше рішення, про яке я думав, - це подорож через графік сцени як звичайний і додавання предметів до 3-х окремих списків, розділення геометрії, заклинань тіней та світла, а потім повторення цих списків для складання правильних речей, чи це краще, і чи це? розумно перенаселити 3 списки кожного кадру?

Підхід, який я використав у проекті C ++, полягає в тому, що сценарій-графік (який має просторовий індекс) заповнює "видимий" std :: вектор звернень на основі поточного фрустування перегляду. Цей видимий список керується графіком сцени, тому він перераховується лише тоді, коли камера рухається - переміщуються об’єкти в графіку переміщуються в цей список та використовуються надгробні камені та несортовані списки змін, які впорядковуються та об’єднуються за необхідністю.

Список видимих ​​елементів сортується спочатку за шейдером-ідентифікатором та в межах кожного типу за відстанню від камери. Ідентифікатори шейдера призначаються таким чином, що місцевість спочатку сортує будівлі, а потім будівлі, потім одиниці, потім снаряди, потім частинки тощо - це RTS. Деякі моделі мають більше одного шейдера, але вони рекламують лише їх основний шейдер. Коли їх просять намалювати, ті, для яких потрібні біти, намальовані іншим шейдером, теж додають себе до єдиного пов'язаного списку наступного проходу.

Таким чином, малювання проходить через видимий масив за один прохід, і при цьому передається зв'язаний список тих елементів, які потрібно переглянути, і вони отримують другий прохід тощо.

Малюнок спереду та назад непрозорий, а потім прозорий допомагає зберегти все здоровим.

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

Я не маю уявлення про XNA та про те, наскільки це застосовано, і яку кількість створених вами матеріалів низького рівня я боюся. Найцікавіше було б дізнатися, що думають ветерани щодо такого підходу для С ++ RTSes.

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

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

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

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

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

Оскільки ваші структури даних швидко вставляють і не створюють сміття, за повторне заселення списків, як ви згадували, немає жодного штрафу.