Detection des collisions ellipsoidale

[Lightness1024!]

bon, ca fait un an que j'ai tapé la première ligne de mon code de detection des collisions et ca fait encore plus que je triture le concept !

bon pour le fun voici mon module de physique pour l'instant.
c'est pas facile à lire forcément donc à moins d'avoir un grand courage :)
vous trouverez dans ce répertoire les deux fichiers source copiés pour l'occasion:
http://lightness.ath.cx/apache2-default/fichiers/projet%20serhum/

tout est fortement inspiré de la technique Paul Nettle:
http://www.fluidstudios.com/pub/FluidStudios/CollisionDetection/Fluid_Studios_Generic_Collision_Detection_for_Games_Using_Ellipsoids.pdf

mais je renconte plusieurs problemes.
ce qui marche le mieux c'est la détermination du point P:
le point où il faut arrêter la sphere avant qu'il y ait contact.

mais malheureusement ca ne fait pas tout, il faut aussi glisser et alors la...
j'ai trouvé un truc qui me permet de calculer le vecteur "reste de glissement" (voir l'image slidingplane.png dans le répertoire).
ca marche mais si je boucle la routine avec ce nouveau vecteur comme vitesse je reste coincé car la fonction croit que je suis en intersection avec le plan parralèle avec lequel je suis en contact.
pour y remédier je pensait modifier la "strictitude" des égalités que j'utilise mais ca n'a rien changé. j'ai donc remonté un pti peu la direction du vecteur RDG en ajoutant une fraction de la normale du plan en contact.
ca marche mais on a l'impression de vibrer sur le sol et on s'arrete pas de bouger...
et en plus j'ai perdu la faculté de monter les escaliers.
pour l'instant je calcule le glissement et je ne revérifie pas les collisions dessus en bouclant ou récursivant. c'est faillible donc si on va trop vite en glissement contre qqch (le sol souvent) et qu'on arrive sur un mur tres vite (40m/s) on peut passer a travers si FPS < 400.

