Використання об'єктів у Кімнатах і Порталах

Зазвичай, коли ви використовуєте Godot, всі об’єкти, які ви можете побачити (VisualInstance), обробляються рушієм однаково. Рендерер порталу дещо відрізняється тим, що розділяє об’єкти у вашій грі. Цей поділ потрібний, щоб визначити кімнати, а також найефективніше все відобразити та обробити.

Режим Порталу

Якщо ви подивитеся на інспектор, кожна VisualInstance в Godot містить CullInstance, де ви можете встановити PortalMode (Режим Порталу). Цей параметр визначає, як будуть вести себе об'єкти в системі порталів.

STATIC (СТАТИЧНИЙ)

Типовим режимом для об'єктів є STATIC. Статичні об'єкти - це об'єкти всередині кімнат, які не будуть рухатися протягом усього життєвого циклу рівня. Такі речі, як підлога, стіни, стелі, є хорошими кандидатами для STATIC об'єктів.

DYNAMIC (ДИНАМІЧНИЙ)

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

ROAMING (ПЕРЕМІЩУВАНИЙ)

Переміщуваний режим призначений для об'єктів, які можуть переміщатися між кімнатами. Такі речі, як гравці і вороги, повинні мати переміщуваний режим. Їх дорожче прорахувати, ніж режими STATIC, або DYNAMIC, тому що система повинна відстежувати, в якій кімнаті знаходиться переміщуваний об'єкт.

GLOBAL (ГЛОБАЛЬНИЙ)

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

IGNORE (ІГНОРУВАТИ)

IGNORE - це спеціальний режим для об'єктів, які будуть по суті вільними в системі. Ручні межі (-bound) автоматично встановлюються на режим ігнорування порталу. Вони не повинні з'являтися під час гри, але зберігаються в дереві сцени на випадок, якщо вам потрібно перетворити рівень кілька разів (наприклад, у редакторі). Ви також можете використовувати цей режим для об'єктів, які хочете відображати лише в редакторі (коли RoomManager (Керівник кімнат) неактивний).

Чи слід розміщувати об’єкти в кімнатах (у дереві сцени) чи ні?

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

Автоматичне розміщення

Однак, для зручності використання, також можна розмістити предмети STATIC і DYNAMIC за межами кімнат в дереві сцени, але в межах гілки RoomList (Списку кімнат). Система буде намагатися автоматично розмістити об'єкти у відповідній кімнаті. Це працює в більшості випадків, але якщо ви сумніваєтеся, використовуйте явний підхід. Явний підхід особливо необхідний при роботі з внутрішніми приміщеннями, які мають деякі обмеження для розлогих об'єктів.

Запримітьте, що якщо ви розміщуєте об'єкти STATIC і DYNAMIC за межами кімнат, то не сприяєте їх прив'язці до кімнат. Якщо ви використовуєте геометрію кімнати, щоб вивести прив'язку, столи та стільці можуть бути розміщені за межами кімнати. Однак стіни та підлога повинні бути явно в межах гілки кімнати дерева сцени, щоб прив'язка точно була правильна.

Об'єкти ROAMING і GLOBAL рекомендується зберігати в гілці дерева сцени за межами будь-яких кімнат, чи RoomList. Їх можна розмістити всередині кімнат, але щоб заощадити плутанину, краще їх тримати на окремій гілці. Обмежень на розміщення об'єктів IGNORE немає.

Час існування об'єкта

Важливо відзначити, що час існування об'єктів STATIC і DYNAMIC прив'язаний до часу існування рівня, між викликами, rooms_convert() для активації портальної системи, і rooms_clear() для вивантаження з системи. Це пов'язано з тим, що на етапі перетворення відбувається досить багато попередньої обробки, щоб зробити їх ефективними.

Тому не слід намагатися створювати або видаляти об'єкти STATIC, чи DYNAMIC, поки активна система порталів. Це призведе до автоматичного вивантаження системи, оскільки вона отримає збій. Однак ви можете вільно show() (показувати) та hide() (приховувати) ці об’єкти.

Отож, послідовність повинна бути така:

• Завантажуєте свій рівень.

• Розміщуєте будь-які STATIC, або DYNAMIC об'єкти.

• Аж тоді запускаєте rooms_convert(), після того як всі STATIC і DYNAMIC об'єкти були додані до дерева сцени.

Об'єкти ROAMING, GLOBAL, чи IGNORE, можуть бути вільно створені та видалені за потреби.

Розлогі об'єкти

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

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

Поля Порталу

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

Ви можете встановити глобальне поле в RoomManager. Ви також можете перевизначити це значення поля на будь-якому порталі, якщо вам потрібно налаштувати деталі. При редагуванні значення поля в інспекторі, ви повинні бачити оновлення поля у вікні перегляду 3D редактора.

Include in Bound (Включити Прив'язку)

Підтримка об'єктів, які займають більше однієї кімнати, має один побічний ефект. Можливо, ви не забажаєте включати деякі об'єкти в розрахунок автоматичної прив'язки до кімнат. Ви можете ввімкнути та вимкнути це в інспекторі для кожного об'єкта. Дивіться Cull Instance > Include In Bound.

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

Освітлення

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

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