Bien interpreter les outils de mesures "Framerate and profile"

Répondre
Avatar du membre
Redstar
Super Modérateur
Messages : 21
Enregistré le : jeu. avr. 05, 2018 10:47 am

Bien interpreter les outils de mesures "Framerate and profile"

Message par Redstar » mer. mai 09, 2018 3:09 pm

Bonjours à toutes et à tous,

Quand vous développez votre jeu, il peut arriver que celui-ci soit plus gourmand et plus lent que prévu, car vous ne faites pas attention à ce détail quand vous débutez dans le développement d'un jeu vidéo. C'est normal, puisque vous apprenez à utiliser les outils que vous avez en main !

Dans le BGE, il existe un outil, durant le mode jeu, qui permet de savoir si votre jeu est optimisé ou non. Ce tutoriel va vous expliquer en détail chacun de ces processus afin que vous puissiez savoir où optimiser. Le comment a déjà été expliqué dans ce topic. Je n'en parlerai que très brièvement ici.

Tout d'abord, la moindre des choses est d'afficher ces statistiques.

Ensuite, quand vous lancez votre jeu, vous allez voir ceci, en haut à gauche de votre fenêtre 3D.

Avant de commencer:

La première chose à savoir est que moins le temps d’exécution (ex:1.6 ms) est élevé, mieux c'est. Ça veux dire que votre jeu est optimisé ou la catégorie s'y rapportant n'est pas trop longue à s’exécuter.

Le process Frametime:

Ce process est important: c'est le résultat final du bon fonctionnement de votre jeu. Il est influencé par plusieurs process (que j'expliquerai plus bas) et peut varier de temps en temps. Une chose à savoir, sur le moteur Unreal Engine, la valeur des frames est de maximum 120 fps, sur le BGE, c'est 60 (sauf si je me trompe, la fréquence d'affichage des écrans est en moyenne à 60 hz, je ne pense pas que ce soit une coïncidence).

Fps signifie Frame Per Second, soit Images Par Seconde. Cela signifie que votre écran affiche 60 images en une seconde (que votre personnage bouge ou pas). C'est tellement rapide que notre œil voit que c'est fluide, contrairement aux appareils photo/camera ou l'on voit des espèces de vagues sur les écrans.

Ne vous inquiétez pas de la différence de la valeur, je rappelle que dans les outils de mesure de framerate, on est limité a 60 fps aussi. Gardez donc en tête que ce process (frametime, donc) est à observer avec attention.

Le process Physic:

Ce process est très important. Le process Physic concerne tous les objets de votre scène, ajouté indirectement ou non avec une propriété physique. Plus vous avez des objets avec des collisions, plus le moteur doit faire des calculs. Pour diminuer le temps de calcul, vous devez simplifier au maximum la physique de l'objet. Voici un exemple:

Un grand bâtiment avec pleins de détails, avec les fenêtres, les appuis de fenêtres, les pylônes de béton, les paraboles satellite, etc. contient beaucoup de faces et ces faces doivent donc avoir une collision, car la propriété physique de ce bâtiment est le mode static. Sauf que, vous ne devez nécessairement pas accéder à tous les étages. Dans ce cas, pourquoi faire calculer tout le bâtiment plutôt que de faire calculer les zones désirées ?

Donc, vous allez devoir créer un mesh invisible de votre bâtiment avec les endroits où vous voulez accéder et le reste sera que de grandes faces sans détails. Votre bâtiment avec détails sera relégué en tant qu'objet sans collision.

Selon certains cas, vous pouvez aussi simplement créer un proxy de votre objet, c'est à dire que Blender peut générer une forme fantôme qui fera la collision plutôt que le mesh entier.

Le process Logic:

Ce process est à surveiller absolument car il contient plusieurs facteurs:
  • Il englobe tout vos objets présent dans votre scène, quel que soit leur propriétés physiques
  • Il prends en compte les scripts python et les briques logiques lancés en boucle.
Par exemple, les senseurs radar et near, en grand nombre, au même moment, peuvent impacter sur les performances.

Si vous réalisez un terrain assez vaste (pas un open world, soyez raisonnable), vous allez disposer plein d'objets décoratifs et des objets clés. Tout ces objets on un coût pour le process logic (ils ont chacun leurs physiques et leurs positions), il doit les prendre en compte. Pour éviter cela, le mieux est d'utiliser les groupes d'instances ou de fusionner le tout en un seul et gros objet.

Les groupes d'instances permettent de "fusionner" partiellement vos objets pour en avoir un seul. C'est pratique quand vous voulez gagner du temps pour construire votre terrain, aussi. Mais parfois, cela ne suffit pas. Alors, l'idéal est de fusionner physiquement tout vos objets en un seul et unique objet, qui contiendra tout vos mesh.