mais au moins comme ca ca monte a peu pres les escaliers.
parce que j'ai un drole d'effet super chiant qui m'éjecte violamment en hauteur si la sphere du bonhomme passe un petit peu a travers le sol.
(le moteur doit etre tolérant aux cas "embedded" comme l'explique paul nettle)
donc en corrigant la position cela recréé un vecteur vitesse trop important vers le haut (c'est mon hypothese en tout cas car je ne suis meme pas sur du comportement de mon algo).
si je modifie l'espace en ellipsoidal (en compressant la dimmension y) l'effet d'ejection est encore pire et je peux parfois me faire sattéliter dans le vide intersidéral si ya pas de plafond pour m'arreter.

donc tout ca pour dire, TheTiger > où en es tu ? as tu eu ce genre de problemes, quelle méthode as tu suivi ? les escaliers ca passe ?
etc.. quoi :)

vala

(ps: j'arrive plus a aller repêcher le thread -sur les archives du V3 qui m'a l'air bizarement adapté aux nouveaux serveurs- où tiger s'etait longement entretenu avec chai-plu-ki au sujet de la detection des collisions bounding box...)

edit:
tiens j'ai trouvé une reprise de paul nettle en flanant sur google:
http://www.peroxide.dk/papers/collision/collision.pdf
j'ai presque eu peur en lisant son pseudo code parce que c'est quasiment EXACTEMENT mon code, mais bon je me rassure en me disant que c'est ce que l'on fait naturellement si on s'est inspiré de Nettle, mais bon quand meme...

edit2:
ah oui, laeti²x, fut un temps reculé (où l'on utilisait encore des catapultes et des chevaux.. non quand meme) j'ai dessiné ce petit truc:
http://lightness.ath.cx/apache2-default/fichiers/projet%20serhum/expl2.PNG
ca montre exactement la méthode que tu as proposé à tiger pour vérifier si un point est dans un triangle.

[Laeti²x]

En attendant qu'on ebauche les solutions, ca me fait presque plaisir de dire que j'ai a peu pres les memes problemes.
A l'occasion ca me ferait aussi plaisir de voir que si mon code est proche du code de Paul Nettle. Le plus court chemin entre 2 points reste la ligne, et si on trouve tous le meme resultat, ca veut surement dire que personne a encore trouve mieux. Evidement, dans l'ideal, faudrait mieux faire...
(comme pour le triangle comme tu dis j'ai rien invente du tout... au moment ou on se penche sur un probleme on trouve les solutions les plus flagrantes. Le coup de TheTiger est definitivement plus astucieux.).
edit maintenant, les tutoriaux poussent rarement la machine dans ses derniers retranchements...
donc on a pas encore la technique ultime "pour le temps reel" qu'on essaie d'optimiser

1/ pour les escalier
je ne monte plus les pentes ou presque c'est l'enfer, j'en ai parle dans un vieux thread en meme temps que tu postais ... mais je vais eviter de reveiller les morts pour ca, je continuerais sur l'tien.

3/ je m'arrete bien au point avant le contact, je gere la suite, et c'est le "reste de glissement" qui differe peut etre sur nos codes. J'essaie au max i mum de pas faire d'approximation en plus, j'ai l'intuition que ca pardonne pas en physique (ou alors fo passer en mode guidage auto de facon cash, sinon ca pollue le truc) du coup j'en chie, j'en chie... la ca fait 2 mois que c'est "en stagnation" et j'ai pas le courage, ne serait ce meme que pour decomposer en joli petites methodes factorisables. Du coup je compte bien saisir l'occase pour reprendre.
4/ je verifie les recursif : ca alourdit a un point de ouf. alors j'ai donne une recursion max.
5/ j'ai pas eu le courage de "vraiment" lire paul nettle, du coup j'ai surement perdu des details interessants.
6/ l'ellipsoide je cherchais une astuce ehontee pour ecraser le monde au lieu
d'allonger la sphere... la perversion me perdra, c'est ignoble et j'ai meme pas tente.
7/par ailleurs en plus de ton poste, je pense a
un pb proche : les collisions quand on tourne sur soi meme avec les rotations. Ma tete fait whirl quand j'y pense et je suis heureux de n'utiliser que des spheres.

j'ai volontairement separe le pb 2: le voici developpe.
je passe a travers des fois, mais je pense que c'est des petits polygones.
D'apres la technique du sweep on lit les deux sphere par un cylindre, pour verifier qu'on a rien passe entre.
Mais le cylindre et les spheres sont des surfaces fines !
si un poly a une superficie totale inscrite DANS le rayon des spheres... il peut traverser l'ensemble dans les spheres ou dans le cylindre qui les joints... AAAAArg.

[Lightness1024!]

oui heureusement que la sphere est symétrique selon tout axe passant par son centre.
avec une bounding box de toute facon jamais on ne l'aurait fait rotater sur elle meme avec le personnage.
toujours alignée aux axes elle serait (dit yoda).

quand à l'histoire du sweeping le volume qui relie les deux positions finale et initiale est purement conceptuel, on ne le produit jamais dans le code pour vérifier l'inclusion, par contre c'est une conséquence (mentale) de ce qui doit se passer avec un bon code de collision.

je vais redonner l'idée de l'algo complet en pseudo code:


Collision(position joueur, mouvement, liste des polygones)
tfinal <- 1
pour tout polygone proche de moi dans la liste des polygones
t = coefficient d'intersection du rayon(mouvement, polygone)
si t dans segment [0, 1] alors
si t < tfinal alors
tfinal = t
polygone final = polygone
finsi
finsi
finpour
position joueur = position joueur + tfinal * mouvement
gliss = reste de glissement(position joueur, polygone final)
si (nombre de récursions < 4 ET norme(gliss) > 0)
collision(position joueur, mouvement, liste des polygones)


tout réside dans la fonction:
"coefficient d'intersection du rayon"

en fait, on lance le vecteur mouvement comme un rayon et on calcule les intersections avec les plans formés par les triangles du monde que l'on a selectionnés. (chez moi c'est tous les polygones contenus dans les listes de polygones des nodes (~= secteurs) du BiTree activées par la position du joueur)

une fois a qu'on le point d'intersection on vérifie s'il est dans le triangle (enfin dans le prisme infini dont une section droite est le polygone courant).
si oui on a une collision simple sphere-plan.
sinon il faut backtracer en lancant un rayon à l'envers à partir du point sur le polygone qui est le plus proche du point d'intersection (donc il sera forcément sur une arrête).
on repere l'intersection avec la sphere la plus proche (équation du degré 2, voir le deuxieme tutoriel dans mon edit2).
on a plus qu'a inverser le vecteur et on a le point d'arrivée de la sphere contre l'arrete du polygone.
il faut garder le point d'arrivée le plus proche parmis tout ceux qu'on a trouvé.
et il se peut que certains points soient derriere notre position actuelle.
c'est pour ca que la version "t > 0 et t < 1" est bcp trop simpliste en pratique.
(voir mon implémentation dans physics.cpp)

mais bon avec cet algorithme là le sweeping est automatique en quelque sorte puisque l'on cherche géomtriquement sans faille possible la distance la plus grande selon le vecteur "mouvement" sans collisions.
donc mentalement, on peut visualiser ca comme une technique qui vérifie tout le contenu du volume en forme de capsule formé par le cylindre reliant la position init et finale plus les deux embouts en forme de demi spheres.
(autrement dit la trace que laisse une sphere se déplacant selon un vecteur pendant un temps t avec FPS infinis sans ClearBackBuffer :D )

[Lightness1024!]

en jouant a CSS (counter strike) j'ai remarqué une faille dans la detection des collisions, si on règle la gravité à 200 (la normale est 800) par exemple, on peut sauter haut et retomber doucement sans se faire mal, bon.
mais la faille est que si on descend des escaliers normalement on devrait les survoler car notre chute est plus lente que le mouvement d'avance, ce qui est l'inverse normalement.
j'ai remarqué que l'on ne décolait pas du tout des escaliers et que l'acceleration verticale que cela engendrait était fortement plus importante que la gravité actuelle.
J'ai remarqué autre chose, si on arrive sur une pente, on ne décole pas non plus on reste collé au terrain meme si les discontinuités sont trop importantes, cela choque comme comportement par rapport a la gravité faible.

cela me fait penser à une simplification possible de la detection des collisions: le suivi de terrain.
peut être que la gravité ne peut être appliquée que dans le cas où on ne touche pas le sol et trouver des cas de "décollage": le saut, les angles abruptes entre polygones.
et alors il serait peut etre meme possible de monter les marches bcp plus facilement !
j'ai remarqué que y'avais application du "suivi de terrain" sur le mode caméra de l'ancien counter strike (ver <= 1.5) parfois on ne peut plus remonter meme en visant en haut lorsqu'on avance parce que la caméra est coincée à 1 metre du sol a peut pres.
bug ou feature, j'ai jamais su.

[Comtois]

J'ai commencé il y a quelques semaines en regardant le tut de Paul Nettle, puis celui de Kasper Fauerby.

J'ai tout à faire , je travaille en parallèle sur un petit éditeur pour me faire des map 3D.Pour l'instant , il me permet de poser des murs , ça me suffit pour mes tests. j'ajouterai la construction des escaliers, sol , et autres après.

C'est tout frais , j'ai fini de coder hier soir la gestion des collisions , et j'obtiens un premier résultat , je détecte bien mes murs , ma sphère reste bien bloquée au bon endroit sur le mur , wow du premier coup sans bug, merci Fauerby !!

Par contre, ça ne glisse pas , je vais bosser là dessus maintenant.
Je n'ai pas encore géré la gravité , chaque chose en son temps.
Donc voila , y'a encore pas mal de boulot, mais le premier résultat est encourageant :)

Tout ça pour dire que ce post m'intéresse .
D'après vos dires , c'est maintenant que la galère commence pour moi ,avec la gravité et le glissement j'ai de quoi m'amuser on dirait :)

Bon assez parlé , je vais vérifier le calcul du glissement !

[Comtois]

Bon voila un début de résultat , cette fois ci ça glisse et la gravité est gérée.
C'est pas terrible , ça broute, j'ai des problèmes avec le sol , alors dans cette démo , j'ai triché, j'ai un seul triangle pour le sol. Mais ça ne fait rien, je suis quand même content :)

