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, водночас забезпечуючи відправну точку для нових учасників візуалізації.

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

Примітка

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

Modern low-level APIs (Vulkan/Direct3D 12/Metal) require intermediate knowledge of higher-level APIs (OpenGL/Direct3D 11) to be used effectively. Thankfully, contributors rarely need to work directly with low-level APIs. Godot's renderers are built entirely on OpenGL and RenderingDevice, which is our abstraction over Vulkan/Direct3D 12/Metal.

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

вперед+

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

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

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

Мобільний

This is a forward renderer that uses a traditional single-pass approach to lighting. Internally, it is called Forward Mobile.

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

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

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

Перша важлива зміна в мобільному рендерері полягає в тому, що мобільний рендерер не використовує формати текстур RGBA16F, які використовує настільний рендерер. Замість цього він використовує формат текстури R10G10B10A2 UNORM. Це вдвічі зменшує необхідну пропускну здатність і має додаткові покращення, оскільки мобільне обладнання часто додатково оптимізується для 32-розрядних форматів. Компроміс полягає в тому, що мобільний рендерер має обмежені можливості HDR через знижену точність і максимальні значення в даних кольору.

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

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

On desktop platforms, the use of sub-passes won't have any impact on performance. However, this rendering method can still perform better than Forward+ in simple scenes thanks to its lower complexity and lower bandwidth usage. This is especially noticeable on low-end GPUs, integrated graphics or in VR applications.

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

Сумісність

Примітка

This is the only rendering method available when using the OpenGL driver. This rendering method is not available when using Vulkan, Direct3D 12, or Metal.

This is a traditional (non-clustered) forward renderer. Internally, it is called GL Compatibility. It's intended for old GPUs that don't have Vulkan support, but still works very efficiently on newer hardware. Specifically, it is optimized for older and lower-end mobile devices. However, many optimizations carry over making it a good choice for older and lower-end desktop as well.

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

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

Given its low-end focus, this rendering method does not provide high-end rendering features (even less so compared to Mobile). Most post-processing effects are not available.

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

Упереджене рендеринг зазвичай забезпечує кращий компроміс між продуктивністю та гнучкістю, особливо коли використовується кластерний підхід до освітлення. Хоча в деяких випадках відкладене рендеринг може бути швидшим, він також менш гнучкий і вимагає використання хаків, щоб мати можливість використовувати 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 provides a native Metal driver that works on all Apple Silicon hardware (macOS ARM). Compared to using the MoltenVK translation layer, this is significantly faster, particularly in CPU-bound scenarios.

Both the Forward+ and Mobile Методи візуалізації can be used with Metal.

Основні шейдери are shared with the Vulkan renderer. Shaders are transpiled from GLSL to MSL using SPIRV-Cross.

Godot also supports Metal rendering via MoltenVK, which is used as a fallback when native Metal support is not available (e.g. on x86 macOS).

This driver is still experimental and only available in Godot 4.4 and later. See the pull request that introduced Metal support for more information.

OpenGL

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

It is possible to use OpenGL ES 3.0 directly on desktop platforms by passing the --rendering-driver opengl3_es command line argument, although this will only work on graphics drivers that feature native OpenGL ES support (such as Mesa).

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

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

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

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

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

  • Vulkan + Forward+ (optionally through MoltenVK on macOS and iOS)

  • Vulkan + Mobile (optionally through MoltenVK on macOS and iOS)

  • Direct3D 12 + вперед+

  • Direct3D 12 + Mobile

  • Metal + Forward+

  • Metal + Mobile

  • OpenGL + Compatibility (optionally through ANGLE on Windows and macOS)

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

Абстракція RenderingDevice

Примітка

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

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

This means that when writing code for modern rendering methods, you don't actually use the Vulkan, Direct3D 12, or Metal APIs directly. While this is still lower-level than an API like OpenGL, this makes working on the renderer easier, as RenderingDevice will abstract many API-specific quirks for you. The RenderingDevice presents a similar level of abstraction as WebGPU.

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

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

Metal RenderingDevice implementation:

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

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

../../../_images/rendering_architecture_diagram.webp

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

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

Хоча шейдери в проектах Godot написані з використанням спеціальної мови, натхненної GLSL, основні шейдери написані безпосередньо на GLSL.

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

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

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

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

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

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

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

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

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

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

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

Other GLSL shaders for Forward+ and Mobile rendering methods:

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

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

Примітка

The following is only applicable in the Forward+ and Mobile rendering methods, not in Compatibility. Multiple Viewports can be used to emulate this when using the Compatibility renderer, or to perform 2D resolution scaling.

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 візуалізації

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

Методи візуалізації Forward+ і Mobile ще не включають 2D-пакетування, але це планується для майбутнього випуску.

