J'ai eu du mal à prendre une décision concernant l'implémentation ou non d'un graphique de scène dans mon jeu. J'ai certains cas d'utilisation qui nécessitent un tel outil, mais je n'ai pas pu passer en revue certains détails de la mise en œuvre.
Quelques antécédents: j'écris un jeu de type shooter spatial destiné à une plate-forme mobile (Android, principalement) et mon code est presque entièrement en C ++. Je n'utilise aucun middleware; les moteurs de rendu et de physique en particulier sont mes propres créations. Mon moteur physique met à jour les emplacements des objets en fonction des forces et des impulsions. Je n'ai pas de système d'animation pour le moment mais je peux le visiter à un moment donné (ce qui peut ou non avoir quelque chose à voir avec cette discussion).
Tout d'abord, je vais décrire un bon cas d'utilisation. J'aimerais avoir un boss composé de plusieurs pièces discrètes, chacune pouvant être endommagée / détruite indépendamment. Par exemple, je pourrais avoir un boss qui a un bras qui peut recevoir des dégâts indépendamment du reste de l'entité boss. Lorsque le bras est détruit, un effet de particules de feu situé sur l'épaule du boss pourrait indiquer que le bras est maintenant détruit.
En l'état, j'ai décidé d'essayer de résoudre de tels problèmes avec des contraintes dans mon moteur physique pour garder ces objets composés ensemble. Une telle contrainte fournit 0 degré de liberté et est essentiellement une matrice de transformation. C'est vraiment une tentative de contourner un problème qui m'a finalement désactivé des graphiques de scène en premier lieu, décrits ci-dessous.
La principale raison pour laquelle je me suis détourné de l'utilisation d'un graphique de scène est que je n'ai pas trouvé de moyen efficace de conserver les objets imbriqués (objets qui héritent d'une transformation de leur parent) dans le monde de la physique et dans la scène de rendu. Le monde de la physique a besoin que les objets soient dans l'espace-monde (ou au moins le même espace) tandis que la scène de rendu a besoin d'objets dans l'espace-parent. Le suivi des emplacements dans les deux espaces peut aider (et être inévitable) mais soulève ses propres préoccupations, notamment la performance.
Cependant, étant donné les cas d'utilisation comme celui décrit ci-dessus, je pense que pouvoir `` travailler '' dans l'espace parent deviendra très important, et essayer de forcer mon moteur physique à maintenir ces relations en utilisant des contraintes va devenir problématique.
Étant donné le cas d'utilisation et la situation difficile décrits ci-dessus, dois-je utiliser une structure de graphe pour passer des transformations d'un objet à un autre? Si oui, comment mon moteur physique doit-il calculer de nouveaux emplacements et effectuer des tests d'intersection pour des objets dans différents espaces?