Résolution de collision entre une sphère et un plan

[faucheuse]

Bonjour à tous,

Je suis en train d'essayer de faire rebondir une bille sur un terrain plat. Pour cela j'utilise cette fonction :

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
bool PlaneSphereResolution(D3DXVECTOR3& _PrevQ, D3DXVECTOR3& _Q, D3DXVECTOR3& _vInit, float _fFrame, float _fRadius) 
{
    D3DXMATRIX transMat;    
    D3DXVECTOR3 P1(_PrevQ), P2(_Q), P3;
    D3DXVECTOR3 V1in;
	D3DXVECTOR3 vUp(0, 1, 0) ;
 
    // Restitution coefficient
    float fRebound = 0.6f;
 
    // Compute velocity
    V1in = P2 - P1;
    float distP1P2 = D3DXVec3Length(&V1in);
	float fVCurrent = distP1P2/_fFrame ; 
 
    // Compute Q
    float k;
	_Q.y = _fRadius ;
 
    k = (_Q.y - P1.y) / (P2.y - P1.y);
    _Q.x = k*(P2.x-P1.x)+P1.x;
    _Q.z = k*(P2.z-P1.z)+P1.z;
 
    // Rebound
    D3DXVECTOR3 Vout, P2Q = P2 - _Q;
	D3DXVec3Normalize(&P2Q, &P2Q);
    P3 = P2 - (1+fRebound) * D3DXVec3Dot(&P2Q, &vUp) * vUp; 
 
    // Reinitialise motion parameters
    Vout = P3-_Q;
    D3DXVec3Normalize(&Vout, &Vout);
    _vInit = fRebound * fVCurrent * Vout;
 
    return true ;
}

Le problème : ce code est tiré d'un autre projet qui fonctionne très bien, mais la la bille rebondit correctement en y mais ne bouge pas en x et z (elle rebondit sur place, malgré sa vitesse initiale en x et z).

Pourriez vous m'aider à régler ce problème svp ?

[plegat]

Salut,

Envoyé par faucheuse

Le problème : ce code est tiré d'un autre projet qui fonctionne très bien, mais la la bille rebondit correctement en y mais ne bouge pas en x et z (elle rebondit sur place, malgré sa vitesse initiale en x et z).

Je ne sais pas pour les autres, mais moi, balancer du code sans autre explications que les 3 commentaires inclus, c'est un peu limite... (heureusement qu'on connait l'algorithme pour le rebond, sinon bonjour la compréhension des variables)

Sinon, si ce code fonctionne très bien dans un autre projet, c'est que ça ne vient pas de lui!
Donc que ça vient d'à côté... et là, on n'a rien à se mettre sous la dent...

