Я пишу игровой движок, который состоит из нескольких модулей. Двое из них являются графический движок и физический движок.
Интересно, это хорошее решение для обмена данными между ними?
Два способа (делиться или нет) выглядит так:
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
Я вижу две основные проблемы:
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)
Проблемы здесь:
Какой способ лучше?
Что создаст больше проблем в будущем?
Мне больше нравится второе решение, но мне интересно, почему большинство графических и физических движков предпочитают первое (может быть, потому, что они обычно делают только графический или только физический движок, и кто-то еще подключает их в игре?).
У них есть еще скрытые плюсы & контрас?
В настоящее время все больше игровых движков используют дизайн компонентов (например, Unity, Unreal). В этом виде дизайна, GameObject
состоит из списка компонентов. В вашей ситуации может быть MeshComponent
и PhysicalComponent
оба прикреплены к одному игровому объекту.
Для простоты вы можете поместить переменную преобразования мира в GameObject
, Во время обновления фразы, PhysicalComponent
выводит преобразование мира в эту переменную. Во время рендеринга MeshComponent
читает эту переменную.
Обоснование этого дизайна заключается в разделении между компонентами. ни MeshComponent
ни PhysicalComponent
знает друг друга Они просто зависят от общего интерфейса. И это может быть проще расширить систему по составу, чем с помощью единой иерархии наследования.
Однако в реалистическом сценарии вам может потребоваться более сложная обработка между синхронизацией физики и графики. Например, физическое моделирование может потребоваться с фиксированным временным шагом (например, 30 Гц), в то время как рендеринг должен быть переменным. И вам может потребоваться интерполировать результаты с выхода физического движка. Некоторые физические движки (например, Bullet) имеют прямую поддержку этой проблемы.
Единство обеспечило хорошую ссылку на их Компоненты, который стоит посмотреть.
Других решений пока нет …