Pour les dieux des équations mécaniques... - Page 2

oui (sans même vérifier, le topic concept de jx)

J'avais dit dans mon premier post qu'il ne fallait pas utiliser la force s'appliquant lors du rebond parce qu'elle est infinie.
En fait, si, il suffit de la domestiquer en la multipliant par 0 (si si, ça marche très bien !), et là la résolution du problème est toute simple ...

Version courte (résultat seul) :
Soient O le centre géométrique de l'étoile (qui devra également être le centre de masse, donc de rotation) et E l'extrémité qui tape le cadre, R=||OE|| le rayon du cercle circonscrit, et on supposera pour les calculs que ce bord est le bord inférieur (y=0).
Soient, dans le repère direct (ex;ey;ez) (par convention typographique, les vecteurs sont représentés en gras), v1=vx1.ex+vy1.ey=(vx1;vy1;0) la vitesse de translation de l'étoile (ie. de O) et w1=w1.ez=(0;0;w1) sa vitesse angulaire avant le rebond.
On note avec l'indice 2 les mêmes vecteurs après le rebond.
Soit â=(ex ^ OE) l'angle entre ex et OE à l'instant du contact, donc â est compris entre -7*pi/10 et -3*pi/10 pour une étoile à 5 branches, et entre -2*pi/3 et -pi/3 pour une étoile à 6 branches.
A noter que si â vaut une des valeurs extrémales, c'est qu'il y a en même temps une seconde extrémité qui tape également le bord et pour laquelle l'angle â correspondant vaut l'autre valeur extrémale.
Pour simplifier la notation, on note C=Cos(â), et f=J/(mR²), avec m la masse de l'étoile et J son moment d'inertie, donc f est une constante sans dimension comprise entre 0 (toute la masse est en O) et 1 (toute la masse est la la distance R de O, donc répartie plus ou moins également entre les extrémités E (plus ou moins également, mais toujours de manière à ce que le barycentre soit en O)) et qui ne dépend que de la forme et de la répartiton relative de masse de l'objet.
Pour une étoile à 5 branches homogène (masse surfacique constante), f vaut environ 0.24248583802055, et pour une étoile à 6 branches homogène, f = 11/36 =~ 0.305555...
Hypothèse pour le contact : glissement sans frottement (tout en Teflon par exemple ).
Ceci implique que si l'objet est un cercle tournant sur lui-même, sa vitesse de rotation ne sera pas modifiée lors des rebonds, donc il rebondira en suivant tout bêtement la loi de réflexion de l'optique géométrique.
A noter que pour le cercle, f = 1/2, et c'est en fait une étoile avec une infinité de branche, donc â est compris entre -pi/2 et -pi/2, donc â = -pi/2, donc C = Cos(â) = 0.
f+C²

Résultat :vx2 = vx1

      vy1*(C²-f) - 2fC*Rw1
vy2 = --------------------
              f+C²

     w1*(f-C²) - 2C*vy1/R
w2 = --------------------
        