Avantage de cela ? Un seul objet qui contient toutes les collisions est plus simple à calculer que 100 objets avec des collisions différentes. N'oubliez pas qu'il faut simplifier les objets décoratifs en créant des "enveloppes" très simples et cubique, comme mon exemple du bâtiment.

Le process Animation:

Ce process est à surveiller à condition que vous ayez beaucoup d'armatures complexes (pour un personnage, par exemple).
Le process animation englobe les os animés de votre armatures. Plus vous avez de personnages avec des armatures complexes, plus le process va être lourd et votre jeu sera ralentis.

Dans le cas des personnages, l'idéal est de faire le moins d'os possibles. Si ce n'est pas possible, il faut alors penser à désactiver les armatures alentours qui sont trop loin de votre vue. Ainsi, vous gagner en performance et ces armatures sont sollicitées qu'au moment ou vous en avez besoin.

Vous pouvez aussi envisager de faire les animation via déformation de votre personnage (shapekeys) mais c'est très compliqué à faire si celui-ci est complexe point de vue forme.

Le process Network:

Il est possible de créer des jeux en réseau avec le BGE (pas un World of Warcraft, soyez raisonnable). Ce process prends en compte les messages envoyés aux autres objets durant le jeu. Si vous en envoyez trop d'un coup, ce process ralentira. Je n'ai pas expérimenté ce domaine donc je ne peut pas en dire beaucoup pour le moment.

Le process Scenegraph:

Ce process concerne la gestion des déformations par armature, le positionnement des objets et l'occlusion culling. L'occlusion culling est le fait de cacher les faces/objets qui sont masqué par d'autre faces/objets. Ce process n'est pas très important.

Le process Rasterizer:

Ce process est à surveiller pour les terrains très chargés en matière de décoration.

Ce process concerne en grande partie le visuel, ce que vous avez à l'écran. Il concerne aussi les matériaux utilisés, les faces, les shaders, les sources de lumières et les ombres. Le seul conseil que je peux donner ici est de ne pas être trop généreux en nombre de face, surtout éviter les faces inutiles, pas trop de sources de lumières et pas trop d'ombres dynamiques. Utilisez aussi le format de texture adéquat (voir topic optimisation).

Le process Services:

Il prends en compte les périphériques tel que le clavier, la souris et les manettes de jeu. Pas intéressant à surveiller.

Le process Overhead:

Ce process n'est pas intéressant à surveiller.

Il concerne simplement les messages d'états tel que le frametime (que vous avez activé) et les débugs des propriétés des objets (tel que time, float, int, etc.). Sauf si vous devez tester toutes les propriétés de vos objets, il n'y a rien de spécial à faire.

Le process Outside:

Cela concerne la mémoire allouée à Blender durant le jeu. Si la valeurs est élevée, fermez les autres applications.

Le process GPU Latency:

Pas très intéressant. Cela concerne le temps que la carte graphique (GPU) doit attendre avant de recevoir et traiter l'information donnée par votre processeurs (CPU). C'est à dire que, en informatique, le processeur (CPU) est le cerveau de votre machine qui calcule tout (et n'importe quoi), il envois les informations vers le processeur de votre carte graphique (GPU), en passant par la mémoire (RAM).

Pour faire simple, c'est comme si vous aviez un mathématicien et un artiste qui travaillent ensemble. Quand un patauge un peu dans sa tâche, l'autre attends.
"Celui qui ajoute de nouvelles connaissances aux anciennes est le véritable enseignant." - Confucius.

Avatar du membre
keltwookie
Admin du site
Messages : 68
Enregistré le : mer. avr. 04, 2018 5:42 pm
Localisation : Kashyyyk
Contact :

Re: Bien interpreter les outils de mesures "Framerate and profile"

Message par keltwookie » lun. mai 14, 2018 3:15 pm

Je viens de relire l’article et :… En voilà de l’information qu’elle est intéressante… :D

Oui. dès que ça parle optimisation, je suis preneur, a fortiori quand il s’agit d’un moteur de jeu :). Et même si ce topic sois dédié au BGE, je me suis permis (@Redstar : J’espère que tu ne m’en voudra pas) ci-dessous quelques analogies, explications et questions.

Concernant le « frame rate » ou « Frame Time » :

Pour étayer ce qu'il y est dit, les explications complètes:
https://www.journaldugeek.com/2014/10/1 ... esolution/

