Обмен данными между графикой и физическим движком в игре?

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

Интересно, это хорошее решение для обмена данными между ними?

Два способа (делиться или нет) выглядит так:

Без обмена данными

GraphicsModel{
//some common for graphics and physics data like position

//some only graphic data
//like textures and detailed model's verticles that physics doesn't need
};

PhysicsModel{
//some common for graphics and physics data like position

//some only physics data
//usually my physics data contains A LOT more informations than graphics data
}

engine3D->createModel3D(...);
physicsEngine->createModel3D(...);

//connect graphics and physics data
//e.g. update graphics model's position when physics model's position will change

Я вижу две основные проблемы:

  1. Много избыточных данных (например, две позиции для физических и графических данных)
  2. Проблема с обновлением данных (мне приходится вручную обновлять графические данные при изменении физических данных)

С обменом данными

Model{
//some common for graphics and physics data like position
};

GraphicModel : public Model{
//some only graphics data
//like textures and detailed model's verticles that physics doesn't need
};

PhysicsModel : public Model{
//some only physics data
//usually my physics data contains A LOT more informations than graphics data
}

model = engine3D->createModel3D(...);
physicsEngine->assignModel3D(&model); //will cast to
//PhysicsModel for it's purposes??

//when physics changes anything (like position) in model
//(which it treats like PhysicsModel), the position for graphics data
//will change as well (because it's the same model)

Проблемы здесь:

  1. PhysicsEngine не может создавать новые объекты, просто «назначать» существующие из engine3D (для меня это выглядит более анти-независимым)
  2. Приведение данных в функцию assignModel3D
  3. physicsEngine и graphicsEngine должны быть осторожны — они не могут удалять данные, когда они им не нужны (потому что второй может понадобиться). Но это редкая ситуация. Более того, они могут просто удалить указатель, а не объект. Или мы можем предположить, что graphicsEngine удалит объекты, физика Engine просто указывает на них.

Какой способ лучше?

Что создаст больше проблем в будущем?

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

У них есть еще скрытые плюсы & контрас?

3

Решение

В настоящее время все больше игровых движков используют дизайн компонентов (например, Unity, Unreal). В этом виде дизайна, GameObject состоит из списка компонентов. В вашей ситуации может быть MeshComponent и PhysicalComponentоба прикреплены к одному игровому объекту.

Для простоты вы можете поместить переменную преобразования мира в GameObject, Во время обновления фразы, PhysicalComponent выводит преобразование мира в эту переменную. Во время рендеринга MeshComponent читает эту переменную.

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

Однако в реалистическом сценарии вам может потребоваться более сложная обработка между синхронизацией физики и графики. Например, физическое моделирование может потребоваться с фиксированным временным шагом (например, 30 Гц), в то время как рендеринг должен быть переменным. И вам может потребоваться интерполировать результаты с выхода физического движка. Некоторые физические движки (например, Bullet) имеют прямую поддержку этой проблемы.

Единство обеспечило хорошую ссылку на их Компоненты, который стоит посмотреть.

4

Другие решения

Других решений пока нет …

По вопросам рекламы ammmcru@yandex.ru
Adblock
detector