Aller au contenu principal
sports_esports Lab Canvas 2D Gravitation Leapfrog Zéro dépendance

Problème à N corps — gravitation et orbites en Canvas 2D

Plusieurs corps s'attirent par gravitation en 1/r² : je somme les forces sur toutes les paires et j'intègre le mouvement à pas fixe en Verlet-vitesse (leapfrog), avec une gravité adoucie (softening) pour éviter les singularités. Chaque corps laisse une traînée d'orbite qui s'estompe. Zéro dépendance.

Clic-glissé : lancer un corps (vitesse = le vecteur du glissé) R : réinitialiser (système solaire ou config aléatoire) Espace : mettre en pause

Trois corps, et déjà l'imprévisible

Le problème à N corps, c'est la question la plus ancienne de la mécanique céleste : connaissant la position et la vitesse de plusieurs masses qui s'attirent, où seront-elles dans une minute, dans un siècle ? Avec deux corps, la réponse est une ellipse parfaite, connue depuis Kepler. Dès qu'on passe à trois, il n'existe plus de formule qui donne la trajectoire : il faut la calculer pas à pas. Je m'en sers ici comme banc d'essai pour montrer, à ciel ouvert, comment on simule proprement un système physique dans le navigateur — sans moteur, sans dépendance, en quelques kilo-octets de JavaScript.

La force gravitationnelle en 1/r², sommée sur toutes les paires

Chaque paire de corps s'attire selon la loi de Newton : une force proportionnelle au produit des masses et inversement proportionnelle au carré de la distance. À chaque pas, je parcours donc toutes les paires et j'additionne, sur chaque corps, les contributions de tous les autres — c'est un calcul en n² qui reconstruit l'accélération de chacun à partir de zéro. Rien n'est scripté ni « à vue » : le mouvement n'est que la conséquence de cette somme de forces, recalculée image après image.

Intégrer avec Verlet-vitesse, pas avec Euler

Connaître l'accélération à un instant ne suffit pas : il faut l'intégrer pour en déduire les positions et vitesses suivantes. La méthode naïve, dite d'Euler, avance en ligne droite dans la direction courante — sur un système orbital, elle dérive vite : l'énergie gonfle artificiellement et les orbites s'ouvrent en spirale au lieu de se refermer. J'utilise donc le schéma de Verlet-vitesse (aussi appelé leapfrog) : on avance d'abord la position avec l'accélération courante, on recalcule les forces à la nouvelle position, puis on met à jour la vitesse avec la moyenne des deux accélérations. Cet intégrateur est symplectique : il préserve remarquablement bien l'énergie sur le long terme, si bien que les orbites restent fermées au lieu de se disloquer. J'avance en outre à pas de temps fixe, sous-échantillonné indépendamment du rafraîchissement de l'écran, pour que la physique soit identique sur un moniteur 60, 120 ou 144 Hz.

Adoucir la gravité pour éviter les singularités

Une force en 1/r² a un défaut redoutable en simulation : quand deux corps se rapprochent, la distance tend vers zéro et la force tend vers l'infini. Un seul pas de temps suffit alors à éjecter un corps à une vitesse absurde, et la simulation explose. J'applique donc un adoucissement (softening) : j'ajoute un petit terme constant au dénominateur, ce qui plafonne la force à courte distance sans rien changer aux orbites lointaines. C'est une entorse assumée à la physique exacte, au service de la stabilité numérique — exactement le genre d'arbitrage qu'il faut savoir poser, et documenter, dans un calcul sérieux. La traînée que laisse chaque corps, et qui s'estompe peu à peu, matérialise ces orbites jamais tout à fait identiques d'un tour à l'autre.

Ce que ça dit de ma façon de travailler

Cette poignée de corps en orbite résume une conviction que j'applique aux projets sérieux : sur un système sensible, le choix de la méthode numérique n'est pas un détail. Le même problème, traité avec Euler ou avec Verlet, donne un résultat crédible ou un résultat faux — et l'écart ne saute pas toujours aux yeux au premier coup d'œil. C'est exactement l'attention que je porte à un calcul financier, à un moteur de règles métier ou à un traitement de données à fort volume : comprendre la mécanique sous le capot, choisir l'approche juste plutôt que la plus rapide à écrire, et livrer un code dont vous pouvez faire confiance aux résultats sur la durée.

Photo d'Emmanuel BALLERY, fondateur de x10

À propos de l'auteur

Emmanuel BALLERY est le fondateur de x10 solutions. Ces petits jeux sont surtout un plaisir de développeur, codés le week-end — pas une vitrine de mes missions, qui sont bien plus exigeantes. J'y soigne quand même la performance et la lisibilité, par habitude.

Voir plus arrow_forward
rocket_launch

Un vrai projet en tête ?

Ce petit jeu m'amuse, mais il ne dit pas grand-chose de mon métier : mes missions sont bien plus complexes. Si vous avez une application à concevoir ou à fiabiliser, c'est là que je suis vraiment utile.

Discuter de mon projet arrow_forward