Et puis tant qu’on parle d’affichage, un article très intéressant sur le taux de rafraîchissement des écrans :
http://www.gamblewiz.com/s/taux-de-rafr ... trop-lent/

Certes, ça parle de TVs, mais les jeux modernes utilisent de plus en plus la HD.

Et toujours concernant l’affichage, il faudra qu’on parle de LOD (Level of Details) aussi, un de ces quatres …

Les Physics Process :
Pour diminuer le temps de calcul, vous devez simplifier au maximum la physique de l'objet
Oui, c’est valable pour tous les moteurs.

C’est pour cela que quand on fait une forme de collision. On suggère généralement de dupliquer « grossièrement » l’objet en premier lieu, ou carrément de recréer un approximation de l’objet. Si je ne me trompe, avec Blender, la manip est plutôt aisée :)
Mais pour la suite, et donc la gestion, chaque moteur procède apparemment différemment.
Avec le BGE, on utilise un mesh fantôme. Approche intéressante, je ne connaissais pas le concept.
Dans un autre exemple avec Godot, on importerait le mesh « grossier, puis on l’assignerais à un noeud CollisionShape auquel on associerais le script « qui-va-bien » (ça demande confirmation, mais ça doit être un truc du même genre)… Et hop, roulez jeunesse !
Comment ça se passerait avec le BGE ?
Un grand bâtiment avec pleins de détails, avec les fenêtres, les appuis de fenêtres, les pylônes de béton, les paraboles satellite, etc. contient beaucoup de faces et ces faces doivent donc avoir une collision, car la propriété physique de ce bâtiment est le mode static
 
« Static bodies » ? Tiens, tiens, un terme familier sous Godot. Pour explication : Terme générique incluant les objets non-animés, logiquement moins gourmand que les « kinematic bodies », c’est à dire, les objets animés.
(Je pense toujours créer un wiki + lexique dédié aux arts numériques, mais j’aurais besoin d’aide …)
… est d'utiliser les groupes d'instances ou de fusionner le tout en un seul et gros objet.
Oui, Il est toujours recommandé d’instancier (cloner) ces objets (que ce soit avec Blender, le BGE ou un autre moteur) plutôt que les répéter, mais d’après ce que tu dis, et avec un peu de jugeote, on pourrait créer des formes de collision complexes et donc, beaucoup plus précises sans forcément trop augmenter la consommation de ressources. J’ai bon ?
Reste à savoir si ces instances sont exportables… Va falloir poser la question.
Si je demande, c’est parce que je suis en plein dedans … :D

Animation Process:
Ce process est à surveiller à condition que vous ayez beaucoup d'armatures complexes (pour un personnage, par exemple).
Petit conseil :
Si votre œuvre est à destination d’un autre moteur de jeu que le BGE, jouez la simple avec Blender dans un premier temps. Les animations complexes (ex : personnages + tout les mouvements imaginables) sont à réserver pour cet autre moteur, celui-ci ayant sûrement une manière différente de gérer ces animations.


Network Process :

Oui, d’après le peu que j’en sais, la pile « réseau » du BGE n’est pas conçu pour les modes «massivement multi-joueurs ». Dans ce cas, il faudra se tourner vers un autre moteur (je vais pas donner de nom, on m’accuserait d’être bassement corporatiste :D ) .

Pour les autre sujets, ils seraient non moins intéressants, mais à développer dans le cadre d’une « anatomie d’un jeu vidéo » (à voir?).



Encore une fois, article fort intéressant, merci !
- Le projet"XPlore"
- Tutos Blender
- Tutos Godot Game Engine

“ L'artiste est un malade qui essaie de se soigner en créant, mais plus il se soigne, plus il est malade. Et plus il est malade, plus il est content, vu qu'il n'a aucune envie de guérir." Philippe Geluck

Avatar du membre
Redstar
Super Modérateur
Messages : 21
Enregistré le : jeu. avr. 05, 2018 10:47 am

Re: Bien interpreter les outils de mesures "Framerate and profile"

Message par Redstar » lun. mai 14, 2018 8:33 pm

Toutes infos supplémentaires est la bienvenue, keltwookie.

Le LOD est similaire pour tous les moteurs de jeu. Mais c'est un sujet à faire à part.
Comment ça se passerait avec le BGE ?
Le mesh "grossier" devrait être mis en "convex hull" ou "triangle mesh" pour prendre en compte les membres, etc. Tant que ça concerne le joueur, je pense que ça ne mange pas de pain.

