mon prof mas dit que la methode pour donenr un effet de deceleration.acceleration a l objet (en c++ _sleep(n)) etait d utiliser une serie.
 
Au debut je ne la ferai rebondir que par rapport a laxe y
puis j y rajouterai un deplacement vertical.
 
masi quelle serie utiliser ?
 
 
 
 

une piste  :
perte d energie cinetique a chaque rebond
 
ek= 0.5 * m *v *v
ek *=0.80
 
vitesse = racine ( 2 * ek / mass)
 
et pour lacceleration je derive v ?
comment reproduire leffet de ralentissement quand la balle ateint son maximun, puis d acceleration dans la descente ?
 

bon, ma meca est rouillee, mais je vais essayer.
 
quand tu lache ta balle, elle a une energie mecanique E qui vaut la somme de l'energie cinetique et de l'energie potentielle. Si ta balle rebondit de facon elastique (ie sans perte d'energie), E reste constant. Toi ce que tu veux faire, c'est du choc mou. admettons que chaque rebond corresponde a une perte constante d'energie mecanique P (apres, tu pourras facilement varier, genre, on perd un pourcentage de l'energie, ou autre... ici je fais juste le principe).
 
petit rappel simple:
 
on suppose que ta balle a une masse constante, on a donc:
a = dV/dt = la pesanteur g (j'imagine que tu te places sur Terre, que tu negliges les frottements de l'air, etc) = constante.
 
     ->     ->             ->
d'ou V(t) = V(t0) + (t-t0).g       (1)
 
 
(ici t0 est ton temps de reference, tu peux prendre par exemple le moment ou la balle est lachee: t0 = 0 et V(t0) = 0 (si elle est lachee sans vitesse initiale) ou une autre valeur si la balle est lancee)
 
au moment du choc, l'energie de ta balle vaut effectivement mV^2, tu lui enleve ce qu'elle est censee perdre comme energie => P
 
d'ou la nouvelle vitesse Vn:
 
(1/2).mV^2 - P = (1/2).mVn^2  
  => Vn = racine_carre(V^2 - 2.P/m) (2)
 
et il suffit d'appliquer la formule de la chute libre (1) pour calculer le mouvement de la balle jusqu'au prochain choc.
 
NB: dans la formule (2) j'ai neglige l'energie potentielle car j'ai considerer le cas ou la balle rebonfit sur une surface plane. Si la surface est inclinee, l'energie potentielle est differente a chaque rebond, il faut la prendre en compte theoriquement, mais a mon avis tu auras un resultat satisfaisant en ne t'embettant pas avec )
 
 
j'espere que ca t'aidera
 
 
 
 

thks je vais essayer ca =)
je trouve ca super interessant  

En chute libre la trajectoire d'un objet c'est une simple parabole.
(on suppose évidemment que le champ de gravité est constant -> pas de simulations de rebonds dans l'espace )
 
LeGreg

legreg, ca a rien a voir, mais t'as deja fait mumuse avec le VQ ?

Je connais le principe, ça ressemble à la palettisation  
si je ne m'abuse.
 
mais non pourquoi ?
 
Grégory

parce depuis hier je me prends la tete a essayer de comprendre pourquoi mon compresseur pete les plombs quand je passe en bloc de 4x4 pixels (a la place de 2x2). A taille de codebook egal j'ai un resultat degueu, qui prends plus de place sur disque
 
Pe que des vecteurs de 48D c'est abusé ?

Comment ça peut prendre plus de place ?
(je me gratte la tete)
 
ou tu veux dire que ton registre a autant d'éléments
mais ils sont quatre fois plus grands ? d'ou a prise de poids ?
 
LeGreg

Par taille de codebook egal, j'entendais nombre d'entrée
 
donc si tes entrées ont 48D a la place de 12, forcement ca prends plus de place (ca c bon)
Par contre que mes resultats soient aussi infect me depasse, donc je me demandais si des vecteurs aussi large etait raisonnable pour ce type d'application

Le nombre d'élements à matcher quand tu multiplies la taille de ton vecteur par quatre a quelques ordres de grandeurs de différence (malheureusement ce n'est pas linéaire)
 
