Salut à tous !

Je viens demander un peu d'aide (ou des avis) sur un problème pour lequel je n'ai absolument plus d'idée. J'ai exploré un peu le web à la recherche d'une solution concernant les collisions mais sans succès. Peut-être qu'ici on pourra me donner quelques pistes.

Voici le problème :



J'ai une map dont le décor est un mesh, je l'ai ajouté au sceneManager sous forme d'Octree comme préconisé par le tuto d'irrlicht.
Et j'ai associé un collisionResponseAnimator à mon personnage (cube vert) pour détection de collision.

Sur les figures 1 et 2, mon cube monte les pentes grâce à la collision par ellipsoïde (en rouge), c'est vraiment très pratique, en revanche, petit soucis, si je lâche la touche de direction, mon cube glisse lentement sur ces pentes jusqu'à ce que soit plat... Déjà ce problème me gêne un peu et je ne sais pas trop comment le résoudre (j'ai changé la slidingValue de l'animator mais du coup, le cube "bute" contre les pentes et ne les monte plus).

Sur les figures 3 et 4, le problème est différent mais bien plus gênant : si j'approche mon cube du bord, l'ellipsoïde "glisse" et fait tomber le cube avec elle. En fait c'est bien cette glissade qui me gêne dans la détection de collision, autant elle s'avère indispensable pour monter les pentes, autant elle me gêne pour les bords comme si ceux-ci étaient arrondis et savonneux.

Personnellement je pense que le collisionResponseAnimator n'est pas adapté à ce que je veux faire, je me dirigerait bien vers un système de collision par boite mais je ne vois pas comment implémenter une telle fonctionnalité pour gravir le relief de mon mesh. Je préfèrerai éviter d'inclure une librairie physique, car je ne compte pas faire quelque chose de si complexe, je n'ai pas besoin de gravité réaliste ni de rebonds ou de collisions au triangle près. J'aimerais que ça reste très simple.

Voila j'espère que quelqu'un pourra me décoincer un peu de cette situation. Merci d'avance.

Bon, j'ai approfondi mes recherches et j'en viens quasiment à la conclusion de devoir utiliser un moteur physique pour obtenir ce que je veux. Tmyke sur ce forum préconise Newton. Je me suis donc penché dessus.

Je n'ai pas la possibilité de tester mon code pour le moment, j'ai juste quelques pistes et j'aimerais avoir un avis pour le moment et quelques conseils pour ceux qui maitrisent.

const float NewtonToIrr = 32.0f;
const float IrrToNewton = (1.0f / NewtonToIrr);

// Création du monde
NewtonWorld* world = NewtonCreate(NULL, NULL);

// Création d'une collision de type "scène"
NewtonCollision* levelCollision = NewtonCreateSceneCollision(world);

// Récupération des informations de la boite du héro
core::aabbox3d<f32> box = hero->getBoundingBox();
core::vector3df size = box.getExtent() * IrrToNewton; 

// Création d'une collision boite
NewtonCollision* heroCollision = NewtonCreateBox(world, size.X, size.Y, size.Z, NULL);

// Création des bodies
NewtonBody* levelBody = NewtonCreateBody(world, levelCollision);
NewtonBody* heroBody = NewtonCreateBody(world, heroCollision);

// Application de la gravité au body
NewtonBodySetMassMatrix(heroBody, 1.0f, 5.0f, 1.0f, 5.0f);

while(device->run()) {
  NewtonUpdate(world, 1.0f / 60);
}

j'avais ésiter a poster la dernière fois, il me semblais que la renomer des "collisions" a la irrlicht était connue ...
il n'y pas de réelle correspondance entre les deux object, physique et graphique, perso j'utilise bullet, libre a toi mais je parle donc en coséquent.

sous bullet donc on joue sur un manager, chaque object physique dispose d'une fonctions du style "setUserData(void*)"
on passe donc l'object graphique a cette fonction (ISceneNode*), et sur le manager il te sufie de mettre a jours la physique via une list que bullet dispose, et mettre a jour la position de l'object graphique récupéré via l'object physique

sinon pour newton je supose que ce n'est pas le plus optimiser, j'avais fait moteur avec bullet, il semblais d'après TMyke que bullet semblais plus a l'aise sur le nombre d'object, mais il est plutot lourd une fois compiler.
les plus utiliser sinon:

physix
havoc
bullet
newton
ode

edit: syntaxe...

le projet "PAL" a réaliser des benchmarks avec Irrlicht incluant 13 moteurs physiques differents.
Ceci peut être très bon a essayer avant de choisir son moteur physique.
plus d'info:
http://www.adrianboeing.com/pal/benchmark.html#irrdemo

@+

Moi je veux bien passer à Bullet ou n'importe quel autre moteur physique mais j'ai juste besoin de collisions fiables avec le décor.
Et encore, quand je dis fiable, je ne demande pas la lune, mais juste que les deux problèmes que j'ai soulevé soient résolus.

Pensez-vous donc que si j'intègre un moteur physique (Newton, ODE, Bullet ou autre), je peux résoudre ces problèmes ?

Merci ^^

Il est évident que cela résoudra ton problème, mais c'est vrai que l'intégration d'un moteur physique alourdie pas mal le code.
Il y a peut être une alternative a cela
http://www.nick-online.co.uk/iphysics/index.html
C'est une api integrant Newton pour Irrlicht, son utilisation est extrêmement simple, il suffit de voir les 2-3 exemple sur le site pour avoir tout compris.
Le seul problème est que ce n'est plus en développement depuis quelque temps donc en terme de fiabilité je ne sais pas exactement ce que ça donne, mais je pense que c'est a essayer.

@+

Ouais ça a l'air sympa comme système, je vais tester ça dès que je peux et je ferai un petit retour ici sur le résultat obtenu. Merci

Résolu dans ce topic : http://irrlicht-fr.org/viewtopic.php?id=1300