Une idée intéressante. Je testerai un jour, c'est peut-être ainsi que les jeux vidéos font pour passer des obstacles quand on est accroupis :)
...mais d’après ce que tu dis, et avec un peu de jugeote, on pourrait créer des formes de collision complexes et donc, beaucoup plus précises sans forcément trop augmenter la consommation de ressources. J’ai bon ?
J'ai des doutes. Pour le savoir, il faudrait mettre tout ce qui est censé être visible comme invisible pour voir comment ça se comporte côté Rasterizer et logic.
Reste à savoir si ces instances sont exportables… Va falloir poser la question.
De Blender à Blender, oui, sinon, pour un autre moteur, aucune idée.

Surtout pour les conventions de nommage des bones :roll:
Oui, d’après le peu que j’en sais, la pile « réseau » du BGE n’est pas conçu pour les modes «massivement multi-joueurs ».
Non, loin de là, mais il faut être créatif :)
mais à développer dans le cadre d’une « anatomie d’un jeu vidéo »
Ça fait beaucoup si l'on prends au cas par cas... Je pense qu'une vidéo qui analyse un style, les choix des dév', etc, est largement suffisant. "Merci Dorian" le faisait, ça, quoi qu'on en dise sur la qualité.
"Celui qui ajoute de nouvelles connaissances aux anciennes est le véritable enseignant." - Confucius.

Avatar du membre
keltwookie
Admin du site
Messages : 68
Enregistré le : mer. avr. 04, 2018 5:42 pm
Localisation : Kashyyyk
Contact :

Re: Bien interpreter les outils de mesures "Framerate and profile"

Message par keltwookie » lun. mai 14, 2018 9:45 pm

Le LOD est similaire pour tous les moteurs de jeu. Mais c'est un sujet à faire à part.
Oui, bien d’accord, on abordera cela ailleurs :yes: (ainsi que les focales des caméras ? ;) )
...Le mesh "grossier" devrait être mis en "convex hull" ou "triangle mesh" pour prendre en compte les membres, etc. ...
 ...De Blender à Blender, oui, sinon, pour un autre moteur, aucune idée."

Surtout pour les conventions de nommage des bones 
Héhé, oui, je me doutais d’un truc comme ça.
J’ai quand même regardé la doc Godot et j’ai aussi posé la question sur le forum des devs, apparemment, je peux instancier à l’envie, mais pour l’export/import et la gestion en ressources, pas d’infos précises, çà viendra peut être plus tard. En fait, j’ai l’impression qu’il ne faut surtout pas que j’instancie depuis Blender, et dans mon cas, il doit servir à deux choses dans l’absolu : la modélisation, et l’habillage (textures), point. Ou alors, des animations et rigging ultra-simples.
Tout le reste, je dois le faire dans le moteur. Je pense que ce doit être à peu près pareil pour les autres (Unity, Unreal,…). Oui, en y réfléchissant un peu, tout le monde n’utilise pas les mêmes moteurs de rendu ! Et quand aux animations, c’est clair, chacun a ses nomenclatures, processus, etc....
Ah tiens, en voulant poser la question sur le forum des devs Godot, je suis tombé la dessus (Merci à Calinou !) :

https://cgmasters.net/free-tutorials/wh ... #Resources

Je l’ai « marque-pagé » direct celui là ! :D


Edit: Suite à ce sujet un peu particulier, j'ai ouvert un autre topic ici:
[Test] Exports collisions, et instances

Non, loin de là, mais il faut être créatif
Je vois… mais dis moi, le Python n’a il pas été créé, à la base, comme langage de script pour les serveurs ? ;) … A vérifier bien sûr.
Merci Dorian" le faisait, ça, quoi qu'on en dise sur la qualité.
Un lien peut être?...
- Le projet"XPlore"
- Tutos Blender
- Tutos Godot Game Engine

“ L'artiste est un malade qui essaie de se soigner en créant, mais plus il se soigne, plus il est malade. Et plus il est malade, plus il est content, vu qu'il n'a aucune envie de guérir." Philippe Geluck

Avatar du membre
Redstar
Super Modérateur
Messages : 21
Enregistré le : jeu. avr. 05, 2018 10:47 am

Re: Bien interpreter les outils de mesures "Framerate and profile"

Message par Redstar » mar. mai 15, 2018 6:31 pm

Les vidéos sur "Merci Dorian"
mais dis moi, le Python n’a il pas été créé, à la base, comme langage de script pour les serveurs ?
Je suis pas un expert en python. Beaucoup m'ont dit que, côté réseau, c'est un très bon langage, en effet. C'est vrai qu'à y penser, dans certains jeux, j'arrive à apercevoir "activation du module python" ou un texte similaire.
"Celui qui ajoute de nouvelles connaissances aux anciennes est le véritable enseignant." - Confucius.

Répondre