Je n'ai pas encore essayé avec un escalier, il faut d'abord que ça fonctionne correctement avec cette démo , et c'est pas demain la veille :00000030:

Pour l'instant j'ai suivi à la lettre le tutoriel de Fauerby , je vais tout reprendre en essayant d'autres solutions, on verra bien ce qu'il en ressortira.
Il n'y a pas les sources dans la démo (c'est la même chose que le tut de Fauerby , sauf que je l'ai adapté à PureBasic)

Le zip contient deux exe , le premier permet de créer une map en 2D.
le second permet de créer la map en 3D à partir de la map 2D et de tester les collisions.

Démo (576 ko) (http://perso.wanadoo.fr/comtois/sources/Forum.zip)

[Lightness1024!]

bienvenue au club :D
bravo pour avoir réussi du premier coup, et aussi vite :00000013:

pour le moment je suis sous nux, si je reboot sous win un de ces 4 je testerais ta démo.

[Comtois]

J'ai très légèrement amélioré les collisions ,c'est loin d'être satisfaisant , mais je ne passe plus au travers des murs comme dans la version précédente :)

Et maintenant je ne triche plus , il y a plein de triangles au sol , enfin 2 pour le sol , et 2 triangles par marche d'escalier, eh oui , vous avez bien lu Escalier , j'ai fait un essai et ça fonctionne pas trop mal.

Il reste des choses à mettre au point , notamment à la jointure des triangles au sol , il y a un léger glissement le long de la jointure,c'est agaçant.
et ça saccade sur les angles des murs par endroit.

Dans la démo qui suit j'ai changé le robot par un ninja (celui des démos d'ogre).
Mais pour ça il a fallu que j'utilise la version beta d'ogre et donc que je change le fichier Engine3D inclu dans l'archive .
C'est pourquoi le fichier est un peu gros , il contient la version beta de la dll Engine3D.