Attention !
Il se peut très bien que vy2 soit toujours négatif (donc l'étoile continue à aller vers le cadre) et fasse taper une autre extrémité, ou qu'en repartant, une autre extrémité tape le bord dont on s'éloigne.
Par contre, pour l'extrémité qui vient de taper, aucun problème, elle s'éloigne forcément.
Dans ce cas, c'est tout simplement un nouveau rebond, donc on réindice 1 les valeurs obtenues précédemment, et on réapplique les formules pour avoir les valeurs après rebond.
Cas particulier : si l'étoile tape le bord avec 2 extrémités en même temps, alors :
vx2 = vx1
vy2 = -vy1
w2 = w1
Ceci correspond au cas C=0 (a=-pi/2), donc comme lorsque l'étoile tape le bord avec OE vertical, ou comme pour le cercle.
D'ailleurs, pour le cercle, comme il y a une infinité de branche, on peut aussi bien dire qu'il y a une extrémité ou qu'il y en a deux qui tapent le bord, ceci montre donc qu'il n'y a pas d'incohérence visible dans le résultat.


Version semi-longue (seulement les formules utilisées et les calculs) :
Calcul de v2 et w2
Calcul de f
Si vous comprenez la méthode que j'ai suivie, n'hésitez pas à vérifier mes calculs, j'ai tout fait à la main, et une erreur est si vite arrivée ...


Version longue (démonstration complète, propre et détaillée) :
Si tu en as besoin, vince, je te la fais sans aucun problème.
Par contre, à cause de la rédaction (bouhouhou, j'écris beaucoup trop lentement ), il me faudra bien plus que l'heure que j'ai passée sur le brouillon ...

Note : j'ai pris pour hypothèse pour le contact le glissement sans frottement.
Si besoin est, je peux très bien refaire les calculs avec l'hypothèse frottement sans glissement, mais là, il n'est pas certain que, lors de la résolution de l'équation quadratique, je puisse éliminer d'office un des deux résultats ... je verrai bien ...
Dans ce cas, pour un cercle arrivant avec une vitesse de rotation nulle, le rebond lui donne une vitesse de rotation non nulle, et il ne repart pas dans la direction que donne une simple réflexion.

Bouh, snif, j'ai été plus long à écrire ce post qu'à résoudre le problème ...

@++

Le pb c'est que le glissement sans frottement ne rendra pas bien. On s'attend à voir la balle repartir dans l'autre sens à certains moments, ce qui n'arrivera que dans le cas du frottement sans glissement.

En effet, le glissement sans frottement ne rendra pas bien, puisque la situation physique qu'il décrit n'est pas très courante dans la vie de tous les jours (seulement les jours de verglas, et encore ...).
Mais bon, comme je le disais, c'est surtout avec un cercle (une balle) que la différence se fera intuitivement sentir.
Pour une étoile, la trajectoire ne sera évidemment pas du tout la même non plus, mais je ne sais pas s'il est possible de dire comme ça, à l'oeil et intuitivement, quelle hypothèse de contact est utilisée.

Si besoin est, je peux très bien refaire les calculs avec l'hypothèse frottement sans glissement
, mais là, il n'est pas certain que, lors de la résolution de l'équation quadratique, je puisse éliminer d'office un des deux résultats ...

Ouais, youpi, VICTOLY !
Après je ne sais combien de temps à calculer des discriminants impossibles à simplifier analytiquement, j'ai enfin réussi, grâce à un changement de variables de folaye, à obtenir une équation quadratique dont je puisse choisir de manière certaine, parmi les 2 solutions mathématiques, celle qui correspond à la réalité physique.
Pour le glissement sans frottement, l'équation quadratique de départ se résolvait directement en deux coups de cuillère à pot, et la solution mathématique qui était physiquement irréaliste était triviale à trouver, mais là ...
Bon, je termine les calculs, et je posterai le résultat ce soir ou demain, selon la bonne volonté de mon scanner.

@++

en lisant vos posts, et surtout apres que vince aie poste:
"je ne veux pas de réalisme à tout prix..."

je me demande si vous connaissez l'integration de verlet? (qui soit dit en passant produit de bien meilleur resultats que l'integration merdique d'euler pour les timesteps larges...)

une solution tres rapide (pt de vue perfs et temps d'implementation), et qui donnne d'excellents resultats est d'utiliser des particules contraintes, comme l'a suggere neuroo

Si tu veux plus de réalisme, tu ajoutes des contraintes sur les particules (que ce ne soient plus des ponctuelles, mais des sphères etc.)

heu petit detail, normalement ce qui est appelle contraintes sur les particules c'est les liaisons entre elles, pas si elles sont ponctuelles ou pas


et ta simulation avec particules contraintes vince, ca va revenir plus ou moins a des rigid bodies simplifies...
t'as pas besoin de te preoccuper de vitesse de deplacement de ton etoile, d'inertia tensor ou de quoi que ce soit.
avec verlet... mmmh.. bon heu en pseudo code ca sera plus simple et comprehensible qu'avec des phrases:
(dsl c'est completement a l'arrache, mais ca devrait rester comprehensible)

VECTOR2D	cur_pos[n_particles];
VECTOR2D	prev_pos[n_particles];
float		invmass[n_particles];

typedef struct
{
  int		particles[2];
  float		length;
}		t_constriants;

t_constraints	constraints[n_constraints];

/*
**
*/

void	verlet()
{
  int	i;

  for (i = 0; i < n_partcles; i++)
    {
      VECTOR2D	speed;
      VECTOR2D	tmp;
      float	damping;

      tmp = cur_pos[i];
      speed = tmp[i] + old_pos[i];

      cur_pos += ((speed / prev_timestep) * damping + external_forces * timestep) * timestep;

      // here, perform collision detection and re-place the particle in a valid
      // position inside the cube.
      // to do that, compute the distance it has penetrated the collider, and
      // push it away from the collider's surface from that same distance.
      // something more or less like:

      {
	VECTOR2D	delta;
	VECTOR2D	contact_normal;

	contact_point = intersect_collider(tmp, cur_pos, &contact_normal);
	delta = contact_point - cur_pos;
	cur_pos += 2 * (contact_normal * dotp(delta, contact_normal));
      }

      old_pos = tmp;
    }
}

/*
**
*/

void		satisfy_constraints(int n_steps)
{
  int		i;
  t_constraints	*c;

  while (n_steps--)	// gauss/seidel relaxation steps, slowly converges to the optimal, stable (hopefully ;)) solution
    {
      c = constraints;
      i = n_constraints;
      while (i--)
	{
	  VECTOR2D	delta;
	  float		dlen;
	  float		diff;
	  int		im[2];

	  delta = cur_pos[c->particles[1]] - cur_pos[c->particles[0]];
	  im[0] = invmass[c->particles[0]];
	  im[1] = invmass[c->particles[1]];
	  dlen = dotp(delta, delta);
	  diff = 0.5f * (c->length - dlen) / (dlen * (im[0] + im[1]));

	  delta *= diff;

	  cur_pos[c->particles[0]] -= delta * im[0];
	  cur_pos[c->particles[1]] -= delta * im[1];

	  c++;
	}
    }
}


void		simulate()
{
  VECTOR2D	*tmp;

  verlet();
  satisfy_constraints(10);
}


void	__start()
{
  init_constraints();
  while ("marmotte")
    {
      simulate();
      render();
    }
}

je repete, c'est ecrit completement a l'arrache, et ca marche certainement pas tel quel, mais le principe est la, si ca peut t'aider vince

le init_constraints j'ai eu la flemme, mais en gros, bah comme son nom l'indique, tu remplis le table de contraintes avec les bons trucs, dans ton cas, (une particule par sommet de l'etoile), tu dois pouvoir t'en tirer avec un schema classique d'etoile avec deux contraintes par particules, comme sur le schema scanne d'ethaniel ( http://img8.exs.cx/my.php?loc=img8&image=Etoile_2.png ), mais ca serait mieux que t'en rajoute deux autres par particules, pour que particules supplementaires forment un pentagone autour de ton etoile, elle sera bcp plus rigide (et tu pourra te contenter de moins de steps de simulation)

merci bien... je regarde ça

ah et puis qquechose de tres bien avec l'integration de verlet (), c'est que les corps se mettent en mouvement tous seul, y a juste a deplacer une fois un sommet de ton etoile pour la mettre en mouvement...
et dans le code d'au dessus, tu peux rajouter une friction quand tu calcule la position de la particule apres collision avec la surface, tu multiplie juste la vecteur de penetration par un coeff entre 0 et 1 qui correspond au produit des coeffs de restitution de la surface et de l'etoile (je suis pas 100% sur que c'est le roduit des coeffs de restitution mais y me semble bien, enfin peu importe, tu t'en fous, c'est juste une approximation de tte facons )

EDIT:
et, oui, y a pas besoin de stocker les vitesses des particules, la vitesse est deduite de la position courante - la position precedente, c'est d'ailleurs ca qui permet la mise en mouvement automatique des corps

et, le prev_timestep, c'est juste dans le cas ou t'as un timestep variable, pour un timestep fixe tu t'en fous, c'est pareil que le timestep normal (logique )

c comment par rapport à runge-kutta, verlet ?

moins bien, enfin ca depend de quel point de vue hein
runge kutta, t'as pas de mise en mvt automatique des objets comme verlet, et c'est bcp plus reloo a coder
ms bon ca a pas le meme champ d'application non plus, et c'est vachement plus lent pour les ordres un minimum eleves
sinon ya aussi l'implicit euler, qui parait il est pas mal non plus, mais j'ai jamais utilise ou cherche a comprendre ca, (je sais mm pas ce que c'est le principe )

hu ? mise en mouvement auto = ?

= par exemple, t'as ton etoile, immobile.
tu fais heu un truc comme:

VECTOR2D move = {1, 0.5, 2};

cur_pos[3] += move;

et ton etoile se met en mouvement et en rotation toute seule sans que t'aie besoin de rien faire d'autre...
juste en "tirant" le 3eme vertex, ca v mettre en mouvement l'ensemble des particules qui y sont contraintes (donc toute l'etoile)

(EDIT: bordel de merde de balise de couleur)

EDIT2:

d'ailleurs dans un exemple plus concret, pour une simulation de persos, (avec bones), tu peux faire un squelette en particules contraintes, et t'en servir pour faire les rad-dolls, ou par ex, si tu veux tirer un corps par la main, tu set l'invmass de la particule de la main a 0 (donc masse infinie), et tu force sa position a la position de la main du joueur qui tire le corps, et t'as tout le systeme de particules du corps tire qui va suivre comme y faut, en interagissant avec le decor (ya aussi des contraintes d'angles pour simuler des articulations a l'epaule)

Et avec RK et une vitesse initiale, ça marcherait pas ?

bah RK, justement, il te faut une vitesse
avec verlet tu stocke aucune vitesse.

(autre ex pour verlet , t'as un zombie gere par des particules contraintes en face de toi, tu lui shoote un blast dans l'epaule, suffit de reculer legerement la particule de l'epaule en fct de la force du blast, et tu va voir ton zombie se prendre la chataigne dans l'epaule, avec l'epaule qui part en arriere, le bras qui va valdinguer, etc... bref ca poutre , et c'est trop le bordel de faire ca avec des trucs comme RK, enfin trop le bordel... c'est bcp plus couteux quoi...)

pareil pour les simulations de cloth, de gelees, etc...
euh, on s'ecarte du sujer la

Je vois pas bien la différence entre une vitesse initiale très faible et un déplacement initial très faible

rah...
verlet a pas de notion de vitesse.
regarde dans le code que j'ai poste au dessus, il stocke les vitesses nulle part, il en a pas besoin, il les deduit des anciennes positions, t'as pas de vitesse explicite.
sinon au final, ya pas de difference, a part un truc plus lent et bordelique

(sans compter que pour arriver a la meme chose, ta vitesse initiale tres faible doit diminuer, donc tu dois avoir une notion d'acceleration en plus, tout ca c'est implicite avec verlet.
dans l'ex du gars qui se prend un blast dans l'epaule, si tu donne une vitesse initiale tres faible, l'epaule continuera de reculer si tu ramene pas la vitesse a 0, alors qu'avec verlet elle se ramene toute seule a 0 grace aux contraintes et aux masses des autres particules.

ca serait mieux irc pour discutter, j'arrette pas d'editer toutes les 3 secondes pour eviter de poster 3600 posts d'1 phrase :/

Hmm d'accord en fait d'après ton EDIT2 tu veux pas faire un truc initial très faible juste pour rompre un équilibre instable, tu veux carrément déplacer certains éléments manuellement hors du modèle physique... Dans ce cas-là effectivement y aura une différence entre f'(t) et f(t+e)-f(t) ^^

Mais bon c pas un peu un hack de déplacer des trucs manuellement ?

(et la difference entre vitesse initiale tres faible et deplacement tres fible, c'est entre autres le timestep. la vitesse se fout du timestep, c'est en m/s, le deplacement c'est en 1 step, ca a rien a voir

et pour irc, chuis censé bosser, alors si je vais sur irc, je vais rien glander

bah les deplacer manuellement...tu peux tres bien ne pas les deplacer manuellement et appliquer une force exterieure
cf le external_forces d'au dessus

lol ok

"cense"

sBibi :
bah les deplacer manuellement...tu peux tres bien ne pas les deplacer manuellement et appliquer une force exterieure
cf le external_forces d'au dessus

bah si tu te restreint à external_forces sans toucher manuellement aux positions/vitesses, tu n'as strictement aucune différence entre RK et verlet, nan ?

sBibi :
"cense"

bah g un rapport de stage à rendre la semaine prochaine, faudrait que je commence à implémenter qqch de sérieux (`à`l'arrach`vraiment`sisi) et que je rédige tout ça, donc nan pour le coup v p-ê bosser

si t'as une external force distincte pour chaque particule, la seule difference ca sera que RK sera plus stable que verlet, et plus lent...
par contre tu peux tjrs avoir un truc plus ou moins "propre" qui met une particule en mouvement, ou tu lui donne une vitesse biensur, et qui deplace la particule de vitesse * timestep, sauf que c'est apres que ca changera entre verlet et RK, une fois que la particule est en mvt dans verlet, t'as rien d'autre a faire, elle evolue correctement, et se ralentit toute seule en fonction des contraintes et des autres particules, avec RK c'est pas si simple, la relaxation des particules (EDIT: avec les contraintes) c'est bien gentil, mais ca change pas tes vitesses, ca a aucune influence dessus

Pollux
:

sBibi :
"cense"

bah g un rapport de stage à rendre la semaine prochaine, faudrait que je commence à implémenter qqch de sérieux (`à`l'arrach`vraiment`sisi) et que je rédige tout ça, donc nan pour le coup v p-ê bosser

ca me rappelle des mauvais souvenirs... (et va falloir remettre ca cette annee )

./55> oué c bien ce que je dis, t'utilises des hacks

cela dit, c sûr que RK risque de pas trop apprécier si tu modélises tes collisions par une grosse discontinuité ponctuelle, parce que tu vas plus vraiment faire dans les fonctions C^n

tsss. c'est pas des hacks, c'est une solution vachement elegante je trouve , qui gere pleins de trucs de facon suffisemment realiste, avec des principes extremement simples. le code d'au dessus (enfin, la version qui marche ), peut faire des trucs que tu soupconne meme pas
et de tte facons, si tu vas chercher par la, RK aussi c'est un hack... faut modeliser la matiere a l'echelle subatomique pour pas avoir de hacks

EDIT: et chuis pas sur d'avoir tout compris dans ta derniere phrase

bah oué, échelle subatomique pouwa