anyKode Marilou
ContentsIndexHome
PreviousUpNext
Accélérer la simulation

Accélérer la simulation.

Ce chapitre explique comment accélérer la simulation en optimisant la physique et la 3D. Dés lors que la nombre d'objets (physique ou 3D) ou de degrés de liberté augmentent, la resource processeur devient critique. Il en est de même pour la vidéo. Nous donnons ici quelques astuces pour optimiser la modélisation et ainsi créer des scenes plus larges et plus rapides. 

 

Optimisations 3D:

 

Utiliser des modèles 3D de qualité inférieure: 

Le temps de rendu d'un objet 3D est directement dépendant de son nombre de polygones. Il est conseillé d'utiliser MeshTool (ou un autre outils) pour réduire le nombre de triangles au minimum. L'objet 3D pourra être affiché plus rapidement. Également, la calcul de l'ombrage est fait à partir des triangles de l'objet : ce calcul sera d'autant plus rapide que l'objet est 'léger' en nombre de triangles. 

 

Utiliser la géométrie physique pour le calcul de l'ombrage: 

Si vous utilisez un mesh 3D (depuis un fichier) pour habiller une géométrie physique, il est préférable de cocher compute shadows sur la géométrie physique (nombre de triangles minimum) au lieu du mesh lui même (grand nombre de triangles): l'affichage du volume de l'ombre sera d'autant plus rapide. 

 

Ne pas calculer l'ombrage des petits objets: 

En général, l'ombrage généré par les objets de petite taille n'est pas d'une grande utilité dans le rendu 3D et consomme du CPU et de la vidéo. Il est préférable d'utiliser l'ombrage sur de gros objets comme les murs, les sols ou les grosses pieces des robots/objets. 

 

Ne pas utiliser la propriété 'generate dynamic shadows' (lumières) si ce n'est pas utile: 

Dans certains cas comme les LED ou les lumières à portée très courte, il n'est pas nécessaire de produire de l'ombrage. L'opération est coûteuse et le résultat est quasiment invisible dans l'image. 

 

Réduire le nombre de source lumineuse dans une même zone: 

Chaque objet est tracé dans la carte vidéo autant de fois que touché par une source lumineuse : chaque lumière apportant sa contribution. C'est à dire que si un objet est touché par 10 lumières, il sera envoyé à la carte vidéo 11 fois (10 lights + passe ambiante). 

 

Cacher les 'helpers': 

Dans Exec, il est possible d'afficher des 'helpers' qui donnent des indications sur la simulation: capteurs de distance, pression d'air, points de contacts etc. L'affichage de ces objets étant hors du processus de rendu 3D ils sont très consommateur de resources video. 

 

Optimisations physiques:

En General la physique consomme plus de CPU que la 3D ou les autres processus. Il est possible d'optimiser la physique, la configuration globale et les équipements embarqués pour accélérer la simulation. 

 

Interdire les fonctions qui ne sont pas requises pour le projet: 

Dans le cas général, une fonctionnalité active consomme plus de temps CPU qu'une autre désactivée ! Par exemple: l'effect gyroscopique, les couples/forces résistifs, ressorts, limites sur les axes etc. ne consomment pas de CPU s'ils ne sont pas actifs. Il est important de ne pas rajouter des 'effets' à la simulation s'ils n'ont pas ou peu d'importance pour votre projet. 

 

Réduire le nombre de points de contact: 

La complexité de la simulation (et donc sa vitesse) est directement dépendante du nombre de degrés de liberté au carré: pow( DOF , 2). DOF est le nombre d'axes utilisés dans la simulation + le nombre de points de contact créés dynamiquement dans un incrément de temps. Cela signifie qu'il faut prendre garde au nombre de points de contact. Par exemple un boite posée sur une autre boite peut générer jusqu'à 12 points de contacts (+12 DOF). 

 

  • Utiliser contacts management (depuis les propriétés physique de l'objet): il est possible de limiter le nombre de points de contact qu'une géométrie est autorisée à créer dans une situation donnée. Par exemple les pieds d'une table (boites) génèrent, par défaut, 3 contacts par pied = 12 DOF. Il est intéressant de limiter (pour chaque pied) le nombre de contacts à 1. La table reposera ainsi sur 4 contacts (4 DOF), ce qui est largement suffisant pour la stabiliser et moins consommateur de CPU.
  • Utiliser l'AutoDisable (depuis les propriétés du corps rigide): lorsque le corps rigide est stabilité (vitesses <= à un seuil), celui-ci n'entre plus en compte dans la résolution du système ce qui a pour effet immédiat de réduire le nombre de DOF. (note: il faut autoriser cette fonctionnalité dans la Configuration->physics).

 

Utiliser la propriété kinematic des corps rigides. 

Les calculs effectués pour un corps rigide en mode kinematic (statique) sont plus rapides que ceux effectués pour un corps dynamique. Si l'objet n'a pas vocation à se déplacer il est préférable de le passer un mode kinematic. Par exemple un mur, un bâtiment, un robot vissé au sol. Non seulement les calculs sont plus simples mais ces objets, dont la position est figée, sont aussi plus stables. Ainsi, toute la chaîne de jointures qui part d'un corps rigide kinematic est aussi plus stable. Ce mode est plus stable et plus rapide que l'utilisation d'une jointure statique connecté à l'environnement statique (qui rajoute 1 DOF). 

 

Disable les devices non utilisées: 

Il est préférable de Disable un équipement embarqué non utilisé: Exec l'ignorera au démarrage de la simulation. Un équipement qui est Off ou AutoOn est mis à jour par le système comme un équipement en mode On. En général les modes Off et AutoOn consomment beaucoup moins de CPU que le mode On mais en consomme quand même. 

 

Réduire le frame rate (3D): 

Par défaut, le rendu 3D est effectué toutes les 30 ms simulées. Dans certains cas ce taux de rafraîchissement peut ralentir la physique et il est préférable de passer à 50ms voire 100ms:

  • Les ordinateurs à 1 seul processeur: Marilou est bâti sur une architecture multi-processeurs qui sépare la physique et les calculs 3D. Si 1 seul processeur est disponible, le rendu 3D fonctionne au détriment de la physique.
  • Utilisation des caméras: La mise à jour d'une caméra, commandée par le process physique, est synchrone avec l'affichage 3D: en d'autres termes une caméra ne peut pas calculer son image tant qu'un rendu 3D est en cours ce qui a pour effet immédiat de faire perdre du temps à la physique (limitation de DirectX).

 

Globalement: Il faut cocher 'Exec->Settings->Allow render time to shift' pour autoriser Exec à supprimer certains rendus (redonne du souffle à la physique) et, si ce n'est pas suffisant, baisser le frame rate. 

 

Utiliser la méthode Iterative pour la résolution du système physique (configuration->Physics): 

Marilou propose deux méthodes pour résoudre le système physique (ODE): la méthode solver (lente mais précise) et la méthode itérative (plus rapide et moins précise). 

Documentation v4.7 (18/01/2015), Copyright (c) 2015 anyKode. All rights reserved.
What do you think about this topic? Send feedback!