Vérifie déjà tes vecteurs vitesse en amont et aval de cette procédure.
Ensuite, regarde ce que tu en fais (et éventuellement, donne nous plus d'infos...)

[faucheuse]

Evidemment que le code vient pas de moi, je vais pas m'amuser a recoder tout un code normalement fonctionnel.

Je ne vois pas quoi donner d'autre comme explication, le vecteur vitesse au sortir de la fonction a une composante en x et en z quasiment nulle (0.002 par exemple) quelque soit la vitesse de départ.

Le problème semble venir du calcul de Vout lorsque l'on calcul la nouvelle vitesse, peut etre le calcul n'est il pas bon.

[plegat]

Envoyé par faucheuse

Evidemment que le code vient pas de moi, je vais pas m'amuser a recoder tout un code normalement fonctionnel.

Hors sujet... relis ma réponse précédente, la tienne n'a rien à voir avec...

Envoyé par faucheuse

Je ne vois pas quoi donner d'autre comme explication, le vecteur vitesse au sortir de la fonction a une composante en x et en z quasiment nulle (0.002 par exemple) quelque soit la vitesse de départ.

D'après ce que j'en comprends, le code est bon (même si je le trouve un peu tendancieux sur les rebonds rasants... et que ça plante le point suivant sur le plan et pas au bon endroit après rebond... mais ça doit être fait exprès), ça ne vient pas de lui. Ca vient des paramètres que tu lui passes... il y a quoi dans _PrevQ, _Q, _fFrame et _fRadius dans le test que tu fais?

[ericd69]

salut,

vInit n'est utilisé qu'en sortie, il ne sert pas dans les calculs d'où sa non prise en compte pour le déplacement, il ne sert qu'à donner le vecteur vitesse ascensionnelle.

[Nyarlathotep]

D3DXMATRIX transMat;
D3DXVECTOR3 P1(_PrevQ), P2(_Q), P3;
D3DXVECTOR3 V1in;
D3DXVECTOR3 vUp(0, 1, 0) ;

Voici une bonne raison de laisser tomber DirectX.

Pour rester dans le sujet :

Un plan est défini par une normale, et une distance sur l'axe de cette normale.
Pour faire un rebond parfait d'une sphère sur un plan, on projette la vitesse de la sphère (notée V) sur la normale du plan (notée N) et on utilise ce résultat pour calculer la vitesse après le choc (notée Vfinal) :

proj=N.V (produit scalaire)
Vfinal=V-2*proj*N

[ericd69]

oui une pauvre loi de réflexion tout bête avec atténuation :p

[plegat]

Envoyé par Nyarlathotep

Pour faire un rebond parfait d'une sphère sur un plan...

Ce qui n'est pas le cas ici.
Voir le code de faucheuse pour de plus amples détails, mais vous y trouverez facilement le coef de restitution à 60%

Le sujet datant de septembre dernier, j'ose espérer que la question a été résolue depuis...
Sans doute après avoir vérifié les paramètres en entrée et en sortie... comme suggéré...

[ericd69]

lol j'espère aussi pour elle...

mais bon, c'est toujours le pb de beaucoup de monde qui prends du code tout fait sans le comprendre vraiment le fonctionnement

[stardeath]

Envoyé par Nyarlathotep

Voici une bonne raison de laisser tomber DirectX.

pas vraiment dans le sujet, mais ça, ça m'intéresse, histoire de rigoler 5 minutes. alors c'est quoi déjà l'explication de cette raison, et c'est quoi les autres?

[ericd69]

tout simplement le vecteur vitesse en entrée ne sert que pour en extraire la norme et générer la vitesse post rebond mais sans prendre en compte la direction de celle-ci...

[stardeath]

c'est pas sur le code en lui même que je pose une interrogation, c'est en quoi DirectX pose problème visiblement.

[ericd69]

je sais pas lol

j'ai travaillé avec les 2 opengl et directx et pour l'instant ce dernier offre toujours le plus de manipulation possible...

l'un et l'autre ont néanmoins leur avantages comme pour opengl, le fait d'avoir tout un tas de primitive graphique de plus haut niveau et glut pour générer une application 3d rapidement sans avoir à maitriser les modes graphiques et les buffers pour directx

par contre, faut savoir que la lib d3d qui implémente les vecteurs, matrices, etc n'utilise rien pour l'accélérer

[plegat]

Envoyé par ericd69

tout simplement le vecteur vitesse en entrée ne sert que pour en extraire la norme et générer la vitesse post rebond mais sans prendre en compte la direction de celle-ci...

Il doit y avoir quelque chose qui vous échappe dans l'algo alors...

Envoyé par stardeath

c'est pas sur le code en lui même que je pose une interrogation, c'est en quoi DirectX pose problème visiblement.

Oh non, on va repartir sur un troll openGL/DirectX...

[stardeath]

Envoyé par ericd69

par contre, faut savoir que la lib d3d qui implémente les vecteurs, matrices, etc n'utilise rien pour l'accélérer

l'accélérer? à part l'utilisation du sse2 (ce qui est déjà le cas), je ne vois pas comment accélérer plus la gestion des vecteurs.

Envoyé par plegat

Oh non, on va repartir sur un troll openGL/DirectX...

effectivement, mais le démontage d'une techno sans argument, ça mériterait une rectification quand même.

[ericd69]

Envoyé par stardeath

l'accélérer? à part l'utilisation du sse2 (ce qui est déjà le cas), je ne vois pas comment accélérer plus la gestion des vecteurs.



effectivement, mais le démontage d'une techno sans argument, ça mériterait une rectification quand même.

y a pas que sse :p une bonne optimisation de certains calculs en assembleur (simplement déjà sur l'ordre des opérations par exemple)
en plus, sse nécessite d'avoir 1 version de chaque fonction par version de sse...

le troll opengl/directx est le même que celui windows/linux et bien souvent entretenu par les linuxiens, sans vrai argument technique

plegat relit le code ça fait un rebond selon uniquement la normale et pas un rebond libre sur le plan...

[stardeath]

l'ordre des opérations? là je veux bien un exemple, parce que si le programmeur ordonne mal ses calculs, ce n'est pas non plus à directx de résoudre ça.

directx fournit des fonctions simples de gestion des vecteurs, matrices, etc qui sont optimisées. je ne vois pas ce qu'il pourrait faire de plus.

après sse3 et 4, j'ai pas souvenir de performance miraculeusement supérieure à sse2.

[plegat]

Envoyé par ericd69

plegat relit le code ça fait un rebond selon uniquement la normale et pas un rebond libre sur le plan...

Effectivement, le rebond se fait toujours suivant la normale. On ne rebondit pas en tangentiel, même dans la vraie vie!
(sauf nadal et federer cet aprèm, mais ils utilisent un subterfuge physique qui n'est pas dans les paramètres!)

Algo de rebond classique, on modifie le vecteur vitesse en lui ajoutant 2 fois (ou 1+coef de restitution) le vecteur normal à la surface pondéré de la vitesse normale.

Et là, en entrée, on n'a pas le vecteur vitesse, on a les deux vecteurs position (+ la durée d'un frame + le rayon de la sphère).

Mais on ne se poserait pas se genre de question, si au début, comme je l'ai demandé dans mon premier post, on avait eu les explications plutôt que du code brut.

Envoyé par stardeath

effectivement, mais le démontage d'une techno sans argument, ça mériterait une rectification quand même.

Je te l'accorde, sauf que là c'est Nyarlathotep qui a lancé le troll, et que toi et ericd69 avez mordu à l'hameçon...
Et que c'est complètement hors-sujet avec le sujet...

[stardeath]

oui, mais bon, peut être qu'il y a des arguments (même si mon sarcasme laisse entendre que je n'y crois pas une seule seconde), et je voudrais les entendre, comme la discussion actuelle sur le sse avec ericd69.

si il y a quelque chose à apprendre, de mon point de vue, c'est intéressant d'en parler.

[ericd69]

c'est aussi pour ça que je suis contre les gens qui pompe un code sans comprendre ce qu'il fait: ne pas confondre ne pas réinventer le fil à couper le beurre et je pompe car je sais pas faire et oh merveille un truc ressemble à ce que je veux)



perso j'ai plutôt désamorcé en disant que les 2 ont leurs avantages et leur inconvénients comme linux et windows

parlons de sse et optimisation assembleur de la 3d alors lol

déjà contrairement à ce que tu crois, l'optimisation sse est une option de compilation donc un choix du programmeur et elle implique une architecture (le processeur qui la supporte) sous peine de plantage...
donc tu as 2 choix si tu veux le sse:

• soit tu fais un code qui teste ton processeur et tu charges la lib qui correspond (le meilleur choix)
• soit tu exécutes le code qui va bien à chaque fois (lourd)

d'où le fait que souvent, vu l'hétérogénéité des plateformes le choix de ne pas utiliser sse... ou de figer le code à 1 seule version

en plus sse est pensé pour les calcul de codec pas forcément pour les math en général...