Я боровся з рішенням щодо того, чи слід впроваджувати графік сцени у свою гру чи ні. У мене є кілька випадків використання, які вимагають використання такого інструменту, але я не зміг ознайомитися з деякими деталями реалізації.
Деякі відомості: я пишу гру типу космічного шутера, орієнтовану на мобільну платформу (в першу чергу Android), і мій код майже повністю C ++. Я не використовую жодного проміжного програмного забезпечення; зокрема двигуни візуалізації та фізики - це мої власні творіння. Мій фізичний двигун оновлює місця розташування об'єктів на основі сил та імпульсів. У мене поки немає системи анімації, але я можу відвідати це в якийсь момент (що може або не має нічого спільного з цією дискусією).
По-перше, я опишу хороший випадок використання. Я хотів би мати боса, який складається з декількох дискретних частин, кожну з яких можна пошкодити / знищити самостійно. Наприклад, у мене може бути начальник, який має руку, яка може отримати шкоду незалежно від решти суб'єкта начальника. Коли рука знищена, ефект вогняних частинок, розташований біля плеча начальства, може означати, що рука тепер знищена.
Так і є, я вирішив спробувати вирішити подібні проблеми з обмеженнями в моєму фізичному двигуні, щоб зберегти такі складні об'єкти разом. Одне таке обмеження забезпечує 0 градусів свободи і по суті є матрицею перетворення. Це справді спроба обійти проблему, яка врешті-решт відмовила мене від графіків сцен, описаних нижче.
Основна причина, за якою я відмовився від використання графіка сцени, полягає в тому, що я не міг знайти ефективного способу збереження вкладених об'єктів (об’єктів, які успадковують перетворення від свого батьківського) як у світі фізики, так і у сцені візуалізації. Світ фізики потребує того, щоб об'єкти знаходилися у світовому просторі (або, принаймні, в тому ж просторі), а сцені візуалізації потрібні об'єкти у батьківському просторі. Відстеження місць в обох просторах може допомогти (і бути неминучим), але викликає власні занепокоєння, не останнє з них стосується продуктивності.
Однак, враховуючи описані вище випадки використання, я вважаю, що можливість «працювати» у батьківському просторі стане дуже важливою, і намагання змусити мого фізичного двигуна підтримувати ці відносини через використання обмежень стане проблематичним.
З огляду на описаний вище випадок використання та затруднення, чи слід використовувати графічну структуру для передачі перетворень від одного об’єкта до іншого? Якщо так, то як мій фізичний двигун повинен обчислювати нові місця та виконувати випробування на перехрестя для об’єктів у різних просторах?