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

11

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

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

Матиас Хельцль
источник
Я думаю, что это слишком локализовано.
jcora
4
Я думаю, что это общий вопрос. Может ли игровой объект иметь несколько экземпляров одного и того же компонента?
Матиас Хёльцль
Да, это могло бы быть, если бы об этом спросили. Мне кажется, будто он искал ответ на очень специфическую проблему.
Jcora
4
«... сущность в системе компонентов не может иметь несколько компонентов одного типа ...» - почему бы и нет?
День
Я не думаю, что это слишком локализовано. Например, в UE3 SkeletalMeshActorтолько один SkeletalMeshComponent. Это общая проблема, которую можно решать разными способами.
Сам Hocevar

Ответы:

13

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

Люк Б.
источник
Итак, у меня есть иерархия сущностей, и эти сущности имеют составляющие и связаны друг с другом. Тогда это еще игровой движок, основанный на компонентах =)
Матиас Хёльцль
@ MathiasHölzl это вопрос? Этот вид иерархии отличается от проблемной иерархии в ООП. Это просто графическая иерархия, дочерние объекты не будут наследовать функциональность от своих родителей и доставят вам неприятности, это обычно делается в любом случае (имея дерево для визуализации). Вы также можете пойти с Asakeron ответом на вашу проблему, имея список мешей, я не вижу, как это проблематично. Может я не понимаю твой вопрос?
Люк Б.
-1 Не уверен, что это действительно так. Если вам нужен компонент, обрабатывающий иерархию ячеек, почему бы не иметь объект ModelComponent, содержащий иерархию ячеек? Разделение сущности только для этого звучит как неправильное решение проблемы. Смотрите ответы Асакерона и Байта56.
Лоран Кувиду
@ LaurentCouvidou Я не понимаю, почему было бы неправильно использовать более одной сущности, мне кажется, это хорошее решение. Я просто хотел дать другую альтернативу наличию списка сеток, хотя я согласен, что список сеток также будет хорошим решением.
Люк Б.
@LukeB. Потому что эта группа меша может соответствовать одной сущности в целом, с компонентами, которые зависят от этого, например, ИИ, звук, физика ... Делая это, вы получаете граф сцены и все его причуды.
Лоран Кувиду
8

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

Asakeron
источник
1
Сетка также имеет такие компоненты, как преобразование, физика, графика ...
Mathias Hölzl
1
Так что меш это сущность? Или все это компонент? В моем понимании, преобразование, физика и графика должны быть компонентами в сущности, а не в сетке, сетка - это просто описание вершин.
Люк Б.
1
Да, это должен быть компонент, но компоненты не могут иметь компоненты, поэтому сложно реализовать иерархию модели.
Матиас Хёльцль
1
Я считаю, что вы должны предоставить больше информации о том, как вы собираетесь построить свой двигатель, чтобы получить лучшие ответы. Entity компоненты система может быть реализована различными способами, проверить этот ответ на Kylotan для получения дополнительной информации о том , что.
Асакерон
4

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

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

MichaelHouse
источник
1

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 обрабатывает то, что необходимо нарисовать предмет - все, что нужно, а не только то, что исходит от моделиста.

sebf
источник