Version Avec le fichier Engine3D 1Mo (http://perso.wanadoo.fr/comtois/sources/ForumAvecEngine3DBeta.zip)

Et pour ceux qui auraient déjà la DLL ( les possesseurs de PureBasic )
J'ai fait une archive sans la Dll
Version Sans le fichier Engine3D 189 ko (http://perso.wanadoo.fr/comtois/sources/ForumSansEngine3DBeta.zip)

Bon maintenant il va falloir que je m'intéresse aux maps Quake3,c'est le format que permet de charger PureBasic pour l'instant , peut-être d'autres formats avec la V4 ?

Petite question , vous utilisez quoi pour la gestion de vos collisions , des triangles ou des polygones ?

Pour l'instant j'ai tout fait avec des triangles, mais je me demande si je ne ferais pas mieux de tout reprendre pour gérer des polygones ?

[Laeti²x]

un petit message, parce que je suis l'evolution de la thread en attendant de poster du concret :

je pense qu'il vaut mieux garder des triangles dans l'absolu,
mais des quads, ca peut bien le faire, et ca reste un cas particulier,
notement, ca amene la collision bounding box plus facilement.

[Lightness1024!]

moi comme je suis en DirectX tout est triangle.
et puis comme ca mes fonctions sont plus simples...

j'ai toujours pas pu tester ta demo mais je le fait des que j'ai win de booté ;)
(pas le temps la, plein projet de base de donnée a rendre lundi :00000032: )

[Comtois]

Ok merci pour vos réponses , je suis resté sur les triangles :)

YAhouuououououou !!!
Je suis trop content , j'ai enfin trouvé mon erreur !!
ça ne tremble plus et je passe correctement les jointures au sol.
J'étais en train de rédiger un tutoriel sur les collisions , et arrivé au chapitre résolution d'une équation du second degré , j'ai trouvé une solution intéressante sur wikipedia.org (http://fr.wikipedia.org/wiki/%C3%89quation_du_second_degr%C3%A9)

Voir le chapitre "Gain de précision" en bas de l'article .
En voyant ça , j'ai voulu tester , et comparer les résultats avec la procédure que j'utilisais.Et je me suis rendu compte que ma procédure ne retournait aucune valeur , alors qu'elle m'indiquait bien qu'il y avait une solution pour résoudre l'équation , en fait , j'avais fait une erreur sur un pointeur.
Et du coup , je récupérais une mauvaise valeur .
J'ai corrigé le pointeur , et maintenant , ça fonctionne nickel :D

Bon j'ai encore pas mal de boulot pour rédiger le tutoriel , et commenter le code, mais je préfère donner un code qui fonctionne , j'étais pas satisfait du précédent .

En attendant encore une petite démo
Il n'y a pas de ninja ni de robot ,c'est une vue à la première personne.
Touche [F1] pour afficher la map en 2D.
Bouton gauche de la souris pour tirer.
la balle ne va pas vite ,c'est pour me laisser le temps d'aller vers la cible et de vérifier que la balle atteint bien l'objectif visé ( une tache sur un mur , ou un truc facilement repérable).

Le calcul de l'angle est correct si on ne tire pas trop haut ni trop bas, je vais voir pour améliorer ça par la suite. Après il n'y aura plus de balle , juste un lancé de rayon , si le rayon touche sa cible , elle explose ,et on en parle plus .

