Vers un graphique de scène ou non vers un graphique de scène?

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?

Avez-vous réellement essayé un graphique hiérarchique et mesuré les performances?

Avez-vous étudié des moteurs physiques simples pour voir comment ils gèrent le problème, même un moteur 2D qui a un lien entre des objets vous aiderait à vous guider dans une direction éprouvée.

Je n'essaierais pas d'exécuter votre physique dans plusieurs espaces, la complexité serait intimidante. Exécutez la physique dans l'espace mondial et ajoutez des fonctionnalités pour créer des transformations de votre hiérarchie pour déplacer des objets spatiaux locaux vers l'espace mondial et inversement. Vos contraintes, par nécessité, doivent se trouver dans l'espace local par rapport à l'objet parent.

En guise de remarque, même un pur tableau d'objets est un "graphique de scène", juste très simple. N'ayez pas peur d'organiser les données de manière à résoudre les problèmes et surtout ne décidez pas que les performances de cette organisation de données sont un facteur sans même avoir mesuré ces performances.