¿Cómo puedo usar múltiples mallas por entidad sin romper un componente de un solo tipo por entidad?

Solo estamos cambiando de un motor de juego basado en la jerarquía a un motor de juego basado en componentes. Mi problema es que cuando cargo un modelo que tiene una jerarquía de mallas, y lo entiendo, es que una entidad en un sistema basado en componentes no puede tener múltiples componentes del mismo tipo, pero necesito un "componente de malla" para cada malla en un modelo. Entonces, ¿cómo podría resolver este problema?

En este sitio implementaron un motor de juego basado en componentes: http://cowboyprogramming.com/2007/01/05/evolve-your-heirachy/

Su componente de posición podría tener una lógica "padre / hijos", donde cualquier entidad con una posición puede tener un padre y su posición es relativa a su padre. En lugar de tener varias mallas en la misma entidad, puede crear más de una entidad, cada una con su propia malla y vincularlas. Incluso puede hacer que las entidades secundarias escuchen sus eventos primarios (o cualquier sistema que tenga para la comunicación entre entidades) y reaccionen en consecuencia.

Su meshComponent puede contener una lista de mallas. No estoy seguro de cómo está implementando su motor, pero un sistema podría iterar fácilmente sobre todas las mallas y simplemente dibujarlas.

Crearía mi componente de malla con una lista de objetos de malla. Cada objeto de malla tiene los datos de malla junto con un desplazamiento. Al dibujar, el sistema de dibujo toma la posición del componente de posición, luego dibuja cada malla en el componente de malla en posición + desplazamiento.

Puede tener múltiples mallas dentro de su componente de malla, mientras dice con un solo componente de malla por entidad.

TLDR: al comenzar, el componente consiste en múltiples mallas.

Estoy de acuerdo con Asakeron / Byte56 / Laurent en que se necesita otro nivel de indirección entre los pares de malla / material y la entidad misma. En lugar de ver el GraphicsComponent como vértices y materiales, considérelo como una mancha de píxeles en el ráster final: cómo llegan allí hay un detalle de implementación y nada más.

Pensé mucho en esto para mi proyecto y creo que la solución óptima es hacer que GraphicsComponent sea un componente de nivel mucho más alto, que abarque gran parte de la funcionalidad del objeto tradicional 'Modelo', ¡porque esta funcionalidad no es opcional! Para representar esos polígonos mucho más que solo los datos del búfer y el sombreador es necesario, como:

• Posición que has mencionado
• Skinning / Animación de datos
• El Pase Actual (por ejemplo, si usa dos pasos alfa)
• Información de lanzamiento de sombras (si lo está haciendo)
• Información sobre cómo y cuándo actualizar el material.
• Funcionalidad de selección

Y eso es solo para los activos 3D, sin tener en cuenta los sistemas de partículas, carteles, etc. Pero todo es pertinente solo para el código de gráficos / renderizado: no afecta la física, el sonido o las secuencias de comandos, por lo que tiene sentido que se asiente el componente de gráficos / renderizado.

Terminé con:

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

En esto:

• El modelo es cualquier activo del juego que tiene un componente gráfico.

• ModelComponent es análogo al modelo tradicional y, de hecho, lo es para los activos 3D. El controlador GraphicsComponent (si usa el patrón Modelo-Vista-Controlador) es responsable de averiguar qué tipo de activo gráfico es y dibujarlo correctamente (tenga en cuenta que ModelComponent es una subclase de GraphicsComponent).

También hubo un par de compromisos en la mía por la simplicidad y la compatibilidad con versiones anteriores, como cada GraphicsComponent también es una Entidad, y la Entidad almacena los datos de Posición directamente, por lo que solo se calcula en un lugar, pero la idea es la misma: GraphicsComponent maneja lo que es necesitaba dibujar el elemento, todo lo que se necesita, no solo lo que proviene del modelador.