VisuMap3D2.zip (http://perso.wanadoo.fr/comtois/sources/VisuMap3D2.zip)

Je suis curieux de savoir si ça rame chez vous ou pas , vous avez quel FPS ?
Chez moi il est à 75 .

Je viens de changer les textures des murs ,et j'ai fait un petit scaleTexture pour pour améliorer l'apparence. et j'ai ajouté un petit ciel.
Si les murs disparaissent quand vous baissez la caméra, c'est un bug de la lib 3D , j'utilise la version beta, ça sera corrigé avec la version finale ,du moins , je l'espère.

[Sami]

Avec ta démo j'ai un FPS de 85. Mais pas de murs! Désolé je peut pas tester les collisions.

[Comtois]

bizarre , ça le fait à d'autres ?

Je viens de télécharger le fichier pour le tester , ça fonctionne chez moi.
Au départ tu es dans les nuages , c'est ça que tu vois ? ensuite tu tombes , il faut attendre un peu , ou incliner la caméra vers le sol pour voir quelque chose , si au bout de quelques secondes ,tu ne vois toujours rien alors là c'est inquiétant, je ne vois pas pourquoi

et pour ceux qui n'auraient pas PureBasic et les Dll nécessaires (1Mo)

Les DLL nécessaires (http://perso.wanadoo.fr/comtois/sources/Engine3DBeta.zip)

[Comtois]

Avec ta démo j'ai un FPS de 85. Mais pas de murs! Désolé je peut pas tester les collisions.

quelqu'un d'autre a le même problème que toi , et maintenant ça me revient , ce qui a changé par rapport à l'autre démo c'est que dans cette dernière , j'ai créé un mesh par mur pour pouvoir gérer les coordonnées UV des textures (proportionnelles à la dimension du mur) , avant je n'avais qu'un seul mesh , mais je ne pouvais pas adapter les coordonnées uv aux dimensions du mur.

Alors est-ce une limitation des cartes graphiques ? ou Ogre ? enfin si ça fonctionne chez moi et chez d'autres , c'est pas ogre, mais sûrement les capacités des cartes graphiques ? quelqu'un a une idée à ce sujet ?

en gros dans la démo , il y a 90 meshes , et 90 entitys

[Comtois]

voila j'ai collé le code source ici (http://forum.games-creators.org/showthread.php?t=2260)

C'est du PureBasic .

[Lightness1024!]

ok ta de la chance, mon disque de 200go a laché, avec ma partition linux dessus et des dixaines de séries que je vais devoir retelecharger, arggggggh.

bon, donc je suis sous win, j'ai testé ton truc.
ca tourne coincé a 85fps (vsynch).

les collisions fonctionnent sans pets.
par contre on peut pas faire de pas chassés et avancer en meme temps, tres tres mauvais gameplay.
bon, je suppose que c'est que le début :)
en tout cas tes collisions elles marchent mieux que les miennes faudra que j'aille voir ton code lol.

[Comtois]

par contre on peut pas faire de pas chassés et avancer en meme temps, tres tres mauvais gameplay.

Quel rabat joie :D

Bon ok je vais regarder ce que je peux faire, mais c'est pas la priorité , maintenant , il faut que j'améliore la visée de la caméra, que je limite son angle quand on regarde en haut ou en bas.Et que j'ajoute une fonction LancerRayon() pour le tir , et la vision . Et quelques objets à exploser , ça c'est juste pour me défouler :)
Ensuite une gestion d'un quadtree pour me faire la main.

[Lightness1024!]

Quel rabat joie :D
ca tu peux le dire :D

Bon ok je vais regarder ce que je peux faire, mais c'est pas la priorité , maintenant , il faut que j'améliore la visée de la caméra, que je limite son angle quand on regarde en haut ou en bas.Et que j'ajoute une fonction LancerRayon() pour le tir , et la vision . Et quelques objets à exploser , ça c'est juste pour me défouler :)
Ensuite une gestion d'un quadtree pour me faire la main.

oki, gg comme on dit ! :)

[Comtois]

je viens de tester ton jeu serhum , elles sont où les collisions ?
Je voulais voir où tu en étais avec ça , parce que moi j'ai encore du boulot pour améliorer les miennes , je suis toujours à la recherche de nouvelles solutions , ou de corrections :)

c'est volontaire l"effet grand angle de la caméra ? ça fait bizarre je trouve, ça déforme beaucoup.

[Lightness1024!]

ah oui j'ai pas mis a jour les executables du site, je devrais le faire puisque je sais qu'il faudra une autre phase de developpement pour les rendre plus correctes de toute facon.
oui l'angle de vue doit être dans les 95°, je devrais peut etre mettre une variable réglable dans la console, c'est pour voir les ennemis plus vite :)

bon je vais rebooter sous win et faire une release, tu as raison il est temps. en plus j'ai achevé dernierement mon enregistreur de timedemos (a support de pathtrack).

EDIT:

voila, j'ai uploadé la derniere beta en état de marche. (last working beta :) )

[Comtois]

j'ai cette erreur , j'ai sélectionné essai2.map pour le niveau à ouvrir :
---------------------------
Erreur
---------------------------
Impossible de lire le fichier niveau
---------------------------
OK
---------------------------
Puis
---------------------------
Erreur
---------------------------
Le chargement du 'brut' à échoué.
---------------------------
OK
---------------------------

[Lightness1024!]

