Simulation 3.4 — L'écrasement au sol

Simulation 3.4 — L'écrasement

Simulation · s'appuie sur les étapes 2 et 3

En 3.1, la bille rebondissait sans une égratignure. Dans la vraie vie, un objet qui touche le sol encaisse — il se déforme, ou il casse.

Trois cubes identiques, lâchés ensemble, de la même hauteur. Seule leur matière change.

vitesse de lecture ×0.25 · 4× plus lent hauteur de lâcher — m 6.0 vitesse de lancer — m/s vers le bas 0.0 souplesse du mou 1.0 fragilité du cassant 1.0 découpe du cassant — N×N×N 5 revenir en arrière — le temps simulé 0.00 s

Ce qu'il faut savoir (16)

Un écrasement DOIT conserver le volume. Si vous écrasez en Y sans rien faire d'autre, le cube rétrécit — et l'œil le repère instantanément, même sans savoir pourquoi. La matière ne disparaît pas : ce qu'on perd en hauteur, il faut le rendre en largeur. D'où le 1/√s sur X et Z, qui garde x · y · z = 1.
C'est le premier des douze principes de l'animation — le squash & stretch de Disney. Un objet parfaitement rigide paraît mort. Même une balle de golf se déforme à l'impact ; simplement trop peu et trop vite pour qu'on le voie. En animation, on exagère — c'est ce qui donne le poids.
Le sol est un ressort, et la déformation EST l'enfoncement. On ne replace jamais le cube de force : on le laisse s'enfoncer, et le sol le repousse d'autant plus fort qu'il s'enfonce. Sa demi-hauteur vaut alors exactement sa hauteur de centre, donc son bas retombe sur zéro tout seul. Aucune durée n'est codée nulle part : elle sort de la physique.
Le contact doit être testé plus souvent que l'image — c'est ce qui rendait cette page saccadée à ma première version. Une seule détection par frame, et à 10 m/s le cube s'enfonce de 17 cm avant qu'on le remarque ; le remonter d'un coup est une téléportation, et l'œil la voit. En 12 sous-pas, l'enfoncement tombe à 1,4 cm et le mouvement redevient continu. C'est pour ça que les moteurs physiques tournent à 240 Hz pendant que l'écran est à 60.
La vitesse de lecture ne touche à AUCUNE constante. Ni la gravité, ni la raideur, ni l'élasticité : elle multiplie le temps qui s'écoule entre deux images — exactement le ×0,5 d'un lecteur vidéo. La physique reste la même, on la regarde plus ou moins vite. Et c'est nécessaire : un impact réel dure 60 millisecondes, soit quatre images, et aucune raideur ne peut l'allonger — sa durée vaut π/(2ω) et sa profondeur v/ω, les deux tiennent au même ω. C'est pour ça qu'on filme les crash-tests à 10 000 images par seconde.
Revenir en arrière n'enregistre RIEN — ça rejoue. Bouger la barre de temps remet tout à zéro et rappelle le pas de simulation autant de fois qu'il faut. Zéro mémoire, là où enregistrer les positions de 32 768 morceaux coûterait 900 Ko par image. C'est exactement ce que fait le replay d'un jeu : on ne stocke pas les images, on stocke la graine et on rejoue.
Mais rejouer exige une simulation REPRODUCTIBLE, et ça se paie sur deux points. D'abord Math.random() est banni : on ne peut pas lui redemander la même suite, donc la fracture serait différente à chaque retour en arrière. Un générateur à graine (ici mulberry32, quatre lignes) le remplace, et on remet la graine à chaque lâcher.
Ensuite, le pas de temps doit être FIXE. La simulation n'avance jamais du temps écoulé depuis la dernière image — toujours de 1/240 s exactement, avec un accumulateur qui garde le reste pour l'image suivante. Avec un pas variable, les mêmes deux secondes ne tomberaient jamais pareil, et l'image d'un instant donné changerait à chaque visite. C'est le prix du déterminisme — et c'est aussi ce qui rend la physique identique sur un 60 Hz et un 144 Hz.
Lancer et lâcher ne s'additionnent pas. Le curseur de vitesse jette le cube vers le bas ; il touche alors à √(v₀² + 2gh), jamais à v₀ + √(2gh). Lancer à 10 m/s un cube qui tomberait déjà à 10 n'en fait pas 20 mais 14,1 — c'est l'énergie qui s'ajoute, pas la vitesse, et l'énergie va comme le carré. Poussez les deux curseurs et vérifiez.
Doubler la hauteur n'écrase pas deux fois plus. L'écrasement suit la vitesse d'impact, et la vitesse va en √h (3.1). Passer de 3 à 6 mètres ne fait que ×1,41. Il faut quadrupler la hauteur pour doubler le choc.
Attention au scale qui tombe à zéro. Une échelle nulle rend la matrice de l'objet non inversible : les normales deviennent absurdes, l'objet vire au noir ou disparaît. Le code plafonne donc l'écrasement à 0,15 — jamais 0.
Les morceaux SONT le cube. On le découpe en N×N×N cellules — le curseur règle N — chacune à sa vraie place et à sa vraie taille : leur volume total vaut donc exactement le sien, par construction. Ma première version faisait apparaître 90 petits cubes dans une flaque au sol — 0,37 m³ pour un cube qui en fait 1. Les deux tiers de la matière s'évaporaient, et ça se voyait sans savoir pourquoi.
Un objet qui casse ne s'arrête pas de tomber. Les morceaux gardent tous la vitesse d'impact — rien ne les a freinés. Ce sont les cellules du bas qui touchent le sol ; celles du haut continuent leur chute et s'écrasent sur le tas. Ma première version les faisait exploser vers le ciel : ça n'arrive jamais.
Ce qui projette la matière, c'est l'écrasement — pas une explosion. La couche du bas est comprimée et n'a nulle part où aller sauf sur les côtés, exactement comme une goutte qui s'étale. D'où l'éjection radiale proportionnelle à la profondeur dans le tas : forte en bas, nulle en haut. C'est ce qui donne la gerbe plate d'un objet qui se brise, au lieu d'un feu d'artifice.
Un éclat ne rebondit pas comme une balle : il claque et il glisse. Restitution 0,12, et un frottement au sol exprimé par seconde (exp(−6·dt)) et non par contact — un morceau qui glisse est freiné en continu, pas une fois par rebond. Sinon le freinage dépendrait du nombre d'images.
Ce qui triche encore, et il faut le dire : une vraie fracture consomme de l'énergie (créer des surfaces coûte), les morceaux ne s'entrechoquent pas ici, et leur découpe est une grille — le réel donnerait des cellules de Voronoï de tailles très inégales. Une simulation de rupture honnête est un autre métier : c'est le domaine de moteurs comme Rapier, pas de quinze lignes.

← Précédent · Suivant →