./14>
La rotation se fait par rapport au centre? J'ai l'impression que oui puisque tu prends un centre de gravité.
oue, la rotation, par rapport au centre de gravite de l'objet.
juste pour être sûr, torque (collier) c'est bien l'accélération angulaire? (a += dt * torque)
le torque, c'est a priori plutot "couple" en francais...
et non, c'est pas l'acceleration angulaire, ca sert a faire varier l'acceleration angulaire.
de meme qu'une force fait varier l'acceleration lineaire, un torque fait varier l'acceleration angulaire.
en gros, en generalisant, t'as un truc comme ca:
ApplyForceOnObject(vector where, vector force)
{
totalForce += force;
totalTorque += cross(where - CenterOfMass, force);
}
et ensuite dans l'update de ton objet:
linearAccel = totalForce * invMass;
angularAccel = invMasslessInertiaTensor * totalTorque * invMass;
linearVelocity += linearAccel * dt;
angularVelocity += angularAccel * dt;
position += linearVelocity * dt;
angle += angularVelocity * dt;
Ensuite quand tu parles des impulses (vecteurs permettant de faire sortir l'objet du terrain) j'en ai plusieurs, mais je dois attendre d'avoir terminé la vérification de tous les points de contact avant d'appliquer une force pour le "sortir", c'est ça? Et j'applique uniquement la force du vecteur le plus grand. Mais dans certains cas appliquer cette force ne suffira pas à sortir l'objet (s'il touche à deux endroits qui ne sont pas sur une surface plane). Dans ce cas je vais devoir refaire une détection de collisions droit derrière? Ca me semble un peu bidouille en fait...
oui donc la deja les c'est pas des impulses au sens strict. et t'applique pas une force au sens strict non plus.
la en fait le principe de prendre la plus grosse valeur de penetration pour sortir l'objet, c'est un raccourci qui permet de replacer l'objet a l'endroit ou la collision est censee avoir eu lieu. mais c'est une approximation qui assume principalement que la vitesse de deplacement du tank est purement verticale, ce qui evidemment est totalement faux, et que le tank n'a pas de vitesse de rotation (ce qui evidemment est totalement faux aussi
)
mais.
- dans _tous_ les cas, le fait de faire ca fera toujours ressortir le tank, du moment que (comme precise dans un precedent post), ton terrain est une heightmap.
- comme pour les primitives de collision (points -> segments -> etc..) une fois que le reste marche, tu peux facilement changer ca et utiliser une technique plus complexe et meilleure pour trouver le temps d'impact, minimiser les integration, et donner a ton solver de meilleurs impulses ou forces.
la ce qu'il faut bien voir, c'est que le hack de deplacer le tank par la plus grande valeur de penetration, ca revient a essayer de trouver le dernier etat "valide" qu'avait le tank au sein de ton timestep avant d'entrer en collision.
en gros, si tu regarde l'etat de ta simulation, t'es au temps 't', et tu veux avancer la simulation a 't' + 'dt'
en 't' ton tank a une position valide ou il n'intersecte rien.
en 't + dt', ton tank a peut etre toujours une position valide, dans quel cas, tres bien, t'as rien de special a faire, mais dans le cas contraire, idealement:
A - il faut savoir quand, entre 't' et 't+dt', a eu lieu la collision. ('t+dt*0.2' ? 't+dt*0.85' ? ...)
B - il faut ensuite avancer la simulation au temps de la collision 't+dt*colTime'.
C - il faut calculer la reponse du tank a la collision. pour ce faire, tu vas soit juste reflechir le vecteur vitesse avec un coefficient d'amortissement, ou bien prendre en compte la position du point de contact par rapport au centre de gravite, et appliquer un impulse, ou bien... bref...
(note que le principe reste le meme si c'est deux objets dynamiques hein, c'est juste que les impulses appliques aux deux objets ne sont pas calcules pareil (enfin si, tu pourrais utiliser le meme code, en donnant une masse infinie a ton terrain (donc une invmass de 0, c'est, au passage, une des raisons de l'utilisation de l'inverse de la masse dans les moteurs physiques, c'est plutot rare d'avoir une masse nulle, et une invmass nulle te permet d'avoir des objets "inbougeables", et d'utiliser un codepath generique pour tout... (bref...)))
la, le fait de replacer le tank en utilisant la plus grande profondeur de penetration, ca pseudo-resout les points A et B.
pour correctement resoudre le point A, il faudrait prendre en compte le mouvement reel du tank, ses rotations, etc..
tu pourrais par exemple, une fois que t'as un truc qui marche, remplacer le hack du replacement du tank par un truc qui va, pour chaque point ou il y a une penetration, creer un segment entre la position du point a 't' et la position a 't+dt', et raytracer le terrain. (ca, ca approxime la rotation pendant le timestep comme etant une translation lineaire de chaque point du tank, mais c'est pas genant si ton dt est faible)
ou bien, recuperer la vitesse instantanee de chaque point a 't+dt', et back-tracer le terrain avec.
ou bien, decouper le timestep en 'n' sous-steps et re-tester les collisions a chaque step.
ou bien, subdiviser le timestep dichotomiquement pour trouver le temps d'intersection.
ou bien, ... bref...
apres, il faut bien voir que meme si c'est un hack, a moins que ton jeu tourne a 2 fps et que tes timesteps soient gigantesques, ou que ton tank bouge de 300 pixels par frame, l'erreur moyenne sera plutot faible.
t'aura juste un tank qui aura une legere tendance a grimper les pentes.
et compare aux autres methodes ca a l'avantage de te garantir, pour un debut, que tu n'aura pas de probleme avec des configurations invalides. ton tank sera toujours replace sur le terrain. (meme si tu commence ton jeu avec le tank entierement a l'interieur du terrain, il sera projete instantanement a la surface des la premiere update physique.
)
Fichier joint : 
?))
)
sinon on risque de perdre de l'info, en imaginons qu'on a les angles {-2, 3, +2}, la moyenne devrait être 3 mais elle sera 1 ^^
Prochaine étape: ce que m'a décrit momotte 
(oui, c'est intrinsèquement lié, effectivement 