ah oui, j'aurais du mettre un readme, je vais le faire parce que y'a rien d'évident a ca.

il faut bien sur compiler les fichiers .map en fichier .niv (binds vers un .brut et un .tree) . (les .map sont exploitables par hammer editor)

pour ce, utilise "lanceur" et configure les chemins pour lancer "compilateur2.exe".
lanceur créera une ligne de commande pour lancer la compilation et redirige la sortie dans un pipe vers une fenêtre à lui.
si tu coches la suppression de faces cachées, attention l'algorithme est en O(n²) ca prend 3 minutes chez moi :00000010:
si ca t'amuses tu peux lancer le compilateur dans une console et faire la ligne de commande toi meme, l'exe te donneras "l'usage" :)

donne moi ton feedback sur tout ce que tu penses qui vaut le coup d'etre remarqué, positif, ou négatif :00000009:

merci :)

[Comtois]

les collisions fonctionnent sans pets.
par contre on peut pas faire de pas chassés et avancer en meme temps, tres tres mauvais gameplay.
bon, je suppose que c'est que le début :)

Je te retourne la remarque !! Purée déjà faut trouver les touches , je pensais utiliser bêtement les flèches du curseur , ben non , peut-être qu'il y a un fichier d'aide quelque part ? je n'ai pas trop cherché :)

Sinon c'est très très très difficile à diriger ton truc , les collisions fonctionnent bien , mais les déplacements sont impossibles , c'est exprès qu'une fois en mouvement on ne puisse plus s'arrêter ? A part contre un mur ?

Sinon j'ai pu compiler le niveau , mais ensuite , quand je lance serhum, il faut donner le chemin du niveau , et le type proposé est "fichiers niveau" , mais pas de pot , aucun fichier ne s'affiche , alors j'ai sélectionné "tous" , et là on ne sait pas quoi choisir , bien sûr j'ai choisi le bon fichier en dernier ,celui sans extension :)

J'aime bien la map , c'est immense , je veux la même pour faire des essais avec PureBasic :)
ça serait compliqué à mettre au format Xml pour Ogre ta map ?

Je suis tombé sur la console en tripotant le clavier pour chercher les touches pour me déplacer, et c'est pas mal , il va falloir que je songe à en programmer une.

[Lightness1024!]

Je te retourne la remarque !!

ah nan nan, on peut aller en transversal !


Purée déjà faut trouver les touches , je pensais utiliser bêtement les flèches du curseur , ben non , peut-être qu'il y a un fichier d'aide quelque part ? je n'ai pas trop cherché :)

bon sang, ta raison, un readme s'impose fortement :D
Z, Q, S, D c'est la combinaison la plus frequemment utilisée.
(en qwerty: a,w,s,d)
le mieux serait de faire un fichier de config pour paramétrer les touches bien sur ! je l'ai pas encore fait mais je crois qu'il serait temps :)
le probleme que je rencontre c'est que les touches sont des constantes, f0ck je vais devoir me taper l'énorme switch... hm, je trouverais un moyen crade d'y échapper.
Reste le probleme du qwerty, car les touches directinput sont des scancodes et non des touches virtuelles. :/


Sinon c'est très très très difficile à diriger ton truc , les collisions fonctionnent bien , mais les déplacements sont impossibles , c'est exprès qu'une fois en mouvement on ne puisse plus s'arrêter ? A part contre un mur ?

oui c'est hard. C'est expres a moitié, avant j'avais mis des frottements, pour ralentir mais ils etaient inconditionnels avec le contact d'un objet, donc on tombait dans le vide comme dans l'eau (tout doucement).
pour pouvoir prendre bcp de vitesse et tester la fiabilité des collisions je les ait enlevés totalement.
tu peux freiner en reculant :)


Sinon j'ai pu compiler le niveau , mais ensuite , quand je lance serhum, il faut donner le chemin du niveau , et le type proposé est "fichiers niveau" , mais pas de pot , aucun fichier ne s'affiche , alors j'ai sélectionné "tous" , et là on ne sait pas quoi choisir , bien sûr j'ai choisi le bon fichier en dernier ,celui sans extension :)

ah, oui, tu as donné un nom au fichier destination sans préciser a la main l'extension, je vais mettre un truc qui le detecte et qui la rajoute si elle n'est pas la ca évitera ce probleme.
voila le genre de beta tests constructifs !


J'aime bien la map , c'est immense , je veux la même pour faire des essais avec PureBasic :)
ça serait compliqué à mettre au format Xml pour Ogre ta map ?

