Attention: Here be dragons

This is the latest (unstable) version of this documentation, which may document features not available in or compatible with released stable versions of Godot.

Checking the stable version of the documentation...

Внутрішня архітектура візуалізації

Ця сторінка є оглядом високого рівня внутрішнього дизайну рендерера Godot 4. Це не стосується попередніх версій Godot.

Метою цієї сторінки є документування рішень щодо дизайну, прийнятих з метою найкращого відповідності філософії дизайну Godot <https://contributing.godotengine.org/en/latest/engine/guidelines/best_practices.html>__, а також надання відправної точки для нових учасників процесу рендерингу.

Якщо у вас є запитання щодо внутрішніх елементів відтворення, на які тут немає відповіді, не соромтеся запитати на каналі #rendering чату співавторів Godot <https://chat.godotengine.org/channel/rendering>`__.

Примітка

Якщо у вас виникли труднощі з розумінням понять на цій сторінці, рекомендуємо ознайомитися з посібником з OpenGL, наприклад LearnOpenGL.

Для ефективного використання сучасних низькорівневих API (Vulkan/Direct3D 12/Metal) потрібні проміжні знання API вищого рівня (OpenGL/Direct3D 11). На щастя, авторам рідко доводиться працювати безпосередньо з низькорівневими API. Рендерери Godot повністю побудовані на OpenGL і RenderingDevice, що є нашою абстракцією над Vulkan/Direct3D 12/Metal.

Методи візуалізації

вперед+

Це прямий рендерер, який використовує кластерний підхід до освітлення.

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

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

Мобільний

Це передовий візуалізатор, який використовує традиційний однопрохідний підхід до освітлення. Внутрішньо це називається Forward Mobile.

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

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

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

The first important change in the mobile renderer is that the mobile renderer does not use the RGBA16F texture formats that the desktop (Forward+) renderer does. Instead, it uses an R10G10B10A2 UNORM texture format unless the rendering/viewport/hdr_2d project setting is enabled. This halves the bandwidth required and has further improvements, as mobile hardware often further optimizes for 32-bit formats. The tradeoff is that by default, the mobile renderer has limited HDR capabilities due to the reduced precision and maximum values in the color data.

When the rendering/viewport/hdr_2d project setting is enabled, the mobile renderer uses the same RGBA16F renderers as Forward+. This allows for full HDR support, but also increases bandwidth usage and can reduce performance on mobile GPUs or integrated graphics.

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

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

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

Враховуючи низький рівень фокусування, цей метод візуалізації не забезпечує високоякісних функцій рендерингу, таких як SDFGI та Об'ємний туман і об'єми туману. Деякі ефекти постобробки також недоступні.

Сумісність

Примітка

Це єдиний доступний метод візуалізації під час використання драйвера OpenGL. Цей метод візуалізації недоступний під час використання Vulkan, Direct3D 12 або Metal.

Це традиційний (некластеризований) прямий рендерер. Всередині це називається GL Compatibility. Він призначений для старих графічних процесорів, які не підтримують Vulkan, але все ще дуже ефективно працюють на новішому обладнанні. Зокрема, він оптимізований для старих і недорогих мобільних пристроїв. Однак багато оптимізацій переносяться, що робить його хорошим вибором також для старих і нижчих комп’ютерів.

Як і мобільний рендерер, засіб сумісності використовує текстуру R10G10B10A2 UNORM для 3D-рендерінгу. На відміну від мобільного рендерера, кольори розподіляються за тонами та зберігаються у форматі sRGB, тому немає підтримки HDR. Це дозволяє уникнути необхідності проходження тонального відображення та дозволяє нам використовувати нижню бітову текстуру без істотних смуг.

Засіб візуалізації сумісності використовує традиційний однопрохідний підхід для малювання об’єктів зі світлом, але використовує багатопрохідний підхід для малювання світла з тінями. Зокрема, під час першого проходу він може малювати кілька джерел світла без тіней і до одного DirectionalLight3D з тінями. У кожному наступному проході він може малювати до одного OmniLight3D, одного SpotLight3D і одного DirectionalLight3D з тінями. Світло з тінями впливатиме на сцену інакше, ніж світло без тіней, оскільки освітлення змішується в просторі sRGB замість лінійного простору. Ця різниця в освітленні вплине на те, як виглядає сцена, і про це потрібно пам’ятати під час розробки сцен для рендерера сумісності.

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

Чому б не відкласти рендеринг?

