Чи повинен я обмінюватися даними між графікою та фізикою в грі?


9

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

Цікаво, чи є хорошим рішенням обмін даними між ними?

Два способи (поділитися чи ні) виглядає так:

Без обміну даними

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->assingModel3D(&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. Кастинг даних у функції assingModel3D
  3. physicsEngine та graphicsEngine повинні бути обережними - вони не можуть видаляти дані, коли вони їм не потрібні (адже другий може знадобитися). Але це рідкісна ситуація. Більше того, вони можуть просто видалити вказівник, а не об’єкт. Або ми можемо припустити, що graphicsEngine видалить об'єкти, PhysicsEngine просто покаже на них.

Який шлях краще?

Що спричинить більше проблем у майбутньому?

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

Чи є у них більше прихованих плюсів і контрастів?


Точно і моє запитання.
danijar

Відповіді:


9

На сьогоднішній день все більше ігрових двигунів приймає конструкцію компонентів (наприклад, Unity, Unreal). У цьому виді дизайну, a GameObjectскладається з переліку компонентів. У вашій ситуації можуть бути а MeshComponentі PhysicalComponent, обидва прикріплені до одного ігрового об’єкта.

Для простоти ви можете помістити змінну перетворення світу в GameObject. Під час оновлення фрази PhysicalComponentвиводить перетворення світу на цю змінну. Під час візуалізації MeshComponentчитає цю змінну.

Обґрунтуванням цієї конструкції є роз'єднання між компонентами. Ні, MeshComponentні PhysicalComponentзнають один одного. Вони просто залежать від загального інтерфейсу. І можна простіше розширити систему за складом, ніж використовувати єдину ієрархію успадкування.

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

Єдність дала хороший довідник про їх Компоненти , які варто подивитися.


Це взагалі не дає відповіді на запитання, якщо два компоненти не говорять про те, поділяють вони меш-дані чи ні.
Майк Семдер

2
Власне, він пропонує кращий дизайн, що цілком законно.
jcora

7

Двигуни зазвичай вибирають перший варіант (власну фізику-сітку та власну рендер-сітку), оскільки їм потрібні дуже різні дані, як за якістю, так і за кількістю.

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

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

Розв’язуючи обидва, ми переконуємось, що ми можемо змінити один, включаючи зміну його макета даних для кращої продуктивності, не псуючи іншу. Це набагато масштабніше.


0

Окрім @Millo Yip чудова відповідь, я хотів би лише нагадати вам, що вам потрібно буде поділитися тими ж даними з модулем Controls та модулем AI, і якщо я не помиляюсь, більшість аудіобібліотек мають поняття про положення звукового випромінювача тому вам також потрібно буде поділитися даними з цим модулем.


0

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

Як ви отримуєте дані від фізики до передачі, залежить лише від вас.

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

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

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.