Come posso usare più mesh per entità senza rompere un componente di un singolo tipo per entità?

Stiamo solo passando da un motore di gioco basato su gerarchia a un motore di gioco basato su componenti. Il mio problema è che quando carico un modello che ha una gerarchia di maglie, e per come capisco, è che un'entità in un sistema basato su componenti non può avere più componenti dello stesso tipo, ma ho bisogno di un "meshComponent" per ogni mesh in un modello. Quindi, come potrei risolvere questo problema.

Su questo sito hanno implementato un motore di gioco basato sui componenti: http://cowboyprogramming.com/2007/01/05/evolve-your-heirachy/

Il componente Posizione potrebbe avere una logica "genitore / figlio", in cui qualsiasi Entità con una Posizione può avere un genitore e la loro posizione è relativa al loro genitore. Invece di avere più mesh sulla stessa entità, puoi creare più di una entità, ognuna con la propria mesh e collegarle insieme. Puoi persino far sì che le entità secondarie ascoltino i loro eventi principali (o qualunque sistema tu abbia per la comunicazione tra entità) e reagire di conseguenza.

MeshComponent può contenere un elenco di mesh. Non sono sicuro di come stai implementando il tuo motore, ma un sistema potrebbe facilmente scorrere su tutte le mesh e semplicemente disegnarle.

Vorrei creare il mio componente mesh con un elenco di oggetti mesh. Ogni oggetto mesh ha i dati mesh insieme a un offset. Durante il disegno, il sistema di disegno prende la posizione dal componente posizione, quindi disegna ogni mesh nel componente mesh in posizione + offset.

Puoi avere più mesh all'interno del tuo componente mesh, continuando a dire con un singolo componente mesh per entità.

TLDR: rendendo il componente costituito da più mesh per cominciare.

Concordo con Asakeron / Byte56 / Laurent in quanto è necessario un altro livello di riferimento indiretto tra le coppie mesh / materiale e l'entità stessa. Invece di guardare il GraphicsComponent come vertici e materiali, pensalo come un blob di pixel sul raster finale: come ottengono lì un dettaglio di implementazione e niente di più.

Ci ho pensato molto per il mio progetto e penso che la soluzione ottimale sia quella di rendere GraphicsComponent un componente di livello molto più alto, che comprenda gran parte delle funzionalità dell'oggetto tradizionale "Modello", perché questa funzionalità non è opzionale! Per rendere quei poligoni molto più che semplici dati del buffer e lo shader è necessario, come ad esempio:

• Posizione che hai menzionato
• Dati di skinning / animazione
• Il passaggio corrente (ad es. Se si utilizza l'alfa a due passaggi)
• Informazioni sul lancio dell'ombra (se lo stai facendo)
• Informazioni su come e quando aggiornare il materiale
• Funzionalità di abbattimento

E questo è solo per le risorse 3D, senza considerare i sistemi di particelle, i cartelloni pubblicitari, ecc. Ma tutto ciò è pertinente solo al codice di grafica / rendering - non influisce sulla fisica, sul suono o sugli script, quindi ha senso che dovrebbe stare in il componente Grafica / Rendering.

Ho finito 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

In questo:

• Il modello è qualsiasi risorsa di gioco che ha un componente grafico.

• Il ModelComponent è analogo al modello tradizionale e, in effetti, lo è, per le risorse 3D. Il controller GraphicsComponent (se si utilizza il modello Model-View-Controller) è responsabile per capire quale tipo di risorsa grafica è e disegnarla correttamente (si noti che ModelComponent è una sottoclasse di GraphicsComponent).

C'erano anche un paio di compromessi nei miei per semplicità e compatibilità con le versioni precedenti, come ogni GraphicsComponent è anche un'entità, e Entity memorizza i dati di posizione direttamente in modo che vengano calcolati solo in un posto, ma l'idea è la stessa: GraphicsComponent gestisce ciò che è necessario per disegnare l'oggetto - tutto ciò che è necessario - non solo ciò che viene dal modellatore.