Salut,
 
Vous connaissez peut être le livre "Physics for game developers" des éditions O'REILLY?
Savez-vous s'il existe une traduction en français de ce livre?
 
Merci.

 
de rien

Can i has a cheezburger?    
 
Plus sérieusement, j'attends une vraie réponse.

Tu as de très bon sites sinon qui traitent de ce problème (www.euclideanspace.com par exemple), tu as aussi les cours en ligne du MIT.

Et c'est pour faire quoi sinon, redévelopper ton propre moteur de physique ou en utiliser un déjà existant ? Parce que le bouquin en question, il n'est vraiment utile que dans le premier cas. Dans le second, l'usage des libs comme Vortex ou Havok est très simple et intuitif, et ne demande que peu de connaissances...

De toutes façons, dans ce domaine, le pb le plus chiant, c'est pas le moteur et la prog de la physique, mais c'est d'utiliser des modèles 3D "propres" pour tes objets.

C'est pour le premier cas.
Je rêve depuis longtemps de me faire mon propre moteur physique 2D    
Puis peut être faire un petit jeu avec, ou faire des simulations, faire un truc du genre working model (excellent ce soft).
 
Je vais voir tes liens

 
Franchement, pour un moteur physique 2D, si c'est juste pour la dynamique, il n'y a pas grand chose... Pas besoin du bouquin dont tu parles, c'est un peu le tank pour tuer la mouche.
 
Veux tu faire juste de la gestion de dynamique avec collisions, ou en plus avec des liaisons cinématiques entre solides ? Que des corps solides ou également des déformables ?

Ben en fait j'aimerais y aller progressivement.
D'abord j'implémente la gravité, ensuite la détection des collisions, la rotation, la friction, etc  
Mettre le plus de chose possible avec de la déformation, si possible.
 
Par contre je comprend pas ce que tu veux dire par "ou en plus avec des liaisons cinématiques entre solides"

"Ca dépend."
 

Pour la gestion de dynamique descorps solides, tu as classiquement 3 trucs à développer:

- 1) La gestion de la dynamique -> tu donnes en entrée des forces qui s'appliquent à tes objets en un point, et en sortie, tu as la nouvelle vitesse et la nouvelle position de ton objet (3 valeurs à chaque fois : 2 valeurs pour la position 2D, et une pour la rotation). Il s'agit ici simplement d'appliquer le PFD, et de faire une intégration pas trop conne (cf. les différents intégrateurs: implicite, explicite, semi-implicite, runge-kutta... etc).

- 2) La gestion des collisions -> 2 phases:
 a) détection de collision: ça peut prendre beaucoup de temps, ça passe par des optimisations du style partitionnement d'espace, boites englobantes, etc... mais en 2D, je ne pense pas que toutes cesoptimisations soient très utiles.
 b) résolution: génération de forces pour "sortir" de la collision, ya plusieurs méthodes. C'est notamment ici que tu génères également les forces de frottement, la réaction au plan, et les forces qui s'appliquent à tes objets qui sont entrés en collision, fonction d'un "coefficient de rebond" par exemple, Le mieux je pense est que tu regardes sur le site euclidean space, ce qui est dédié à la résolution des collisions en 2D : http://www.euclideanspace.com/phys [...] /index.htm

- 3) La gestion des liaisons cinématiques et assimilé. Enfin en 2D, il n'y en aura que 2: pivot, glissière... + éventuellement un "ressort". Spa trop dur.

Et enfin, pour les déformables, il y a plusieurs façons de modéliser ça: des "réalistes" et des "rapides" comme d'hab

 
Ca a pas l'air facile    
Sinon tu connais pas un livre pour ça? (en français si possible)

Fausse manip

 
Non, mais c'est vraiment pas compliqué... Enfin ça dépend, tu en es où niveau études, connaissances en méca tout ça ? Parce que si tu es au collège effectivement, c'est sans doute un peu tôt pour t'attaquer à ce genre de pb en comprenant bien tout, mais en première ou term S, tu sais pratiquement tout ce qu'il faut déjà il me semble.

Term S, on connait pas tout à ce niveau.
Rotation, je connais pas.
Frottement non plus.
Déformation encore moins.
Elasticité, etc...
 
Pour l'intégration je pense utiliser Euler, c'est la plus simple, mais vive la précision quoi...  
 
Et puis je veux éviter d'y aller comme ça.
Faire un code monstrueux, pas du tout optimiser.
 
En plus il me faudra un moteur graphique pour afficher les objets ect, nan?

 
Bah déjà, occupe toi de faire un moteur physique qui marche et "pas du tout optimisé", c'est formateur. Pour l'optimisation et le temps-réel on s'en fout. Le but, c'est d'apprendre, pas de faire un truc efficace et compliqué, sinon, si ton but c'était d'avoir un truc efficace et optimisé, ben il suffirait de taper dans les moteurs de physique tout faits, déjà optimisés et très efficace. Ya ODE (Open Dynamics Engine) par exemple dans le genre, en openSource. Vu ce que tu as l'air de connaître déjà, c'est trop ambitieux de vouloir essayer de faire un truc qui marche et en plus optimisé, from scratch. C'est un peu le syndrôme des gens qui débutent en prog, ils veulent s'y mettre, et réussir direct un projet super optimisé. Bah non, l'apprentissage, ça se passe petit à petit, par des essais, des erreurs... etc.  
 
Donc en gros:
* soit tu veux le faire "tout seul": et dans ce cas là, bah, faut accepter de faire un truc à la main, pas du tout optimisé, à partir de tes connaissances en méca ou de connaissances à acquérir par toi-même sur le sujet, puis, éventuellement, d'optimiser ensuite.
* soit tu veux "recopier" un truc déjà optimisé et développé par quelqu'un d'autre. Ce qui n'a que peu d'intéret, c'est juste faire de la dactylo quoi, donc autant utiliser directement une lib de gestion de la physique comme ODE.
 

 
Oui mais ça tu vas pas te le retaper à la main, utilise les lib OpenGL par exemple. Ou en 2D, un truc comme Allegro...

Ouais, je vais essayé de faire ça, avec SDL.
Pour l'instant j'ai pas trop le temps.