en fait il faut déjà expliquer ce qu'est la physique d'un jeu.
donc grosso merdo:
bon ton jeu il manipule des objets 3D: véhicules: avions, voiture, vaisseaux & objets statiques: arbres, décors (ruines, pièces, meubles), terrain.
la partie physique actualise la position & autres états physique de tout ce qui est dynamique, en fonction du reste et de ce qu'on impute aux objets comme forces.
en gros la boucle générale d'un jeu (moderne) est: (un peu dans le désordre)
1) prise en compte des actions du joueur (clavier/souris)
2) prises de décision de l'IA
3) gestion de la logique de jeu (bouton pressé->pont qui s'abaisse, niveau de dégats de véhicules trop haut => explosion du véhicule)
4) imputation d'actions physiques aux objets 3D en fonction de 1/2/3, et évolution de l'ensemble du monde
5) rendu du monde en 3D, actualisation audio
=> retour au 1) pour l'image suivante
le 5), soit le rendu 3D prends actuellement, et généralement au moins 50% du temps par image.
le 4), c'est ce dont on parles, l'accélération du moteur physique par un chip dédié.
donc comment ça marche ?
grosse modo un moteur physique, tu lui donne la géométrie de ton objet (carosserie, fuselage), ainsi que ses propriétées physiques newtoniennes:
- masse
- centre de gravité
- moment d'inertie
(nota que pour les objets définis comme statiques, pas besoin de ces infos, juste la géométrie suffit.)
aussi un objet peut être une arborescence d'objets indépendants liées....
tu définis donc chaque objet, et la liaison mécanique entre chaque. (degrés de liberté en mécanique).
après une fois ça connu, du 1),2),3) viennent les actions sur tes objets:
- force + point d'application de la force
- ou directement couples
- ou directement nouvelle position forcée
/cours de physique/méca express:
grosso merdo, d'après newton, le principe d'inertie c'est quand un objet a une certaine vitesse, il la garde pour l'eternité tant que rien n'agit sur l'objet (valable aussi pour la rotation).
ensuite ce qui est contant sans actions extérieures sur le l'objet c'est la vitesse linéaire et angulaire.
ce qui va faire varier la vitesse de ton objet, c'est les forces donc:
alors en fait, l'accélération d'un objet c'est a=f/m (f=ma), c'est dire c'est la force appliqué qui fait accélérer l'objet, mais plus il est lourd plus il accélera doucement. (le freinage = accélération négative).
donc quand tu as pour chaque objet:
- son centre de gravité
- sa masse
- son moment d'inertie
et que tu appliques:
- une force a "un point donné"
l'ensemble te permet de calculer:
- l'accélération linéaire de ton objet, impliquant:
a) la force
b) son point donné
c) le centre de gravité de l'objet (si la force ne passe pas par lui, elle fera moins accélérer)
d) la masse (qui est la résistance au mouvement)
si tu repiques sur l'electricité: (anlogie à l'arrache)
a=f/m (accélération = force / masse)
et bin ça donne:
i=u/r (courant = tension / résistance)
- et de nouveau l'ensemble te permet de calculer l'accélération angulaire, en fonction de:
a) la force
b) son point donné
c) le centre de gravité
d) le moment d'inertie (qui décrit la résistance angulaire)
/cours de physique express terminé
donc une fois que tous les objets ont leur vitesse d'actualisée dû aux accélérations (positives ou négatives) provoquées par les forces appliqués,
il faut actualiser la position et savoir si où on est c'est confortable.
donc le moteur actualise les positions/orientation des objets, en fonction du temps passé lors de l'image précédente.
ie si le jeu est 100fps, alors par image le moteur physique doit l'évolution des objets pour 1/100ième de seconde.
... puis testes les objets les uns contre les autres pour savoir si ils se sont cognés.
si ils se sont cognés il faut répondre à ce choc de manière censée.
hors là des problèmes peuvent aparaitres: si le temps d'évolution du monde est trop grand, et/ou les vitesses d'évolution des objets sont aussi trop grandes, les objets peuvent se pénéter de plusieurs mètres, voir se croiser sans avoir de collision de détectée !!!!
image deux avions de chasse à mach 1 => 330m/s
donc la distance entre les deux avions se réduit à 660m/s
si on est à 100fps, soit 1/100s, l'écart entre les deux objets se réduit par tranche de 6.6m.
ce qui peut causer des sacrées blagues de gameplay.
pour ça, on appliques des techniques, dont l'une d'elle et de tout simplement réduire le "pas" de simulation, ce qui fait que par exemple, pour toujours 100fps, soit 1/100s, donc 10ms, le moteur au lieu de faire ces 10ms d'un coup, va faire 10 étapes de 1ms.
ce qui fait que l'ecart entre nos deux avions passe à 0.66m, ce qui est déjà mieux.
problèmes => le temps de calcul est potentiellement multiplié par 10.
---
ensuite, façe aux collisions, il faut ensuite savoir "comment" répondre, et ce en accord avec la logique de jeu.
est-ce que tu faire exploser l'objet ?
est-ce que l'ensemble du moteur du jeu est capable de gérer les démenbrements/éclatements localisés des modèles ?
est-ce que tes objets sont élastiques, va-t-il y avoir un rebond (rebond qui va générer une force et agir sur les objets impliqués) ?
est-ce que les objets qui se rentrent dedans le fond à basse vitesse et raclent alors l'un sur l'autre (en générant une friction qui étant une force, va a son tour agir sur les objets) ?
est-ce qu'en fait on est dans un cas d'adhérence, et le objets vont rester collés de manière statiques l'un à l'autre ?
(ndlr: dans les attributs de la simulation, il a aussi l'accélération gravitionnelle commune à tout le monde qui est définie par la logique de jeu)
---
valà en gros a quoi aide la carte physique.
en fait c'est plustôt la réponse à "c'est quoi une moteur physique ?".
la carte d'accélération physique prenant à sa charge tout ou partie de ce que le moteur physique fait. (en tant que portion de logiciel)
je sais pas si ça t'a aidé ou si ça t'a perdu...
Message édité par bjone le 12-08-2005 à 21:09:54
enfin je pense qu'on reparlera de ça plus intensément à la sortie d'Unreal 3, qui devrait motiver les foules.
