Як я можу використовувати декілька сіток на одну сутність, не порушуючи один компонент одного типу на сутність?

Ми просто переходимо від ігрового двигуна на основі ієрархії до ігрового двигуна на основі компонентів. Моя проблема полягає в тому, що коли я завантажую модель, яка має ієрархію сіток, і, як я розумію, полягає в тому, що сутність в системі, що базується на компонентах, не може мати декілька компонентів одного типу, але мені потрібен "meshComponent" для кожного сітка в моделі. То як я міг вирішити цю проблему.

На цьому сайті вони впровадили ігровий движок на основі компонентів: http://cowboyprogramming.com/2007/01/05/evolve-your-heirachy/

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

Ваш meshComponent може містити список сіток. Я не впевнений, як ви реалізуєте свій двигун, але система може легко перебирати всі сітки та просто малювати їх.

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

Ви можете мати декілька сіток всередині вашого компонента сітки, при цьому все одно говорячи з одним компонентом сітки на сутність.

TLDR: Створення компонента складається з декількох сіток для початку.

Я погоджуюся з Асакероном / Байт56 / Лоран в тому, що потрібен ще один рівень непрямості між сітчастими / матеріальними парами та самою сутністю. Замість того, щоб дивитися на GraphicsComponent як вершини та матеріали, подумайте про це як на краплину пікселів на остаточному растрі - як це / вони там є - це детальна інформація про реалізацію і більше нічого.

Я багато думав про це для свого проекту, і я думаю, що оптимальним рішенням є зробити GraphicsComponent набагато вищим рівнем компонента, що охоплює більшу частину функціональності традиційного об'єкта "Модель" - адже ця функціональність не є обов'язковою! Щоб зробити ці багатокутники набагато більше, ніж просто дані буфера і шейдер, наприклад:

• Позиція, яку ви згадали
• Дані зняття / анімації
• Поточний прохід (наприклад, якщо використовується два альфа пропуску)
• Інформація про лиття тіней (якщо ви це робите)
• Інформація про те, як і коли оновлювати матеріал
• Функція вилучення

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

Я закінчив:

Model : Entity, IHasGraphicsComponent, IHasSkeleton, IHasAnimationStore     //This is the 'game object' - it is passed to the GraphicsController
    ModelComponent : GraphicsComponent                      //This is the actual graphics component, used by the GraphicsController in the context of the game object.
        ModelComponentPart : GraphicsComponent              //This is also a graphics component
            Mesh                                        //These are implementation details
            Material
        ModelComponentPart : GraphicsComponent
            Mesh
            Material
    Skeleton
    Animations

У цьому:

• Модель - це будь-який ігровий актив, який має графічну складову.

• ModelComponent є аналогом традиційної моделі і насправді є для 3D-активів. Контролер GraphicsComponent (якщо ви використовуєте шаблон Model-View-Controller) несе відповідальність за з'ясування типу графічного активу та його правильне малювання (зауважте, що ModelComponent є підкласом GraphicsComponent).

У моїй роботі було також кілька компромісів для простоти та зворотної сумісності, такі як кожен GraphicsComponent також є об'єктом, і Entity зберігає дані про позицію безпосередньо, тому його обчислюються лише в одному місці, але ідея та ж: GraphicsComponent обробляє те, що є потрібно було намалювати предмет - все те, що потрібно - не тільки те, що походить від модельєра.