Que doit contenir un graphique de scène de jeu?

Pourriez-vous m'aider à clarifier, s'il vous plaît, ce qui devrait exactement être contenu dans un graphique de scène de jeu? Voir la liste suivante, s'il vous plaît:

• Acteurs de jeux? (évidemment oui, tous les objets qui changent d'état devraient être le principal élément du graphique de scène)
• Des jeux statiques simples? (Je veux dire des objets en arrière-plan qui ne s'animent pas et ne se heurtent pas non plus)
• Déclencheurs de jeu ?
• Lumières de jeu ?
• Caméras de jeu ?
• Balles d' armes ?
• Explosions de jeu et effets spéciaux?

Les types d'objets considérés ci-dessus. Passons maintenant à la couverture du graphique de la scène:

• Un graphique de scène doit-il contenir l' intégralité de la carte du niveau de jeu depuis le début du niveau, ou doit-il contenir uniquement la partie visible de la carte? Si la seconde est vraie, cela signifierait que le graphique de la scène serait continuellement mis à jour, en ajoutant / supprimant des objets de jeu, au fur et à mesure que le joueur se déplace. Cependant, ne contenir que les éléments visibles de la carte serait évidemment beaucoup plus rapide à parcourir et à mettre à jour.

Je pense qu'une bonne lecture de ce que font les autres technologies de graphes de scènes vous apporterait de nombreux avantages.

Contexte
Par exemple, regardez la description d'Ogre3D. Il s'agit d'un moteur graphique basé sur un graphique de scène qui est open source. Je suggérerais de regarder les tutoriels et de voir comment les nœuds de scène sont utilisés (Remarque: je ne vous dis pas d'apprendre à utiliser Ogre, mais plutôt les fonctionnalités présentes dans les nœuds de scène et les gestionnaires de scène d'Ogre)

Documentation de SceneNode:
http://www.ogre3d.org/docs/api/1.9/class_ogre_1_1_scene_node.html

Documentation de SceneManager: http://www.ogre3d.org/docs/api/1.9/class_ogre_1_1_scene_manager.html

Quelque chose d'autre mérite d'être examiné est le lien suivant:
http://sgl.sourceforge.net/#features

Il s'agit d'une solution de graphe de scène basée sur OpenGL et la page des fonctionnalités présente tous les nœuds qu'elle peut contenir.

Vos nœuds suggérés
Je suis d'avis qu'un graphique de scène doit être aussi abstrait que possible de la logique du jeu afin que vous n'ayez aucun problème de dépendance. Pour chacun de vos points, je dirais ce qui suit:

Acteurs de jeu
Je dirais probablement non. Semblable à Ogre, j'aurais une classe d'entité de base (qui contiendrait la logique spécifique à l'objet) et un SceneNode de base avec un pointeur de membre d'entité pour obtenir les informations appropriées pour restituer l'objet (position, orientation, etc.)

EDIT: Je ne dis pas de ne pas inclure vos acteurs de jeu dans le graphique de scène ici (sinon rien ne s'afficherait: P) Je dis d'avoir un nœud de scène avec une référence à la classe d'acteur de jeu logique, donc vous avez encore un couplage lâche du rendu et de la mise à jour des objets du jeu.

Jeu statique simple ojbect
Oui

Déclencheurs de jeu?
Non, cela ressemble à une logique spécifique au jeu pour moi.

Lumières de jeu?
Oui

Caméras de jeu?
Oui

Balles d'armes?
Pas complètement certain à propos de celui-ci, mais je dirais probablement oui, mais vous voudriez probablement que toutes les puces soient des enfants vers un nœud de scène parent "BulletCollection", juste pour pouvoir mettre en cache cette position et vous n'aurez pas à traverser la graphique de scène beaucoup à supprimer et ajouter des puces à rendre.

Explosions de jeu et effets spéciaux?
Pas certain, je vais laisser quelqu'un d'autre répondre à cela.

Couverture du graphique de scène
Si vous avez un niveau relativement petit, vous devriez être en mesure de stocker le niveau entier dans un graphique de scène, puis d'optimiser la visibilité à l'aide d'un octree (généralement pour les environnements extérieurs) ou d'un arbre BSP (généralement pour les environnements intérieurs).

Si vous avez un niveau beaucoup plus grand et que vous ne voulez pas charger de niveau, c'est là que le streaming entrerait en jeu, mais c'est un autre problème. Je commencerais par un petit niveau et je verrais progressivement la taille que vous pouvez atteindre sans affecter les performances.

Conclusion
Pour moi, un graphique de scène correspond à la partie de rendu d'une boucle de jeu. Vous ne devez pas coupler trop étroitement votre rendu et vos mises à jour logiques, sinon vous allez rencontrer des problèmes de dépendance ennuyeux.

Mon inclination est de suggérer de mettre moins de choses dans un graphique de scène. Voir en particulier cet article de Tom Forsyth: " Graphiques de scènes - Dites simplement non ".

Le nœud de l'article de Forsyth est que vous ne devriez pas essayer de regrouper un tas de choses non liées dans une grande structure de données maîtres. Cela ressemble beaucoup aux idées que j'ai abordées dans cette réponse en ce qui concerne tout dériver du jeu GameObject, puis tout mettre dans une grande liste hétérogène (c'est-à-dire que c'est mauvais).

Relativement peu d'objets dans le monde présentent vraiment une forte relation parent-enfant comme il sied à une structure arborescente. L'exemple canonique d'une tasse de café sur une table est généralement utilisé ici - bien sûr, vous pourriez la considérer comme un «enfant» de la table ... au moins jusqu'à ce qu'elle soit renversée. Alors est-ce vraiment encore un enfant de la table? Cela signifie que votre «arbre» ​​peut finir par être assez peu profond et dégénérer en quelque sorte dans une liste.

Je vous suggère donc d'utiliser plusieurs structures de données pour plusieurs choses, comme c'est le plus logique pour ces choses. La géométrie statique et les lumières, par exemple, semblent être une chose raisonnable à insérer dans un graphique de scène. Même si les objets représentés n'ont pas de relations parent-enfant naturelles, le fait qu'ils soient statiques signifie que vous pouvez leur donner des relations parent-enfant structurelles sachant qu'ils ne changent jamais.

Acteurs de jeux ... Je n'en suis pas si sûr. Tout ce qui a tendance à bouger, en fait, signifie que vous devez généralement les garder près de la racine du graphique ou les re-parent en permanence (ce qui est une corvée et pas super efficace).

Balles, déclencheurs, effets spéciaux et autres objets transitoires que je stockerais ailleurs. Aucun élément de rendu ou de représentation visuelle (un déclencheur est généralement un volume englobant invisible, une puce n'est généralement qu'un lancer de rayons) ne doit pas figurer dans un graphique de rendu. Vous devez vous efforcer de séparer les couches de rendu et les couches logiques .

Pour ce que ça vaut, je n'ai jamais utilisé de graphe de scène en forme d'arbre dans aucun des moteurs de rendu que j'ai construits pour un usage non académique (évidemment, j'ai déjà construit des graphiques de scène en forme d'arbre essaie maintenant de vous faire accepter).

J'utilise des méthodes de partitionnement spatial qui sont appropriées au style de jeu (quad-tree, octree, BSP, et cetera) pour regrouper / supprimer les entités logiques dans le jeu qui devraient être (a) traitées cette trame et (b) rendues ce cadre. Je finis ensuite par alimenter l'ensemble des objets de la liste (b) dans un système qui mappe les objets logiques pour rendre les descriptions et trie ces descriptions dans des compartiments en fonction des propriétés (par exemple, tout ce qui utilise la transparence sera poussé dans le seau pour "trucs" qui doit être rendu en arrière-plan). Ensuite, je rends chaque seau dans l'ordre, et pour chaque seau rend chaque description dans l'ordre. Je suppose que vous pourriez appeler cela un "arbre", mais il ne présente pas l'état typique / transformer les méthodes de propagation que font les graphes de scènes arborescentes traditionnelles.