oui je l'agrandi sans arret, c'est génial pour tester, ca fait test de charge, et ca permet d'être assez certain que si un bug existe il se manifestera.
pour l'xml, alors la, aucune idée...
je ne connais pas Ogre, tu peux tojours regarder le format .map (c'est de l'ascii) voir si ya assez d'info pour être converti...


Je suis tombé sur la console en tripotant le clavier pour chercher les touches pour me déplacer, et c'est pas mal , il va falloir que je songe à en programmer une.
lol faut vraiment que je mette un readme :)

cette console j'en suis super content, ya bcp de code rien que pour elle :00000025: mais c'est fun a programmer.


EDIT:
ok j'ai rajouté la detection de l'oubli d'extension, j'ai fait un readme et j'ai rajouté des poutres et une porte au hanger de départ de essai2.

[Atréides]

le probleme que je rencontre c'est que les touches sont des constantes, f0ck je vais devoir me taper l'énorme switch... hm, je trouverais un moyen crade d'y échapper.
Bon, ce sont des constantes, mais elles doivent avoir une valeur, non ? Tu peux essayer d'afficher ces valeurs ou de les écrire dans un fichier text puis d'y faire appel au lancement du programme (par exemple, si pour avancer on presse W, tu cherches quel numéro correspond à A). Solution "crade" mais potable :)

[Comtois]

J'ai une question , toujours au sujet des collisions ellipsoïdales.

Jusqu'à présent j'ai travaillé avec une liste de triangles représentant un ensemble statique. Les collisions de l'ellipsoide avec ces triangles fonctionnent, la réponse aussi. Bref que du bonheur.

Maintenant je voudrais ajouter la gestion d'objets dynamiques.
Pour l'instant je me suis contenté d'une plateforme qui se déplace horizontalement , et d'un ascenceur.

J'utilise le même principe que pour les triangles statiques, je dresse une liste des triangles dynamiques, calcule les coordonnées dans la base de l'ellipsoide pour travailler avec une sphere de rayon 1 par la suite.

Par contre , cette fois ci les triangles se déplacent dans le monde 3D, je ne recalcule pas leurs positions dans la base de l'ellipsoide à chaque fois , j'applique un changement de repère à l'ellipsoide pour travailler dans le même repère que la plateforme en cours de test.
Ensuite , le test des collisions est le même que pour un triangle statique.

ça fonctionne pas trop mal.

Première question
Si toutefois quelqu'un a réussi à me suivre jusqu'ici, est-ce la bonne méthode ? est-ce que vous auriez d'autres méthodes à me suggérer ?
ou tout simplement il faut que je m'exprime mieux parce que ce n'est pas clair ?

Si l'ellipsoide est en contact avec une plateforme en mouvement, j'ajoute le vecteur vitesse de la plateforme à l'ellipsoide.

alors tout va bien si je suis sur la plateforme, par contre si je suis contre la plateforme à déplacement horizontal, dans ce cas , je reste collé.
Autre problème plus important, et c'est plus particulièrement sur celui ci que j'aimerais bien votre avis :
Comme je change la vitesse de l'ellipsoide en additionnant la vitesse de la plateforme , normalement il faudrait que je teste à nouveau les collisions avec le nouveau vecteur vitesse , et c'est là que ça coince , parce que je n'en fini pas de boucler , et paf ! stack overflow !
Je me demande si c'est pas pour ça qu'on voit toujours des plateformes dans le vide dans les jeux , ça évite d'avoir à reboucler le test des collisions :)

Bref , comment vous faites pour gérer des objets dynamiques ?

[Lightness1024!]

dans half life 1 c'etait pas mal mais ca avait l'air assez sale en fait.
parfois des bugs de coincements...

dans HL² c'est différent vu que les collisions utilisent un solveur !
un truc de fou qui fait les calculs en fonction de tous les autres objets avec influences réciproques et tout et tout en cascade niquel...
mais alors pour implémenter, argh, faut s'appeller havok software quoi...

je vois pas d'autres techniques pour une premiere estimation rapide, j'aurais fait comme toi.

[Comtois]

j'ai fait quelques modifs , y'a du mieux , mais c'est loin d'être satisfaisant.

Si je mets mes plateformes dans le vide ça fonctionnera très bien, il faudra sauter dessus , et roule ma poule :)

pour les ascenceurs , si le perso se trouve dessous pendant qu'ils descendent, à la moindre collision il faudra que je les fasse remonter, comme ça je n'ai pas de réponse à prévoir pour le perso.

Avec quelques combines de ce genre y'a moyen de s'en sortir, mais ce n'est pas vraiment satisfaisant , je vais reprendre tout ça plus tard à tête reposée.

Le post reste ouvert, si quelqu'un a des idées ou des suggestions qu'il n'hésite pas à en parler.