Упереджене рендеринг зазвичай забезпечує кращий компроміс між продуктивністю та гнучкістю, особливо коли використовується кластерний підхід до освітлення. Хоча в деяких випадках відкладене рендеринг може бути швидшим, він також менш гнучкий і вимагає використання хаків, щоб мати можливість використовувати MSAA. Оскільки ігри з менш реалістичним художнім стилем можуть отримати значну користь від MSAA, ми вирішили скористатися прямим рендерингом для Godot 4 (як Godot 3).

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

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

Драйвери рендеринга

Godot 4 підтримує такі графічні API:

Vulkan

Це основний драйвер у Godot 4, на якому зосереджено більшу увагу на розвитку.

Vulkan 1.0 потрібен як базовий, з додатковими функціями Vulkan 1.1 і 1.2, які використовуються, якщо вони доступні. volk використовується як завантажувач Vulkan, а Vulkan Memory Allocator використовується для пам’яті управління.

Під час використання драйвера Vulkan підтримуються як Forward+, так і Mobile Методи візуалізації.

Створення контексту Vulkan:

Створення контексту Direct3D 12:

Direct3D 12

Як і Vulkan, драйвер Direct3D 12 призначений лише для сучасних платформ. Його розроблено для Windows і Xbox (тоді як Vulkan не можна використовувати безпосередньо на Xbox).

І Forward+, і Mobile Методи візуалізації можна використовувати з Direct3D 12.

Основні шейдери спільно з рендерером Vulkan. Шейдери транспільовано з SPIR-V до DXIL за допомогою Mesa NIR (додаткова інформація).

Цей драйвер все ще експериментальний і доступний лише в Godot 4.3 і пізніших версіях. Хоча Direct3D 12 дозволяє підтримувати ексклюзивні функції Direct3D у Windows 11, такі як віконна оптимізація та Auto HDR, Vulkan все ще рекомендується для більшості проектів. Для отримання додаткової інформації перегляньте запит на витягування, який представив підтримку Direct3D 12.

Metal

Godot надає рідний драйвер Metal, який працює на всьому обладнанні Apple Silicon (macOS ARM). Порівняно з використанням рівня перекладу MoltenVK це значно швидше, особливо в сценаріях, пов’язаних із процесором.

І Forward+, і Mobile Методи візуалізації можна використовувати з Metal.

Основні шейдери спільно з рендерером Vulkan. Шейдери транспільовані з GLSL на MSL за допомогою SPIRV-Cross.

Godot також підтримує рендеринг Metal через MoltenVK, який використовується як запасний варіант, коли рідна підтримка Metal недоступна (наприклад, на x86 macOS).

Since Godot 4.7, Metal 4 is now used when supported. All Apple Silicon hardware supports Metal 4, but it must be running macOS 26 or later, or iOS 26 or later. Metal 3 is automatically used as a fallback on older macOS and iOS versions. See the pull request that introduced Metal 4 support for more information.

OpenGL

Цей драйвер використовує OpenGL ES 3.0 і призначений для застарілих і недорогих пристроїв, які не підтримують Vulkan. OpenGL 3.3 Core Profile використовується на настільних платформах для запуску цього драйвера, оскільки більшість графічних драйверів на настільних комп’ютерах не підтримують OpenGL ES. Для веб-експорту використовується WebGL 2.0.

Можна використовувати OpenGL ES 3.0 безпосередньо на настільних платформах, передавши аргумент командного рядка --rendering-driver opengl3_es, хоча це працюватиме лише з графічними драйверами, які мають власну підтримку OpenGL ES (наприклад, Mesa).

З драйвером OpenGL можна використовувати лише метод відтворення Сумісність.

Основні шейдери повністю відрізняються від рендерера Vulkan.

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

Короткий опис драйверів/методів візуалізації

Наразі можливі такі комбінації API відтворення + метод відтворення:

  • Vulkan + Forward+ (необов’язково через MoltenVK на macOS та iOS)

  • Vulkan + Mobile (необов’язково через MoltenVK на macOS та iOS)

  • Direct3D 12 + вперед+

  • Direct3D 12 + Мобільний

  • Метал + Вперед+

  • Метал + Мобільний

  • Сумісність з OpenGL + (опціонально через ANGLE у Windows і macOS)

Кожна комбінація має свої обмеження та характеристики продуктивності. Обов’язково перевірте свої зміни на всіх методах рендерингу, якщо це можливо, перш ніж відкривати запит на отримання.

