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

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

Поширені проблеми продуктивності навігації можна розділити на такі теми:

• Проблеми з продуктивністю розбору вузлів дерева сцени для запікання сітки навігації.

• Проблеми з продуктивністю під час запікання фактичної сітки навігації.

• Проблеми з продуктивністю запитів шляхів NavigationAgent.

• Проблеми з продуктивністю фактичного пошуку шляху.

• Проблеми з продуктивністю синхронізації навігаційної карти.

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

Проблеми з продуктивністю розбору вузлів дерева сцени

Порада

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

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

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

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

Проблеми з продуктивністю під час запікання сітки навігації

Порада

Під час виконання завжди віддавайте перевагу використанню фонового потоку для запікання навігаційних сіток.

Збільште cell_size і cell_height NavigationMesh, щоб створити менше вокселів.

Змініть SamplePartitionType з вододілу на монотонний або шари, щоб підвищити ефективність випічки.

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

НІКОЛИ не масштабуйте вихідну геометрію за допомогою вузлів, щоб уникнути помилок точності. Більшість масштабів застосовуються лише візуально, а фігури, які є дуже великими в базовому масштабі, потребують значної додаткової обробки навіть у зменшеному масштабі.

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

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

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

Проблеми з продуктивністю запитів шляхів NavigationAgent

Порада

Уникайте непотрібного скидання шляху та запитів кожного кадру в сценаріях NavigationAgent.

Уникайте оновлення всіх шляхів NavigationAgent в одному кадрі.

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

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

Не перевіряйте заздалегідь, чи доступна цільова позиція кожного кадру. Те, що виглядає як невинна перевірка, є еквівалентом дорогого запиту шляху за сценою. Якщо план передбачає запит на новий шлях у будь-якому випадку, якщо позиція буде доступною, шлях слід запитувати безпосередньо. Дивлячись на останню позицію повернутого шляху та якщо ця позиція знаходиться на «досяжній» відстані до позначеної позиції, він відповідає на запитання «чи ця позиція доступна?» запитання. Це дозволяє уникнути виконання еквівалента двох повних запитів шляху в кожному кадрі для того самого NavigationAgent.

Розділіть загальну кількість NavigationAgent на групи оновлення або використовуйте випадкові таймери, щоб усі вони не запитували нові шляхи в одному кадрі.

Проблеми з продуктивністю фактичного пошуку шляху

Порада

Оптимізуйте наддеталізовані навігаційні сітки, зменшивши кількість багатокутників і країв.

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

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

Проблеми з продуктивністю синхронізації навігаційної карти

Порада

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

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

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

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