Discussion :

[BugFactory]

Bonjour,

Je viens de lire la documentation de ODE (Open Dynamics Engine). Un point en particulier a éveillé mon attention, et j'aimerais des précisions.

Quand on travaille avec ODE, le programme prend la forme d'une boucle ou on appelle

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

void dWorldStep (dWorldID, dReal stepsize);

ou

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

void dWorldQuickStep (dWorldID, dReal stepsize);

à chaque itération. Or, la documentation précise que stepsize doit être une constante, c'est à dire ne pas varier d'un appel à l'autre, faute de quoi on risque de faire trembler les objets (jittering). Source : http://opende.sourceforge.net/wiki/i...al_%28World%29.

Mais il me semble que l'intérêt de ce paramêtre, c'est de pouvoir s'adapter aux différents framerates qu'aura une application sur différentes applications, en donnant comme stepsize le temps passé à rendre une frame. Or ce temps est variable selon le cas (nombre d'objets à l'écran etc), y compris d'une frame à l'autre sur une même machine.

La solution serait à priori de donner un framerate constant à l'application en le forçant à attendre si une frame est rendue rapidement. Mais celà a plusieurs inconvénients:
- les propriétaires de machines lentes ne pourront pas utiliser l'application si son framerate a été fixé trop haut, même si elles auraient pu le faire tourner à un framerate inférieur,
- les propriétaires de machines rapides qui auraient pu faire tourner l'application à un framerate élevé n'en profiterons pas,
- on est obligé de choisir un framerate pour le pire des cas même si ce cas arrive rarement.

C'est plutôt embêtant. Ma question est donc de savoir si mon inquiétude est fondée ou est-ce que je m'inquiète pour rien?

[bafman]

rhaaa le time stepping de moteur physique discret, un vrai bonheur de prise de tête

en gros, il te faut fixer un timestep qui correspond à la finesse de simulation que tu souhaite. une fois ce time step trouvé (généralement par de merveilleux tests empiriques), tu peut très bien faire une boucle de ce genre ci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
 
pour chaque frame
    elapsedTime = previousElapsedTime + real elapsedTime
    tant que elapsedTime > timeStep
        faire un pas de simulation
        elapsedTime -= timeStep
    fin tant que
    previousElapsedTime = elapsedTime // on sauvegarde les quelques millisecondes
    // qui n'ont pas été consommée par le moteur physique

en gros, ca consiste tout simplement a decoupé ta frame en plusieurs pas de simulation physique si jamais le temps ecoulé est trop important... c'est en gros la solution basique pour régler ton problème, et en plus, si l'ordinateur est très rapide, les pas de simulations ne seront pas forcement fait à chaque frame, d'ou gain de calculs...

oui mais voila, cette solution à un gros problème, c'est que, comme souvent, on ne donne qu'au riches .
en gros, plus l'ordinateur va être rapide, plus la probabilité de faire un calcul physique sera faible, et inversement, plus l'ordinateur sera lent, plus la probabilité de faire le calcul physique sera élévé. Mais encore, si il n'y avait que ca, ce serait plutot suportable, mais en fait non, il existe un problème encore pire avec cette solution . dans le cas d'un ordinateur lent, la probabilité de faire un ou plusieurs pas de simulation est forte, et donc l'ordinateur va "perdre" du temps a faire des calculs, or ce temps perdu va encore augmenter le nombre de pas d'iteration du moteur physique à la frame suivante, on risque donc d'avoir une prochaine frame encore plus lente que la frame courante et ainsi de suite, jusqu'a ca que le moteur tombe a 0 FPS .
Une solution pour resoudre ce problème consiste à limiter le nombre de pas d'iteration par frame pour que le temps de calcul physique ne soit jamais superieur au temps d'affichage de la frame, mais du coup, on risque de perdre la synchro entre l'affichage et la physique, et, plus genant, le moteur se comportera differamment sur un ordinateur lent et sur un ordinateur rapide...

bref, faire un system de time stepping robuste, c'est loin d'être facile

[BugFactory]

Ca ne se voit pas mais je suis en train de pleurer là. Si on est trop gourmand, on fait passer le moteur physique plusieurs fois par frame ce qui gâche du CPU et si on ne l'est pas assez, on ne calcule la physique qu'une fois sur deux, ce qui fait que l'on rend deux frames identiques ce qui n'a aucun intérêt... Est-ce que tous les moteurs physiques (open source et gratuit y compris dans le cas d'une application commerciale) sont comme ça? Je vais jeter un oeil du coté de Bullet.
( Le wiki de Bullet est en panne!)

[bafman]

normalement, avec bullet, le problème est moindre grace aux detection de collision continue (les fameuses CCD), mais je n'ai personnellement jamais approfondit le sujet.
mais de toute façon, tu a tout interet a passer à bullet qui est bien plus evolué qu'ODE en terme de simulation paralleles, utilisation d'instruction SIMD et autres truc modernes
(par contre, c'est vrai que le site est en rade depuis 2 jours )

[BugFactory]

Je n'arrive pas à trouver de la doc sur Bullet. Connaissez vous une bonne adresse?

[bafman]

bah en fait, il n'y a juste pas de documentation pour l'instant sur bullet... tout se fait directement dans les exemples et dans la doc doxygen (pour le peut de commentaire qu'il y a dans les classes)

[BugFactory]

Youpi j'ai 0 expérience sur les moteurs physiques donc aucun problème pour improviser! Heureusement je n'en ai pas besoin pour tout de suite.

Merci pour vos réponses.

[bafman]

ne t'inquete pas, les moteur physique, c'est beaucoup plus simple à utiliser qu'à coder .
avec toutes les demo/exemples qui trainent sur le net, plus la doc d'ODE qui donne pas mal d'info interessante (même pour bullet ), tu peut t'en tirer au moins pour faire un truc de base. Apres, l'experience vient en codant