Абстракція RenderingDevice

Примітка

Драйвер OpenGL не використовує абстракцію RenderingDevice.

Щоб зробити складність сучасних низькорівневих графічних API більш керованою, Godot використовує власну абстракцію під назвою RenderingDevice.

Це означає, що під час написання коду для сучасних методів візуалізації ви фактично не використовуєте напряму API Vulkan, Direct3D 12 або Metal. Хоча це все ще нижчий рівень, ніж API, як-от OpenGL, це полегшує роботу над рендерером, оскільки RenderingDevice абстрагує для вас багато особливостей API. RenderingDevice представляє подібний рівень абстракції, як WebGPU.

Реалізація Vulkan RenderingDevice:

Реалізація Direct3D 12 RenderingDevice:

Реалізація Metal RenderingDevice:

Основна архітектура класів візуалізації

Ця діаграма представляє структуру класів візуалізації в Godot, включаючи абстракцію RenderingDevice:

../../_images/rendering_architecture_diagram.webp

Переглянути в повному розмірі

Основні шейдери

Хоча шейдери в проектах Godot написані з використанням custom language inspired by GLSL, основні шейдери написані безпосередньо на GLSL.

Ці основні шейдери вбудовані в редактор і експортують двійкові файли шаблону під час компіляції. Щоб побачити будь-які зміни, внесені в ці шейдери GLSL, потрібно перекомпілювати редактор або експортувати двійковий файл шаблону.

Деякі функції матеріалу, такі як відображення висоти, заломлення та зникнення наближення, не є частиною основних шейдерів і виконуються в базовому матеріалі за замовчуванням BaseMaterial3D з використанням мови шейдерів Godot (не GLSL). Це робиться шляхом процедурної генерації необхідного коду шейдера залежно від функцій, увімкнених у матеріалі.

За угода файли шейдерів із _inc у назві включаються до інших файлів GLSL для кращого повторного використання коду. Для цього використовується стандартна попередня обробка GLSL.

Попередження

Шейдери основного матеріалу використовуватимуться для кожного матеріалу в сцені – як із стандартним BaseMaterial3D, так і з власними шейдерами. Як наслідок, ці шейдери мають бути максимально простими, щоб уникнути проблем із продуктивністю та гарантувати, що компіляція шейдерів не стане надто повільною.

Якщо ви використовуєте розгалуження if у шейдері, продуктивність може знизитися, оскільки використання VGPR у шейдері збільшиться. Це трапляється, навіть якщо всі пікселі оцінюються як true або false у даному кадрі.

Якщо ви використовуєте розгалуження препроцесора #if, кількість необхідних версій шейдерів збільшиться в сцені. У гіршому випадку додавання єдиного логічного значення #define може подвоїти кількість версій шейдерів, які, можливо, потрібно буде скомпілювати в певній сцені. У деяких випадках константи спеціалізації Vulkan можна використовувати як швидшу (але більш обмежену) альтернативу.

Це означає, що є високий бар’єр для додавання нових вбудованих функцій матеріалу в Godot, як у основних шейдерах, так і в BaseMaterial3D. Хоча BaseMaterial3D може використовувати генерацію динамічного коду, щоб включати лише код шейдера, якщо цю функцію ввімкнено, він все одно потребуватиме створення додаткових версій шейдерів, коли ці функції використовуються в проекті. Це може зробити заїкання компіляції шейдерів більш помітними у складних 3D-сценах.

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

Основні шейдери матеріалу GLSL:

Генерація матеріальних шейдерів:

Інші шейдери GLSL для методів візуалізації Forward+ і Mobile:

Інші шейдери GLSL для методу візуалізації сумісності:

Поділ візуалізації 2D і 3D

Примітка

Нижче наведено лише методи візуалізації Forward+ і Mobile, а не сумісність. Кілька вікон перегляду можна використовувати для емуляції під час використання рендерера сумісності або для виконання масштабування роздільної здатності 2D.

2D і 3D відтворюються в окремих буферах, оскільки 2D-рендеринг у Godot виконується в LDR sRGB-просторі, тоді як 3D-рендеринг використовує HDR лінійний простір.

Формат кольору, який використовується для 2D-візуалізації, – RGB8 (RGBA8, якщо властивість Прозорий у вікні перегляду ввімкнено). 3D-візуалізація використовує 24-бітний беззнаковий нормалізований цілочисельний буфер глибини або 32-бітовий знаковий буфер із плаваючою комою, якщо 24-бітний буфер глибини не підтримується апаратним забезпеченням. 2D-візуалізація не використовує буфер глибини.

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

