Le source de mo programme est disponible ici : http://rafb.net/paste/results/Xpc4G989.html

J´ai fait un petit monde 3D avec OpenGL. Il n´y a rien de très compliqué : un sol, 4 murs et un plan incliné. Mon but est pour l´instant d´avoir une détection des collisions à peu près correcte. Le problème se trouve dans la fonction TestPosition() (ligne 343).
Voici, en gros, comment je procède :
- je sauvegarde la position qu´avait le joueur lors du précédent appel à cette fonction dans la structure PositionJoueurPrecedent
- je récupère la position du jour actuelle et je la mets dans la structure PositionJoueur
- je compare PositionJoueurPrecedent et PositionJoueur
- si entre les deux positions le joueur a traversé un mur, je modifie sa position (je le remets où il faut).

Le problème c´est que si PositionJoueurPrecedent était exactement sur la ligne de détection de collision, la collision n´est pas détectée (je sais pas si je suis clair là). Pour comprendre, le mieux c´est d´essayer.
Aux lignes 359 et 360, si vous remplacez la valeur 9.79 par 9.8, la collision n´est pas détectée. La raison : PositionJoueurPrecedent.z vaut toujours à un moment ou à un autre exactement 9.8. Dans ce cas, j´ai réussi à contourner le problème.

Maintenant, à la ligne 366 j´ai une détection de collision qui concerne le dessus du plan incliné (en gros, le joueur doit monter lorsqu´il avance sur le plan incliné. Et là, ça pose problème. Le joueurs doit s´y prendre à plusieurs reprise avant d´arriver en haut du plan incliné car il passe régulièrement à travers.
J´ai bien essayé de résoudre ce problème mais je n´arrive à rien.

Quelqu´un aurait-il su solution ?
Par avance merci.

PS : pour l´instant je ne gère volontairement pas la gravité (une fois que le joueur est remonté, il ne peut plus redescendre). Je préfères ne pas tout mélanger et régler les problèmes un par un.

travaille avec des surfaces et des volumes, pas juste avec des points. Il te faut des notions d´interieur et d´exterieur, de dedans et de dehors, de devant et de derriere, etc. pour resoudre des collisions proprement.
de plus tu contraint le systeme a un instant precis ; la bonne facon de proceder etant de considerer les volumes generer par les deplacements entre deux frames (vive les capsules et autres sweep boxes). Oui, c´est complique, il suffit pas de voir si un point est ici ou la.. Mais les collisions en general sont un pb delicat.

Tout a fait. Ls collisions sont en general gerées par des volumes, le plus simple etant la sphere (tu colle une ou plusieurs spheres de collisions sur ton perso).

dans les classiques, tu as l´arbre de sphère. je m´explique:
si ton personnage se resume a k spheres S_i, tu cree une sphere S qui les englobe toutes.
et tu teste:
si collisions avec S
pour tout i \in [0;k]
si collision avec S_i, alors COLLISIONS
mais ca se complique quand tu fais des collisions de deux arbes, je te laisse réfléchir dessus

Je vois deux cas possibles :
- je fais un jeux avec un fantôme qui passe à travers les murs
- je ne vais pas m´ennuyer ce week-end.

Plus sérieusement, je vais essayer ce que vous me conseillez.
JeanYvesYves il en parle pas de ça sur son site.
Il existe des bibliothèques pour la détection de collisions où il faut tout faire soi-même ?

gerer les collisions, c´est le but des moteurs physiques. cerche de ce coté la.
mais a mon avis tu n´as besoin que de quelquechose de tres simple (tes murs ne bougent pas). Donc tu devrais pouvoir t´en sortir sans avoir recours a l´artillerie lourde.

C´est pas sorcier la detection si tu as un environnement simple.
Comme le dit lapintade, le plus simple sont les bounding sphere.
sinon pour un moteur physique c´est bien plus compliqué, et je saurais pas encore t´aidé, mais ca viendra

comme disent les autres juste au dessus, limite toi a ce dont tu as besoin.
Si tu implementes correctement les intersections "sweep sphere Vs. triangle", rien qu´avec ca tu peux faire BCP de choses (en complement des trucs indispensables, genre triangle/triangle, ligne/triangle)