Що має міститись у графіку сцени гри?

Ви допоможете мені уточнити, будь ласка, що саме має міститись у графіку сцени гри? Дивіться наступний список, будь ласка:

• Ігрові актори? (очевидно, що так, всі об'єкти, що змінюються, повинні бути головним графіком сцени)
• Проста статична гра ojbects? (Я маю на увазі місця, що відхиляються на задньому плані, які не анімуються, не стикаються)
• Ігрові тригери?
• Ігрові вогні?
• Ігрові камери?
• Кулі зброї ?
• Ігрові вибухи та спецефекти?

Вище розглянуті типи об'єктів. Тепер до висвітлення графіка сцени:

• Чи повинен графік сцени містити всю карту рівня гри з початку рівня, або він повинен містити лише видиму частину карти? Якщо друге вірно, це означатиме, що графік сцени буде постійно оновлюватися, додаючи / видаляючи ігрові об’єкти в міру переміщення гравця. Однак, маючи лише видимі карти, очевидно, було б набагато швидше об'їхати та оновити.

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

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

Документація до SceneNode:
http://www.ogre3d.org/docs/api/1.9/class_ogre_1_1_scene_node.html

Документація до SceneManager: http://www.ogre3d.org/docs/api/1.9/class_ogre_1_1_scene_manager.html

Щось ще варто поглянути за наступним посиланням:
http://sgl.sourceforge.net/#features

Це рішення на основі OpenGL, графік сцени і на сторінці функцій показані всі вузли, які він може містити.

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

Ігрові актори
я, мабуть, скажу "ні". Як і у Ogre, у мене був би базовий клас Entity (який містив би певну логіку об'єкта) та базовий SceneNode з вказівником члена Entity, щоб отримати відповідну інформацію для візуалізації об'єкта (положення, орієнтація тощо)

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

Проста статична гра ojbects
Так

Ігрові тригери?
Ні, це для мене звучить як гра специфічна логіка.

Ігрові вогні?
Так

Ігрові камери?
Так

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

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

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

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

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

Моя схильність полягає в тому, щоб запропонувати помістити менше речей у графіку сцени. Дивіться, зокрема, цю статтю Тома Форсайта: " Графіки сцен - просто скажіть ні ".

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

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

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

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

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

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

Я використовую методи просторового розподілу, відповідні стилю гри (квадратичне дерево, octree, BSP, і так далі), щоб групувати / виключати логічні об'єкти в грі, які повинні (а) обробляти цей кадр і (б) надавати цей кадр. Потім я закінчую подачу набору об'єктів зі списку (b) в систему, яка відображає логічні об’єкти для візуалізації описів і сортує ці описи у відра на основі властивостей (наприклад, все, що використовує прозорість, буде занесено у відро для "речі" Тоді я відтворюю кожне відро в порядку, і для кожного відра викладаю кожен опис по порядку. Я думаю, ви могли б назвати це "деревом", але воно не демонструє типового стану / перетворення методів поширення, які роблять традиційні графіки сцен, орієнтованих на дерево. YYMV,