La bonne nouvelle c'est que tu atteint assez rapidement la taille de ton image en terme d'éléments et qu'une image reste compressible en terme d'information...
 
LeGreg

hum
je posterais des shots parce que j'ai des sales aberations (y'a pas d'autre mot) due au passage en 48d
 
grand jeu du soir
Quelle gueule aura le shot ?
 

    polueur

 
En plus, comme tu es en discret, pour calculer la nouvelle position p(t1), pense à ne pas faire :
"p(t1) = p(t0) + (t1-t0) * v(t1), (intégration qui te donnera une erreur par excès)"
mais :
"p(t1) = p(t0) + (t1-t0) * [v(t1)+ v(t0)]/2".

 
Oh eh  ! faudrait voir a pas exagérer !
cette équation est intégrée depuis longtemps (Galillée ou la 1ère) et c'est celle d'un objet en chute libre.
 
chute libre dans un champ de gravité constant -> parabole..
 
LeGreg

 
  N'oublie pas qu'on est en temps discret   Tu diverges avec ce procédé, d'ailleurs, en calcul de dynamique (moteurs physiques principalement), un gros problème est le choix de la méthode d'intégration, aucune n'est parfaite, mais celle ci est la pire (méthode d'Euler Explicite)...

 
?? faudrait voir à pas déconner
le probleme de la chute libre est simple,
c'est une parabole en temps continu, en temps discret tout ce que tu veux.
L'intégration elle se fait à la main, pas besoin d'Euler ou de Verlet.
 
Je ne parle pas de moteur physique ici (qui gerent des collisions et interactions à plusieurs corps ou des modeles de fluides) mais du rebond d'une balle..
 
LeGreg

 
??? Ce n'est pas parce qu'on intègre à la main que ça ne s'appelle pas la méthode d'Euler.  
 
Dans le post initial que je quotais, souk utilisais l'intégration pour déterminer v(t1) à partir de g et v(t0). Et non pas la solution analytique -> parabole dont on connait l'équation en fonction de t.
 
Partant de ce principe, je faisais donc remarquer que raisonner de la même manière (intégration) pour déduire les positions à partir des vitesses induirait une erreur (parce que si g est constant pdt tout le pas de temps, v ne l'est pas).
 
Je suis bien sûr d'accord que dans ce cas précis, utiliser la solution analytique donne aussi les bon résultats (mais elle est moins évolutive si tu veux rajouter d'autres interactions par la suite), je profitais juste du fait qu'on aborde le pb de l'intégration numérique dans la post de souk pour faire remaquer ce petit truc... Faut pas s'enflammer    

Vu le niveau de la question de départ, je doute qu'il s'intéresse aux problèmes d'intégration numérique
 
mais ça peut effectivement être très intéressant quand on s'y intéresse (et c'est là qu'on découvre que des systèmes mécaniques simples se révèlent rapidement chaotique.. et ceci quel que soit la méthode d'intégration.. Cf Poincaré..)
 
LeGreg

je minteresse au pb d integration numerique      
dites en moi plus.    

 
Dés que tu auras une accélération variable au cours du temps (plusieurs forces à l'oeuvre), il devient compliqué d'utiliser des formules analytiques, donc le principe est :
PFD : somme des forces/masse -> accélération.
A partir de l'accélération, tu déduit la vitesse -> du style v = a*dt
A partir de la vitesse tu déduit la position -> du style p = v*dt
 
Comme tu es en temps discret, tu es obligé dans ton équation d'approximer la manière dont l'accélération et la vitesse varient à l'intérieur d'un pas de temps : cela équivaut pour l'accélération par exemple, à évaluer l'accélération moyenne durant le pas de temps (cette accélération est comprise entre a(t) et a(t+dt), or le PFD te donne a(t) seulement...). C'est de là que naissent les erreurs dues à l'intégration.
 
Un intégrateur d'ordre n : plus n est grd, plus tu seras précis, mais plus il t'en coutera en temps de calcul.
 
Fait des recherches google avec les mots "schéma d'intégration", "Euler implicite", "Euler semi-implicite", "Runge-Kutta"... (pas trop le temps tout de suite de débattre du sujet).