Функція configure() у RenderSceneBuffersRD перерозподіляє 2D/3D буфери, коли змінюється роздільна здатність або масштабування.

Динамічне масштабування роздільної здатності ще не підтримується, але планується в майбутньому випуску Godot.

Код C++ конфігурації буфера 2D і 3D візуалізації:

FSR 1.0:

Техніка 2D візуалізації

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

Усі методи рендерингу використовують 2D-пакетування для покращення продуктивності, що особливо помітно при великій кількості тексту на екрані.

MSAA можна ввімкнути в 2D, щоб забезпечити «автоматичне» згладжування ліній і багатокутників, але FXAA не впливає на 2D-рендерінг, оскільки він обчислюється перед початком 2D-рендерінгу. Методи двовимірного малювання Godot, такі як вузол Line2D або деякі методи draw_*() CanvasItem, забезпечують власний спосіб згладжування на основі смуг трикутників і кольорів вершин, для роботи яких не потрібен MSAA.

Двовимірне поле відстані зі знаком, що представляє вузли LightOccluder2D у вікні перегляду, автоматично генерується, якщо це запитує шейдер користувача. Це можна використовувати для різних ефектів у користувацьких шейдерах, таких як 2D глобальне освітлення. Він також використовується для розрахунку зіткнень частинок у 2D.

Шейдер GLSL покоління 2D SDF:

Техніка 3D візуалізації

Reverse Z

All of Godot's renderers use reverse Z. This means that the depth buffer is inverted, with 1.0 representing the near plane and 0.0 representing the far plane. This allows for better precision, especially at long distances.

Пакетування та інстансування

У рендерері Forward+ використовується інстансування Vulkan для групування рендерингу ідентичних непрозорих або альфа-тестованих об'єктів для підвищення продуктивності. (Об'єкти, що змішані з альфа-стеженням, ніколи не інстансуються). Це не так швидко, як статичне злиття сіток, але все ж дозволяє вибирати екземпляри окремо.

Візуалізація світла, наклейок і відбиття зондів

Примітка

Візуалізація наклейок наразі недоступна в засобі візуалізації сумісності.

Рендерер Forward+ використовує кластерне освітлення. Це дозволяє використовувати скільки завгодно світильників; продуктивність значною мірою залежить від покриття екрана. Світло без тіні може бути майже безкоштовним, якщо воно не займає багато місця на екрані.

Усі методи візуалізації також підтримують візуалізацію до 8 спрямованих джерел світла одночасно (хоча з нижчою якістю тіней, якщо ввімкнено тіні для кількох джерел світла).

Мобільний рендерер використовує однопрохідний підхід до освітлення з обмеженням 8 OmniLights + 8 SpotLights, що впливають на кожен ресурс Mesh (плюс обмеження 256 OmniLights + 256 SpotLights у поданні камери). Ці обмеження жорстко закодовані, і їх не можна змінити в налаштуваннях проекту.

Інструмент візуалізації сумісності використовує гібридний однопрохідний і багатопрохідний підхід освітлення. Світла без тіней відтворюються за один прохід. Світло з тінями відтворюється за кілька проходів. Це потрібно для продуктивності мобільних пристроїв. У результаті продуктивність погано масштабується з великою кількістю світла, що відкидає тінь. Рекомендується одночасно мати лише декілька джерел світла з тінями в зоні зрізу камери, і щоб ці світла були розподілені так, щоб кожного об’єкта торкався лише 1 або 2 затемнених світла одночасно. Максимальну кількість вогнів, які видно одночасно, можна налаштувати в налаштуваннях проекту.

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

Кластеризація також використовується для зондів відображення та візуалізації декалей у рендерері Forward+.

Area lights make use of the Linearly Transformed Cosines technique.

Відображення тіней

Методи Forward+ і Mobile використовують PCF для фільтрації карт тіней і створення м’якої півтіні. Замість використання фіксованого шаблону PCF ці методи використовують шаблон диска Фогеля, який дозволяє змінювати кількість зразків і плавно змінювати якість.

Godot також підтримує м’які тіні (PCSS) для більш реалістичного відтворення тіні півтіні. Тіні PCSS обмежені рендерером Forward+, оскільки вони надто вимогливі, щоб використовувати їх у мобільному рендерері. PCSS також використовує ядро у формі диска Фогеля.

