Gestion de collisions

Signaler
Messages postés
2
Date d'inscription
lundi 5 mars 2007
Statut
Membre
Dernière intervention
29 janvier 2008
-
Messages postés
3874
Date d'inscription
mardi 8 mars 2005
Statut
Modérateur
Dernière intervention
7 novembre 2014
-
Bonjour a tous.

Je viens sur votre forum car à force de chercher je me retrouve plus embrouiller qu'au début. JE vous expose mon problème.
Je souhaite creer un petit jeu de voiture assez simple. Mais je voudrais y inclure un système de collisions entre les voitures et le décor. Et la je ne sais pas trop comment m'y prendre.

Y aurait-il des librairies/surcouches d'OpenGL qui facilitent ce genre de gestion? Ou alors si ce n'est pas le cas, quelles sont les solutions les plus simples et efficaces?

Je profite de ce sujet pour également vous demandez un petit conseil. A l'heure actuelle je me sers d'openGL avec Glu et Glut, mais j'ai entendu parlé OpenInventor. Est-ce que vous me conseiller cette surcouche ou alors je dois laisser tomber.

Merci d'avance pour vos réponses

4 réponses

Messages postés
3874
Date d'inscription
mardi 8 mars 2005
Statut
Modérateur
Dernière intervention
7 novembre 2014
14
Salut,


Tu as jeté un coup d'oeil aux moteurs physiques, style ODE ou autre ?
Messages postés
280
Date d'inscription
dimanche 7 septembre 2003
Statut
Membre
Dernière intervention
8 juillet 2014
5
salut


il y a 3 niveaux de collisions/physique:


le cas du jeu de voiture assez basique, où entre autre les décors ne sont pas destructibles, la voiture reste collée au sol... dans ce cas il vaut mieux coder soi même la physique et les collisions, plutôt que de se prendre la tête avec un moteur physique: en plus une fois les bases de la physiques comprises, il te sera facile d'utiliser un moteur physique pour ton prochain projet (sans se prendre la tête cette fois!)


le cas du jeu super évolué avec des tremplins, des éléments destructibles, la voiture qui fait des tonnaux en cas de crash... dans ce cas il vaut mieux connaître un peu (beaucoup!) la physique et utiliser un moteur physique (le mieux est d'en tester plusieurs, probablement qu'aucun  ne te conviendra à 100%)


le dernier cas est la simulation réaliste: aucun moteur physique n'est assez généraliste pour être utilisé dans une simulation comme gran turismo: il faut tout coder soi même d'autant plus que le problème sera d'obtenir quelque chose de réaliste, et de pas trop lent : seul un moteur spécialisé pour ce jeu en sera capable


Renaud
Messages postés
2
Date d'inscription
lundi 5 mars 2007
Statut
Membre
Dernière intervention
29 janvier 2008

Bonjour, merci pour vos réponses.
Alors mon jeu correpond plus à ton premier cas de figure. donc tu me conseilles de le faire moi même.
en quoi cela consiste ? parce que bon j'ai bien une petite idée mais cela me semble assez lourd à mettre en place.

en effet, je pensais mettre une sorte de boite autour de mes objets (voitures et décors) et vérifier si les coté des boites se coupaient. mais cela me parait un peu lourd dans le sens ou ça oblige a faire de multiple tests à chaque instant.
Y a til une méthode bien plus légère ?

bonne soirée
Messages postés
3874
Date d'inscription
mardi 8 mars 2005
Statut
Modérateur
Dernière intervention
7 novembre 2014
14
Y a des techniques assez compliquées dans le domaine, à base d'arbres ou autre usine à gaz.


Pour faire plus simple, tu peux par exemple couper ton décors en zone :

1 2 3

4 5 6

7 8 9


Si ta voiture est dans la zone 5 et que tous les meshs de ton décors
sont de tailles inférieures à la taille d'une zone (- la taille de la
voiture...), alors la voiture ne peut entrer en collision qu'avec des
meshs se trouvant dans les zones 1 .. 9.


Une optimisation est d'utiliser 2 boîtes englobantes pour chaque mesh :
une "classique", et une alignée avec les axes. On commence à faire les
tests sur la boîte alignée car il sont plus faciles, et s'il y a
collision, alors on passe sur les boîte classiques, plus précises.


Dans ton cas de voitures, tu peux même te ramener à un problème plan
pour ce qui est des boîtes alignées : de simples rectangles.