The Compatibility renderer features 2D batching to improve performance, which is especially noticeable with lots of text on screen.

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

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

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

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

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

In the Forward+ renderer, Vulkan instancing is used to group rendering of identical objects for performance. This is not as fast as static mesh merging, but it still allows instances to be culled individually.

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

Примітка

Decal rendering is currently not available in the Compatibility renderer.

The Forward+ renderer uses clustered lighting. This allows using as many lights as you want; performance largely depends on screen coverage. Shadow-less lights can be almost free if they don't occupy much space on screen.

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

The Mobile renderer uses a single-pass lighting approach, with a limitation of 8 OmniLights + 8 SpotLights affecting each Mesh resource (plus a limitation of 256 OmniLights + 256 SpotLights in the camera view). These limits are hardcoded and can't be adjusted in the project settings.

The Compatibility renderer uses a hybrid single-pass + multi-pass lighting approach. Lights without shadows are rendered in a single pass. Lights with shadows are rendered in multiple passes. This is required for performance reasons on mobile devices. As a result, performance does not scale well with many shadow-casting lights. It is recommended to only have a handful of lights with shadows in the camera frustum at a time and for those lights to be spread apart so that each object is only touched by 1 or 2 shadowed lights at a time. The maximum number of lights visible at once can be adjusted in the project settings.

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

Clustering is also used for reflection probes and decal rendering in the Forward+ renderer.

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

Both Forward+ and Mobile methods use PCF to filter shadow maps and create a soft penumbra. Instead of using a fixed PCF pattern, these methods use a vogel disk pattern which allows for changing the number of samples and smoothly changing the quality.

Godot also supports percentage-closer soft shadows (PCSS) for more realistic shadow penumbra rendering. PCSS shadows are limited to the Forward+ renderer as they're too demanding to be usable in the Mobile renderer. PCSS also uses a vogel-disk shaped kernel.

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

The Compatibility renderer supports shadow mapping for DirectionalLight3D, OmniLight3D, and SpotLight3D lights.

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

Примітка

Only available in the Forward+ renderer, not the Mobile or Compatibility renderers.

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

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

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

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

Вирішення TAA:

FSR 2.2:

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

Примітка

VoxelGI and SDFGI are only available in the Forward+ renderer, not the Mobile or Compatibility renderers.

LightmapGI baking is only available in the Forward+ and Mobile renderers, and can only be performed within the editor (not in an exported project). LightmapGI rendering is supported by the Compatibility renderer.

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

Lightmap baking happens on the GPU using Vulkan compute shaders. The GPU-based lightmapper is implemented in the LightmapperRD class, which inherits from the Lightmapper class. This allows for implementing additional lightmappers, paving the way for a future port of the CPU-based lightmapper present in Godot 3.x. This would allow baking lightmaps while using the Compatibility renderer.

Core GI C++ code:

Шейдери Core GI GLSL:

Код Lightmapper C++:

Шейдери Lightmapper GLSL:

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

Примітка

Only available in the Forward+ and Mobile renderers, not the Compatibility renderer.

The Forward+ and Mobile renderers use different approaches to DOF rendering, with different visual results. This is done to best match the performance characteristics of the target hardware. In Forward+, DOF is performed using a compute shader. In Mobile, DOF is performed using a fragment shader (raster).

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

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

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

Depth of field GLSL shader (raster - used for Mobile):

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

Примітка

Only available in the Forward+ renderer, not the Mobile or Compatibility renderers.

The Forward+ renderer supports screen-space ambient occlusion, screen-space indirect lighting, screen-space reflections and subsurface scattering.

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

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

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

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

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

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

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

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

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

Дивись також

Шейдери неба

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

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

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

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

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

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

Примітка

Only available in the Forward+ renderer, not the Mobile or Compatibility renderers.

Дивись також

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

Годо підтримує воксельний (фроксельний) підхід до відтворення об’ємного туману. На відміну від фільтра постобробки, цей підхід є більш універсальним, оскільки він може працювати з будь-яким типом світла. 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 об’ємного туману:

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

While modern GPUs can handle drawing a lot of triangles, the number of draw calls in complex scenes can still be a bottleneck (even with Vulkan, Direct3D 12, and 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.

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

Godot's occlusion culling doesn't support dynamic occluders yet, but OccluderInstance3D nodes can still have their visibility toggled or be moved. However, this will be slow when updating complex occluders this way. Therefore, updating occluders at runtime is best done only on simple occluder shapes such as quads or cuboids.

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

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

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

  • Працює однаково з усіма драйверами та методами візуалізації, без непередбачуваної поведінки залежно від драйвера чи обладнання 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 сітки: