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...

Оптимізація продуктивності 3D

Вибракування

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

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

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

Усе не так погано, як здається, оскільки Z-буфер зазвичай дозволяє графічному процесору повністю затінювати лише ті об’єкти, які знаходяться спереду. Це називається depth prepass і ввімкнено за замовчуванням у Godot під час використання методів візуалізації Forward+ або Compatibility. Однак непотрібні об’єкти все ще знижують продуктивність.

Один зі способів потенційно зменшити обсяг рендерингу – це скористатися перевагами оклюзії. Godot пропонує підхід до відсіювання оклюзії за допомогою вузлів-оклюдерів. Дивіться Вибракування оклюзії для отримання інструкцій щодо налаштування відсіювання оклюзії у вашій сцені.

Примітка

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

Прозорі об'єкти

Godot сортує об’єкти за Material і Shader для покращення продуктивності. Однак цього не можна зробити з прозорими об'єктами. Прозорі об’єкти візуалізуються ззаду вперед, щоб злити те, що знаходиться позаду. Тому намагайтеся використовувати якомога менше прозорих об’єктів. Якщо об’єкт має невелику ділянку з прозорістю, спробуйте зробити цю ділянку окремою поверхнею з власного матеріалу.

Додаткову інформацію див. у документі GPU optimizations.

Рівень деталізації (LOD)

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

Godot 4 пропонує кілька способів керування рівнем деталізації:

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

Діапазони видимості також є хорошим способом налаштувати імпостори для віддаленої геометрії (див. нижче).

Рекламні щити та самозванці

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

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

Ви можете створювати самозванців, попередньо відображаючи види об’єкта під різними кутами. Або ви навіть можете піти ще далі й періодично повторно візуалізувати вигляд об’єкта на текстурі, яка буде використовуватися як самозванець. На відстані потрібно відсунути глядача на значну відстань, щоб кут зору суттєво змінився. Це може бути складним завданням, але воно того варте залежно від типу проекту, який ви робите.

Використовувати автоматичне створення екземплярів

Це реалізовано лише у рендерері Forward+, а не у Mobile або Compatibility..

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

Щоб автоматичне створення екземплярів було ефективним, матеріал має бути непрозорим або протестованим на альфа-технологію (альфа-ножиці або альфа-хеш). Матеріали з альфа-змішаними або глибинними попередніми пропусками ніколи не створюються таким чином. Натомість необхідно використовувати MultiMesh, як описано нижче.

Використовувати ручне створення екземплярів (MultiMesh)

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

Дивіться також документацію Using MultiMesh.

Випічка освітлення

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

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

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

Недоліком світильників із Статичним режимом запікання є те, що вони не можуть відкидати тіні на сітку з запіканням освітлення. Це може зробити сцени з зовнішнім середовищем і динамічними об’єктами виглядати плоскими. Хороший баланс між продуктивністю та якістю полягає в тому, щоб зберегти Dynamic для вузла DirectionalLight3D і використовувати Static для більшості (якщо не всіх) універсальних і точкових світильників.

Анімація та скінінг

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

Для цієї мети можуть бути корисними вузли class_VisibleOnScreenEnabler3D і class_VisibleOnScreenNotifier3D.

Великі світи

Якщо ви створюєте великі світи, є інші міркування, ніж ті, які вам знайомі з менших ігор.

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

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