На графік сцени чи ні на графік сцени?


10

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

Деякі відомості: я пишу гру типу космічного шутера, орієнтовану на мобільну платформу (в першу чергу Android), і мій код майже повністю C ++. Я не використовую жодного проміжного програмного забезпечення; зокрема двигуни візуалізації та фізики - це мої власні творіння. Мій фізичний двигун оновлює місця розташування об'єктів на основі сил та імпульсів. У мене поки немає системи анімації, але я можу відвідати це в якийсь момент (що може або не має нічого спільного з цією дискусією).

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

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

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

Однак, враховуючи описані вище випадки використання, я вважаю, що можливість «працювати» у батьківському просторі стане дуже важливою, і намагання змусити мого фізичного двигуна підтримувати ці відносини через використання обмежень стане проблематичним.

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

Відповіді:


11

Ви насправді пробували ієрархічний графік і вимірювали ефективність?

Чи досліджували ви прості двигуни фізики, щоб побачити, як вони вирішують проблему, навіть 2D двигун, який має зв'язок між об'єктами, допоможе вам направити вас у перевіреному напрямку.

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

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


Я намагався обійтись не через продуктивність, а через час. Коли ти інді, то зациклювання на чомусь протягом тривалого періоду може бути згубним для прогресу та мислення. Я трохи переглянув двигун Spring RTS, але не знайшов того, що шукав. Отже, якщо я дам графік, у фізичному двигуні мені потрібно буде оновити місця розташування об'єктів у локальному просторі, а потім обчислити орієнтацію на світовий простір і повісити його на використання для виявлення зіткнень. Ви згадуєте "і назад", хоча це вимагає обчислення зворотної матриці, правда? Коли мені потрібно було б це зробити?
notlesh

Я б подумав, що якби проблема була, то використання бібліотеки фізики було б швидше, щоб заощадити багато часу налагодження. Якщо ви робите лише 2D, то, можливо, box2d.org ? Я запропонував "і назад", тому що це просто зворотний, як ви здогадалися. В якийсь момент ви, ймовірно, захочете взяти щось у світовому просторі та приєднати його до іншої моделі, яка цього потребує.
Патрік Х'юз
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.