Comment puis-je utiliser plusieurs maillages par entité sans casser un composant d'un seul type par entité?

Nous passons simplement d'un moteur de jeu basé sur la hiérarchie à un moteur de jeu basé sur des composants. Mon problème est que lorsque je charge un modèle qui a une hiérarchie de maillages, et d'après ce que je comprends, une entité dans un système basé sur des composants ne peut pas avoir plusieurs composants du même type, mais j'ai besoin d'un "meshComponent" pour chacun maillage dans un modèle. Alors, comment pourrais-je résoudre ce problème.

Sur ce site, ils ont implémenté un moteur de jeu basé sur les composants: http://cowboyprogramming.com/2007/01/05/evolve-your-heirachy/

Votre composant Position peut avoir une logique "parent / enfants", où toute entité avec une position peut avoir un parent et leur position est relative à leur parent. Au lieu d'avoir plusieurs mailles sur la même entité, vous pouvez créer plusieurs entités, chacune avec son propre maillage et les lier ensemble. Vous pouvez même faire en sorte que les entités enfants écoutent leurs événements parents (ou tout autre système dont vous disposez pour la communication entre les entités) et réagir en conséquence.

Votre meshComponent peut contenir une liste de maillages. Je ne sais pas comment vous implémentez votre moteur, mais un système pourrait facilement parcourir tous les maillages et simplement les dessiner.

Je créerais mon composant maillé avec une liste d'objets maillés. Chaque objet maillé a les données de maillage avec un décalage. Lors du dessin, le système de dessin prend la position du composant de position, puis dessine chaque maillage du composant de maillage en position + décalage.

Vous pouvez avoir plusieurs maillages à l'intérieur de votre composant maillé, tout en disant avec un seul composant maillé par entité.

TLDR: en faisant en sorte que le composant se compose de plusieurs maillages pour commencer.

Je suis d'accord avec Asakeron / Byte56 / Laurent en ce qu'un autre niveau d'indirection est nécessaire entre les paires maillage / matériau et l'entité elle-même. Au lieu de regarder le GraphicsComponent comme des sommets et des matériaux, pensez-y comme un blob de pixels sur le raster final - comment il / ils y arrivent est un détail d'implémentation et rien de plus.

J'ai beaucoup réfléchi à cela pour mon projet et je pense que la solution optimale est de faire du GraphicsComponent un composant de niveau beaucoup plus élevé, englobant une grande partie des fonctionnalités de l'objet 'Model' traditionnel - car cette fonctionnalité n'est pas facultative! Pour rendre ces polygones bien plus que les données du tampon et le shader sont nécessaires, tels que:

• Position que vous avez mentionnée
• Données de skinning / animation
• La passe actuelle (par exemple, si vous utilisez alpha à deux passes)
• Informations sur le casting d'ombres (si vous le faites)
• Informations sur comment et quand mettre à jour le matériel
• Fonction d'élimination

Et c'est juste pour les ressources 3D, sans prendre en compte les systèmes de particules, les panneaux d'affichage, etc. Mais tout cela n'est pertinent que pour le code graphique / de rendu - cela n'affecte pas la physique, le son ou les scripts, il est donc logique qu'il devrait s'asseoir le composant Graphics / Rendering.

Je me suis retrouvé avec:

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

Dans ce:

• Le modèle est tout élément de jeu qui possède un composant graphique.

• Le ModelComponent est analogue au modèle traditionnel et, en fait, est destiné aux ressources 3D. Le contrôleur GraphicsComponent (si vous utilisez le modèle Model-View-Controller) est responsable de déterminer de quel type d'actif graphique il s'agit et de le dessiner correctement (notez que ModelComponent est une sous-classe de GraphicsComponent).

Il y avait aussi quelques compromis dans le mien pour des raisons de simplicité et de compatibilité descendante, comme chaque GraphicsComponent est également une entité, et l'entité stocke directement les données de position afin qu'elles ne soient calculées qu'en un seul endroit, mais l'idée est la même: GraphicsComponent gère ce qui est nécessaire pour dessiner l'article - tout ce qui est nécessaire - pas seulement ce qui vient du modélisateur.