Как я могу использовать несколько ячеек на объект, не разбивая один компонент одного типа на объект?

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

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

Ваш компонент Position может иметь логику «родитель / потомки», где любой объект с позицией может иметь родителя, а его позиция относительно своего родителя. Вместо того, чтобы иметь несколько сеток на одной и той же сущности, вы можете создать более одной сущности, каждая со своей сеткой и связать их вместе. Вы даже можете заставить дочерние объекты слушать их родительские события (или любую другую систему, которую вы используете для связи между объектами) и реагировать соответствующим образом.

Ваш meshComponent может содержать список мешей. Я не уверен, как вы реализуете свой движок, но система может легко перебрать все сетки и просто нарисовать их.

Я бы создал свой компонент сетки со списком объектов сетки. Каждый объект сетки имеет данные сетки вместе со смещением. При рисовании система рисования берет позицию из компонента позиции, затем рисует каждую сетку в компоненте сетки в позиции + смещение.

Вы можете иметь несколько сеток внутри вашего компонента сетки, в то же время говоря, с одним компонентом сетки для каждой сущности.

TLDR: для начала компонент состоит из нескольких мешей.

Я согласен с Asakeron / Byte56 / Laurent в том, что необходим другой уровень косвенности между парами сетки / материала и самой сущностью. Вместо того, чтобы смотреть на 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 аналогичен традиционной модели и фактически для трехмерных активов. Контроллер GraphicsComponent (если вы используете шаблон Model-View-Controller) отвечает за определение типа графического актива и правильное его рисование (обратите внимание, что ModelComponent является подклассом GraphicsComponent).

У меня также было несколько компромиссов для простоты и обратной совместимости, например, каждый GraphicsComponent также является Entity, и Entity хранит данные Position напрямую, поэтому они рассчитываются только в одном месте, но идея та же: GraphicsComponent обрабатывает то, что необходимо нарисовать предмет - все, что нужно, а не только то, что исходит от моделиста.