Finalement presque personne ne calcule ses collisions ? vous utilisez des libs ? c'est ça le secret ? :)

[Lejumeau]

Salut,

J'ai commencé à m'interresser aux collisions basées sur l'algo de Paul Nettle.
J'ai réalisé un niveau et j'ai développé une applicaiton et bien sur j'ai quelques problèmes.

J'aimerais vous poser quelques question.

- Est ce que l'algo à Paul Nettle ce suffit à lui tout seul pour monter des escalier, ou y a t'il un aménagement de l'algpo à réaliser ?
Mon personnage monte les escalier mais seulement quand je monte sur le coté de l'escalier.

- Pour la gestion de la gravité.
De qu'elle manière le faite vous, vous réaliser deux tests de collision ? un pour le vecteur de vélocité et un pour le vecteur de gravité
ou un seul test en additionnant le vecteur de vélocité avec le vecteur de gravité ?

- A propos du niveau
Est ce que le niveau en question peut être généré avec n'importe qu'el editeur 3D ? et dans le cas contraire est ce que le niveau doit être créé avec un editeur spécial ?

Samuel,

[Lightness1024!]

Salut,

J'ai commencé à m'interresser aux collisions basées sur l'algo de Paul Nettle.
J'ai réalisé un niveau et j'ai développé une applicaiton et bien sur j'ai quelques problèmes.

J'aimerais vous poser quelques question.

- Est ce que l'algo à Paul Nettle ce suffit à lui tout seul pour monter des escalier, ou y a t'il un aménagement de l'algpo à réaliser ?
Mon personnage monte les escalier mais seulement quand je monte sur le coté de l'escalier.


je pense que non. J'ai exactement le meme comportement. mon personnage accelere quand il se trouve dans une glissiere, (contre deux plans en meme temps).

physiquement c'est logique, la seule force d'avance du perso ne suffit probablement pas pour monter l'ellipse sur les marches. et quand qqun monte vraiment des escaliers il pousse majoritairement vers le haut. je dirais donc que ya qqch a rajouter pour ca. et detecter les surfaces verticales en contact ne serait pas suffisant. (bug si on longe un mur et qu'on avance vers une pente, on risquerais de planer au dessus de la pente au lieu de coller sur le sol et descendre comme tout le monde)

donc qqch a voir...


- Pour la gestion de la gravité.
De qu'elle manière le faite vous, vous réaliser deux tests de collision ? un pour le vecteur de vélocité et un pour le vecteur de gravité
ou un seul test en additionnant le vecteur de vélocité avec le vecteur de gravité ?


moi je fais en une fois, mais c'est parfois conseille de faire en deux fois, pour les escaliers justement.
moi je considere ca comme un bug, parce qu'a bas niveau de FPS on pourrait sauter des trous sans sauter.



- A propos du niveau
Est ce que le niveau en question peut être généré avec n'importe qu'el editeur 3D ? et dans le cas contraire est ce que le niveau doit être créé avec un editeur spécial ?

Samuel,

c'est tout l'avantage de cette methode. ca s'adapte a n'importe quelle liste de triangles, c'est donc 100% general, quelque soit l'editeur. et surtout surtout, aucune intervention du mappeur.

[Lejumeau]

Resalut,

J'ai du nouveau,

A propos des escaliers
J'ai trouvé mon erreur, cela provenait de la fonction qui permet de trouver le point le plus proche sur une ligne.
J'avais inversé l'ordre de deux vecteurs dans une soustraction et du coup le résultat n'était absolument pas celui attendu.
Je m'en suis rendu compte car en fait comme je l'ai dit précédement le personnage montait les escaliers seulement sur les côté mais pas dedans.
Alors l'idée m'est venu de vérifier cette fonction et BINGO !!!!

Mainteant mon personnage monte les escaliers en colimaçon et droit.
Il arrive aussi à monter sur les rampes ainsi que dans des tunels que j'ai réalisé avec la fonction TUBE du logiciel de modélisation 3D.

J'ai ajouté la gravité aussi.
Avec ce paramètre on se heurte à de nouvelles réactions supplémentaire qui sont aussi assez rigilo et que l'on peut contourner facilement (je pense).

A propos de votre tutorial
sur les collision response que vous aviez commencé (pas celui de paul Nettle) qui est très bien au passage mais le votre. J'aime bien avoir l'avis de plusieurs personne sur la question.

Gravité dans Quake
Dans le code source de Quake j'ai trouvé ceci : gi.cvar_set("sv_gravity", "800");
800 l'unité est en quoi ?? c'est 8 metre par seconde au carré ???


Samuel