Крім того, обидва методи відображення тіней обертають ядро на основі кожного пікселя, щоб допомогти пом’якшити артефакти недостатньої вибірки.

Засіб візуалізації сумісності підтримує відображення тіней для світильників DirectionalLight3D, OmniLight3D і SpotLight3D.

Тимчасове згладжування

Примітка

Доступно лише у засобах візуалізації Forward+, а не для мобільних і сумісних рендерів.

Godot використовує спеціальну реалізацію TAA на основі старої реалізації TAA від Spartan Engine.

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

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

Крім того, FSR 2.2 можна використовувати як рішення масштабування, яке також надає власний алгоритм тимчасового згладжування. FSR 2.2 реалізовано на основі абстракції RenderingDevice на відміну від безпосереднього використання довідкового коду AMD.

Вирішення TAA:

FSR 2.2:

Глобальне освітлення

Примітка

VoxelGI та SDFGI доступні лише у засобах візуалізації Forward+, а не для мобільних і сумісних рендерів.

Запікання LightmapGI доступне лише в програмах візуалізації Forward+ і Mobile і може виконуватися лише в редакторі (не в експортованому проекті). Рендеринг LightmapGI підтримується рендерером сумісності.

Godot підтримує GI на основі вокселів (VoxelGI), знакове поле відстані GI (SDFGI) і запікання та візуалізацію карт освітлення (LightmapGI). При бажанні ці техніки можна використовувати одночасно.

Запікання карт освітлення відбувається на GPU за допомогою обчислювальних шейдерів Vulkan. Lightmapper на основі GPU реалізовано в класі LightmapperRD, який успадковує клас Lightmapper. Це дозволяє впроваджувати додаткові світлові картографи, прокладаючи шлях для майбутнього порту світлового картографа на основі ЦП, наявного в Godot 3.x. Це дозволить запікати карти освітлення під час використання рендерера сумісності.

Core GI C++ code:

Шейдери Core GI GLSL:

Код Lightmapper C++:

Шейдери Lightmapper GLSL:

Глибина різкості

Примітка

Доступно лише в програмах візуалізації Forward+ і Mobile, але не в системі візуалізації Compatibility.

Рендерери Forward+ і Mobile використовують різні підходи до рендерингу DOF із різними візуальними результатами. Це робиться для найкращої відповідності характеристикам продуктивності цільового обладнання. У Forward+ DOF виконується за допомогою обчислювального шейдера. У Mobile DOF виконується за допомогою фрагментного шейдера (растру).

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

Глибина поля коду C++:

Глибина різкості шейдера GLSL (обчислення — використовується для Forward+):

Глибина різкості шейдера GLSL (растровий — використовується для мобільних пристроїв):

Ефекти екранного простору (SSAO, SSIL, SSR, SSS)

Примітка

Доступно лише у засобах візуалізації Forward+, а не для мобільних і сумісних рендерів.

Рендерер Forward+ підтримує оклюзію екранного простору, непряме освітлення екранного простору, відображення екранного простору та підповерхневе розсіювання.

SSAO використовує реалізацію, похідну від Intel ASSAO (конвертовано до Вулкану). SSIL походить від SSAO для забезпечення високоефективного непрямого освітлення.

Якщо ввімкнено SSAO та SSIL, частини SSAO та SSIL використовуються спільно, щоб зменшити вплив на продуктивність.

SSAO, SSIL та SSR за замовчуванням виконуються з половинною роздільною здатністю для покращення продуктивності.

SSR makes use of a Hi-Z buffer to improve performance. This Hi-Z buffer is generated from the depth buffer in a compute shader. See the pull request that overhauled SSR for more information.

Ефекти екранного простору C++ код:

Екранно-просторова оклюзія навколишнього середовища GLSL-шейдер:

Тейдер GLSL непрямого освітлення екранного простору:

Відображення екранного простору GLSL шейдер:

Поверхневе розсіювання GLSL:

Візуалізація неба

Дивись також

Шейдери неба

Godot підтримує використання шейдерів для візуалізації фону неба. Карта яскравості (яка використовується для забезпечення навколишнього освітлення та відображень для матеріалів PBR) автоматично оновлюється на основі шейдера неба.

Ресурси SkyMaterial, такі як ProceduralSkyMaterial, PhysicalSkyMaterial і PanoramaSkyMaterial, створюють вбудований шейдер для візуалізації неба. Це схоже на те, що BaseMaterial3D надає для матеріалів 3D-сцени.

