Discussion :

[zenux]

Bonjour,

J'aimerais créer un moteur physique 3D assez basique.
J'ai lu quelques articles sur Internet et j'ai essayé de comprendre le code source du moteur Bullet (pas facile ). Je me pose deux questions:

Structure:
J'aimerais executer la simulation physique dans une thread autre que celle du rendu 3D afin d'utiliser mon CPU de façon optimale. J'ai pensé à deux façons de faire:
* Au début de ma boucle de rendu, je réveil ma thread physique pour faire un step de simulation physique. A la fin de mon rendu, je récupère les nouvelles positions/orientations calculées par la thread physique (une fois terminé) afin de les utiliser au prochain rendu.
Désavantage: si mon step de simulation physique est très lent, il risque de faire descendre mon framerate de rendu.

* Avoir une thread de simulation physique qui calcule toutes les x millisesondes un step de simulation physique. A chaque boucle de rendu: on va lire les dernières positions/orientations calculées par la thread physique (avec utilisation des mutex pour éviter les accès concurrents).

Y a-t-il une solution meilleure que l'autre et si oui: pourquoi ?

Performance:
Sur Internet, on peu lire dans pratiquement tous les articles qu'il faut exécuter un step de simulation physique environ 60 fois par seconde pour éviter qu'un petit objet à pleine vitesse traverse un mur.

Est-ce vraiment la solution idéale en terme de performance ?
Si on connait la taille de l'objet et sa vitesse: on peut facilement déterminer à quel fréquence il faut exécuter les calcules de physiques, non ?
Je me doute bien que ça se complique quand on a deux objets qui bougent en même temps.
Qu'en pensez vous ? Existe t-il des algorithmes pour ce genre de problème ?

Merci d'avance.

[pyros]

Salut,

Y a-t-il une solution meilleure que l'autre et si oui: pourquoi ?

Je dirais la 2ème solution. Réveiller un thread est "très" long (plusieurs ms). Alors que si ton thread tourne en permanence, tu as juste à la bloquer avec un mutex (voir même un spinLock, mais à utiliser prudement). De plus, la boucle physique est généralement désinchronisée de la boucle de rendu et est aussi plus rapide (jusqu'a plusieur dizaines de step physique pas frame):
Si ta boucle physique est synchro avec ta boucle de rendu, tes résultats vont varier en fonction de ton affichage. Par ex., dans une scène visuellement très lourde à quelque fps, tes objets risques de traverser les murs. Problème que tu n'a pas avec un boucle physique non synchrone (à moins de mettre ton CPU à genoux )