Up to date

This page is up to date for Godot 4.2. If you still find outdated information, please open an issue.

Швидкодія

Вступ

Godot follows a balanced performance philosophy. In the performance world, there are always tradeoffs, which consist of trading speed for usability and flexibility. Some practical examples of this are:

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

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

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

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

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

З огляду на це, мета цього навчального розділу — пояснити, як отримати максимальну продуктивність Godot. Незважаючи на те, що ці статті можна читати в будь-якому порядку, бажано почати із Загальні поради щодо оптимізації.

Загальні

CPU

GPU

Просторова графіка

Потоки