Детальну технічну реалізацію можна знайти в статті Власні шейдери неба в Godot 4.0.

Відтворення Sky коду C++:

Шейдер GLSL рендеринга неба:

Об'ємний туман

Примітка

Доступно лише у засобах візуалізації Forward+, а не для мобільних і сумісних рендерів.

Дивись також

Туманні шейдери

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

Ресурс FogMaterial створює вбудований шейдер для вузлів FogVolume. Це схоже на те, що BaseMaterial3D надає для матеріалів 3D-сцени.

Детальне технічне пояснення можна знайти в статті «Fog Volumes arrive in Godot 4.0 <https://godotengine.org/article/fog-volumes-arrive-in-godot-4>`__.

Код C++ об’ємного туману:

Шейдери GLSL об’ємного туману:

Вибракування оклюзії

Хоча сучасні графічні процесори можуть впоратися з малюванням багатьох трикутників, кількість викликів малювання в складних сценах все ще може бути вузьким місцем (навіть із Vulkan, Direct3D 12 і Metal).

Godot 4 supports occlusion culling to reduce overdraw (when the depth prepass is disabled) and reduce vertex throughput. This is done by rasterizing a low-resolution buffer on the CPU using Embree. The buffer's resolution depends on the number of CPU threads on the system, as this is done in parallel. This buffer includes occluder shapes that were baked in the editor or created at runtime. The occlusion culling buffer is jittered by a small amount every frame to help reduce under-sampling artifacts, which would lead to false positives (objects getting occluded when they shouldn't be).

Оскільки складні оклюдери можуть створювати велике навантаження на ЦП, запечені оклюдери можна автоматично спрощувати під час створення в редакторі.

Відбракування оклюзії Godot ще не підтримує динамічні оклюдери, але вузли OccluderInstance3D все ще можуть змінювати видимість або переміщуватися. Однак під час оновлення складних оклюдерів таким чином це буде повільно. Таким чином, оновлення оклюдерів під час виконання найкраще виконувати лише на простих формах оклюдерів, таких як чотирикутники або кубоїди.

Цей підхід на основі центрального процесора має кілька переваг перед іншими рішеннями, такими як портали та кімнати або рішення відсіву на основі графічного процесора:

  • Ручне налаштування не потрібне (але можна налаштувати вручну для найкращої продуктивності).

  • Немає затримки кадру, яка є проблематичною в кат-сценах під час перерізів камери або коли камера швидко рухається за стіною.

  • Працює однаково з усіма драйверами та методами візуалізації, без непередбачуваної поведінки залежно від драйвера чи обладнання GPU.

Відбір оклюзії виконується шляхом реєстрації сіток оклюдера, що виконується за допомогою вузлів OccluderInstance3D (які самі використовують ресурси Occluder3D). Потім RenderingServer виконує відбір оклюзії, викликаючи Embree у RendererSceneOcclusionCull.

Код C++ для вибракування оклюзії:

Дальність видимості (LOD

Godot підтримує створений вручну ієрархічний рівень деталізації (HLOD) із відстанями, визначеними користувачем в інспекторі.

У RenderingSceneCull функції _scene_cull() і _render_scene() є місцем, де відбувається більшість визначення LOD. Кожне вікно перегляду може відтворювати ту саму сітку з різними LOD (щоб рендеринг розділеного екрана виглядав правильно).

Код C++ діапазону видимості:

Автоматична сітка LOD

Клас ImporterMesh використовується для робочого процесу імпорту 3D-сітки в редакторі. Його функція generate_lods() обробляє генерацію за допомогою бібліотеки meshoptimizer.

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

Функція _render_scene() класу RenderingSceneCull визначає, який LOD сітки слід використовувати під час візуалізації. Кожне вікно перегляду може відтворювати ту саму сітку з різними LOD (щоб дозволити розділення рендеринг екрана, щоб він виглядав правильно).

LOD сітки вибирається автоматично на основі метрики покриття екрана. Це враховує роздільну здатність і зміни кута огляду камери без втручання користувача. Пороговий множник можна налаштувати в налаштуваннях проекту.

Щоб підвищити продуктивність, візуалізація тіні та рендеринг зонда відображення також вибирають власні порогові значення LOD сітки (які можуть відрізнятися від рендерингу основної сцени).

Генерація сітки LOD при імпорті коду C++:

Код C++ визначення LOD сітки: