Для графа сцены или нет для графа сцены?

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

Немного предыстории: я пишу игру типа космического шутера, ориентированную на мобильную платформу (прежде всего, на Android), и мой код почти полностью написан на C ++. Я не использую никакого промежуточного программного обеспечения; рендеринг и физические движки, в частности, являются моими собственными творениями. Мой физический движок обновляет местоположение объектов, основываясь на силах и импульсах. У меня пока нет системы анимации, но я могу посетить это в какой-то момент (что может иметь или не иметь никакого отношения к этой дискуссии).

Сначала я опишу хороший вариант использования. Я хотел бы иметь босса, который состоит из нескольких отдельных частей, каждая из которых может быть повреждена / уничтожена независимо. Например, у меня может быть босс, у которого есть рука, которая может получать урон независимо от остальной части босса. Когда рука уничтожена, эффект огненной частицы, расположенный на плече босса, может указывать на то, что рука теперь уничтожена.

На самом деле, я решил попробовать решить такие проблемы с ограничениями в моем физическом движке, чтобы объединить такие сложные объекты. Одно из таких ограничений обеспечивает 0 степеней свободы и является по существу матрицей преобразования. Это действительно попытка обойти проблему, которая в конечном итоге отвлекла меня от графов сцены, описанных ниже.

Основная причина, по которой я отказался от использования графа сцены, заключается в том, что я не смог найти эффективный способ сохранить вложенные объекты (объекты, которые наследуют преобразование от своего родителя) как в мире физики, так и в сцене рендеринга. Мир физики нуждается в объектах, находящихся в мировом пространстве (или, по крайней мере, в одном и том же пространстве), в то время как сцена рендеринга нуждается в объектах в родительском пространстве. Отслеживание местоположений в обоих местах может помочь (и быть неизбежным), но вызывает свои собственные проблемы, не в последнюю очередь связанные с производительностью.

Однако, учитывая варианты использования, подобные описанному выше, я думаю, что возможность «работать» в родительском пространстве станет очень важной, и попытка заставить мой физический движок поддерживать эти отношения посредством использования ограничений станет проблематичной.

Учитывая описанный выше сценарий использования и затруднения, должен ли я использовать структуру графа для передачи преобразований из одного объекта в другой? Если так, как мой физический движок должен вычислять новые местоположения и выполнять тесты пересечения для объектов в разных пространствах?

Вы на самом деле пробовали иерархический график и измерили производительность?

Вы исследовали простые физические движки, чтобы увидеть, как они справляются с проблемой, даже двумерный движок, который имеет связь между объектами, поможет вам в проверенном направлении.

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

Как примечание: даже чистый массив объектов - это «граф сцены», очень простой. Не бойтесь организовывать данные таким образом, чтобы решать проблемы, и особенно не решайте, что производительность этой организации данных является фактором, даже не измеряя ее.