La blague « seul le Verlet qui vient de la région française de Verlet est du vrai Verlet ; sinon, ce n’est que de l’Euler pétillant » est excellente
Je me demande comment on passe de connaissances en développement web, Gradle et Java à la capacité de construire ce genre de chose
Comme je n’ai pas fait de licence d’informatique, j’ai parfois l’impression que, même en apprenant autant de langages de programmation que je veux, je ne comprendrai jamais ce genre de choses. J’ai un peu touché à OPENLY, LIBGDX, GODOT et Unity, mais créer une simulation de tissu à partir de zéro me paraît vraiment intimidant
C’est beaucoup plus simple qu’on ne l’imagine. J’ai réalisé la démo de « tissu déchirable » liée ailleurs dans ce fil avant même de commencer ma carrière d’ingénieur logiciel
Ici, on utilise une intégration de Verlet de base : on met à jour des vecteurs 2D formant une grille à partir de leur position actuelle et précédente, puis on impose des contraintes pour qu’ils gardent une certaine distance avec leurs voisins immédiats. Si on trace des lignes entre ces points, on obtient un tissu. En cherchant parce que les simulations physiques me fascinaient, je suis tombé dessus au début parce que c’est l’une des choses les plus faciles à implémenter, avec un très bon rapport effort/résultat. Bien sûr, après ça, cela devient beaucoup plus complexe
J’ai ressenti quelque chose de similaire en voulant apprendre la simulation physique. Avec le temps, j’ai compris qu’il fallait séparer les domaines de connaissance comme la physique des outils de programmation qui servent à les implémenter
Quand on commence surtout par le développement de jeux, on a l’impression qu’il devrait exister une façon naturelle et idiomatique de programmer chaque grande simulation — corps rigides, tissu, ressorts, fluides, etc. Au début, je pensais que même la simulation de fluides s’exprimerait naturellement dans le langage, en créant une grille puis en choisissant des règles de mise à jour à chaque pas de temps. Mais en réalité, il faut modéliser le problème en mathématiques et en physique, puis le faire correspondre au langage et aux outils, et ces outils ne l’expriment pas toujours de façon idiomatique
Certains algorithmes, comme les positions de particules et les simulations de tissu à base de ressorts, se transposent facilement en code, mais cela m’a plutôt induit en erreur quand j’ai voulu aller plus loin. Au final, j’ai dû creuser davantage la physique et l’analyse numérique, puis traduire le problème en code, avec un résultat qui peut être rugueux et rempli de nombres magiques
Le développement web ne se limite pas à Java et, dans l’ensemble, il est dominé par des problèmes d’intégration de composants. Il y a beaucoup de structure mais peu de contenu ; les calculs sont délégués à des bibliothèques ; au moment du build, le problème est la complexité d’intégration, et à l’exécution, l’échelle des systèmes distribués
À l’inverse, écrire une simulation implique beaucoup de calculs, donc la majeure partie du code constitue le contenu réel. Si le développement web est un assemblage d’éléments hétérogènes, la simulation est plus homogène. La contrainte, c’est la performance d’un seul processus dans le budget temporel fixé par le nombre d’images par seconde
On peut donc se concentrer sur un seul environnement d’exécution. Je recommande le navigateur, qui règle le problème du déploiement. Ganja[1] est peut-être le projet de simulation ultime du type « du contenu plutôt que de la structure ». Il est très particulier et difficile à comprendre, si bien que la maintenance s’est arrêtée, mais il fonctionne. Du côté un peu plus structuré, il y a D3, dont les auteurs ont déjà implémenté des algorithmes modernes de visualisation/mise en page, comme les graphes à forces[2]. Un point de départ plus accessible peut être la famille Processing[3], partie de Java puis portée vers Python, JavaScript, etc.
Cela dit, une seule simulation de tissu, si on la compare à un moteur de jeu, équivaut à peu près à une cellule d’une souris. Les moteurs de jeu sont très vastes et, même là, on finit souvent par faire beaucoup d’intégration interne plutôt que d’écrire directement des simulations
1 - https://github.com/enkimute/ganja.js/blob/master/ganja.js
2 - https://github.com/d3/d3-force/tree/main/src
3 - https://processing.org/
Au bout du compte, tout est mathématiques et physique
La question ne portait pas précisément sur le développement de jeux, mais les connaissances en graphisme, mathématiques, éclairage et physique y sont généralement très répandues. Si l’on cherche seulement un sujet de niche comme la simulation de tissu, il peut être difficile de trouver des informations qui ne soient pas liées aux ressources de développement de jeux
J’ai lu aujourd’hui https://alextardif.com/LearningGraphics.html, qui peut servir de guide dans plusieurs directions. https://learnopengl.com/ reste régulièrement bien considéré, même aujourd’hui avec des API plus récentes comme Vulkan, Metal et DX12. Mais il faut voir l’API comme environ 5 % du problème à résoudre. Honnêtement, c’est peut-être encore moins, même si Vulkan est plus lourd encore que ce que j’en avais entendu
Si vous ne voulez pas apprendre C/C++, la communauté WebGL est importante, donc vous pouvez commencer par les subreddits ou forums correspondants. Cela dit, l’API et la plateforme sont surtout une enveloppe autour de la partie vraiment impressionnante et nouvelle : la simulation physique elle-même
Pour donner mon contexte, je suis développeur web/Gradle/Java et, après une tentative il y a quelques années, je me remets à créer un moteur de jeu sur mon temps libre
Ce n’est pas si difficile. En JavaScript, il suffit de représenter chaque point par (x,y,z), de lui donner une masse, puis d’appliquer la gravité à chaque frame et d’ajouter éventuellement un peu de bruit
Chaque fois qu’une particule tente de bouger, on transmet la force aux autres points à travers les arêtes avec de la trigonométrie, et on ajoute un peu d’amortissement pour éviter que ça ne s’emballe. La masse détermine ensuite à quel point chaque point est affecté par les forces. Si la 3D vous intimide, commencez en 2D
Cela me rappelle une vidéo de Polygon qui analyse l’incroyable conception des tissus dans Elden Ring : https://youtu.be/wSSqx-Dh6ko
Un point que la vidéo ne souligne pas assez, c’est que les tissus ont aussi une fonction. Ils masquent la silhouette des ennemis et rendent les modèles plus difficiles à distinguer.
Dans un jeu centré sur les combats au corps à corps et sur des hitboxes précises — ce qui est sans doute l’un des aspects les plus novateurs des jeux FromSoft — les tissus qui flottent librement rendent plus difficile de juger à quelle distance placer son personnage pour toucher, ou à quelle distance rester pour ne pas être touché. Ajoutez à cela des mouvements et des patterns d’attaque imprévisibles, et la difficulté augmente encore, chaque combat devenant unique.
Dans la réalité aussi, le tissu a les mêmes propriétés. Un adversaire en robe ou en cape est beaucoup plus menaçant et plus difficile à affronter.
Personnellement, je n’apprécie pas les jeux FromSoft à cause de leur boucle de gameplay, mais sur le plan du design, je les considère comme faisant partie des jeux vidéo les mieux conçus de l’histoire.
J’ai aussi ma propre version, faite il y a 14 ans : https://www.youtube.com/watch?v=G05M_Y6NQVM
Je suis d’accord : cette configuration de base est très simple à implémenter, et le résultat est vraiment impressionnant.
C’est moi qui l’ai faite. La version originale publiée sur CodePen date d’il y a environ 13 ans.
J’ai moi-même du mal à y croire, mais quand je pense que c’était avant mon premier emploi de programmeur, ça me paraît vraiment remonter à très loin.
Le jeu vidéo Hitman, sorti en 2000, avait déjà du tissu, et Mirror's Edge, en 2008, avait du tissu déchirable. Aucun des deux n’était probablement le premier.
Ces simulateurs de tissu me semblent toujours un peu instables. Si on génère un tissu en grille, il se met à rebondir et à bouger de façon aléatoire.
Je me demande si c’est dû à l’accumulation d’erreurs de virgule flottante IEEE 754.
Dans le contexte des simulations physiques ou des moteurs de jeu, il vaut la peine de chercher du côté de l’intégration numérique. Pour commencer, on peut regarder https://en.wikipedia.org/wiki/Numerical_methods_for_ordinary...
D’après ce que je comprends, ce n’est pas seulement une simple erreur de virgule flottante : cela vient aussi de la nature même de l’approximation d’une fonction continue par des étapes discrètes simples. L’article Wikipédia lié contient d’ailleurs un graphique montrant qu’avec de grands pas, l’erreur s’accumule bien avant que la précision en virgule flottante ne devienne un problème.
Chaque technique d’intégration numérique a ses compromis. Il y a la méthode d’Euler, Verlet, Runge-Kutta, etc. Certaines méthodes ont tendance à accumuler de l’énergie totale, d’autres à en perdre, et dans les deux cas c’est un comportement incorrect. Les méthodes plus complexes se comportent généralement un peu mieux, mais il faut alors se demander si le gain de chaque étape plus complexe vaut mieux que de répéter davantage un algorithme plus simple et plus rapide.
En simulation physique, la conservation de l’énergie ne fonctionne pas par défaut si elle n’est pas codée explicitement. Par exemple, il faut une forme de correction directe périodique.
Les causes ne sont pas seulement les erreurs d’arrondi, mais aussi la quantification du temps et d’autres petites erreurs provenant du modèle mathématique lui-même.
Si l’erreur va dans le sens de l’amortissement, l’énergie se dissipe comme dans la réalité et le mouvement finit par s’arrêter ; si elle va dans le sens de l’accélération, la simulation s’emballe.
J’aimerais dire à l’auteur de ce site que c’est très bien fait. Il fonctionne tel quel, sans JavaScript externe, et marche aussi sur mobile.
On peut difficilement en dire autant de la plupart des sites web textuels aujourd’hui.
Travail vraiment impressionnant. C’est simple, mais on reste à le regarder, et cela montre bien à quel point l’intégration de Verlet est puissante pour produire une simulation de tissu naturelle et crédible.
Si le sujet vous intéresse, je recommande aussi l’article de Jakobsen issu du moteur de jeu Hitman. C’est une référence classique.
J’aime voir quelqu’un poser réellement les questions difficiles sur le fonctionnement de ce genre de choses. Cela me rappelle à chaque fois que tout se construit à partir d’une multitude de petites étapes accumulées pendant des années.
Je me demande si les gens se heurtent à un moment où les maths semblent être un mur, ou s’ils continuent simplement à taper dessus jusqu’à comprendre.
Ce qui me fascine le plus, c’est qu’avec seulement quelques paramètres et contraintes, on obtient des mouvements aussi réalistes.
Cela donne l’impression que le monde qui nous entoure n’est peut-être qu’un ensemble de modèles et de forces cachés, et que notre travail consiste à les découvrir et à les simuler. Très beau travail.
1 commentaires
Avis de Hacker News
Un autre exemple visible dans le navigateur : https://oimo.io/works/cloth/
Après avoir lu l’article de Marian Pekár et compris l’intégration de Verlet, j’ai pu créer moi-même une simulation de tissu : https://pikuma.com/blog/verlet-integration-2d-cloth-physics-...
Je me demande comment on passe de connaissances en développement web, Gradle et Java à la capacité de construire ce genre de chose
Comme je n’ai pas fait de licence d’informatique, j’ai parfois l’impression que, même en apprenant autant de langages de programmation que je veux, je ne comprendrai jamais ce genre de choses. J’ai un peu touché à OPENLY, LIBGDX, GODOT et Unity, mais créer une simulation de tissu à partir de zéro me paraît vraiment intimidant
Ici, on utilise une intégration de Verlet de base : on met à jour des vecteurs 2D formant une grille à partir de leur position actuelle et précédente, puis on impose des contraintes pour qu’ils gardent une certaine distance avec leurs voisins immédiats. Si on trace des lignes entre ces points, on obtient un tissu. En cherchant parce que les simulations physiques me fascinaient, je suis tombé dessus au début parce que c’est l’une des choses les plus faciles à implémenter, avec un très bon rapport effort/résultat. Bien sûr, après ça, cela devient beaucoup plus complexe
Quand on commence surtout par le développement de jeux, on a l’impression qu’il devrait exister une façon naturelle et idiomatique de programmer chaque grande simulation — corps rigides, tissu, ressorts, fluides, etc. Au début, je pensais que même la simulation de fluides s’exprimerait naturellement dans le langage, en créant une grille puis en choisissant des règles de mise à jour à chaque pas de temps. Mais en réalité, il faut modéliser le problème en mathématiques et en physique, puis le faire correspondre au langage et aux outils, et ces outils ne l’expriment pas toujours de façon idiomatique
Certains algorithmes, comme les positions de particules et les simulations de tissu à base de ressorts, se transposent facilement en code, mais cela m’a plutôt induit en erreur quand j’ai voulu aller plus loin. Au final, j’ai dû creuser davantage la physique et l’analyse numérique, puis traduire le problème en code, avec un résultat qui peut être rugueux et rempli de nombres magiques
À l’inverse, écrire une simulation implique beaucoup de calculs, donc la majeure partie du code constitue le contenu réel. Si le développement web est un assemblage d’éléments hétérogènes, la simulation est plus homogène. La contrainte, c’est la performance d’un seul processus dans le budget temporel fixé par le nombre d’images par seconde
On peut donc se concentrer sur un seul environnement d’exécution. Je recommande le navigateur, qui règle le problème du déploiement. Ganja[1] est peut-être le projet de simulation ultime du type « du contenu plutôt que de la structure ». Il est très particulier et difficile à comprendre, si bien que la maintenance s’est arrêtée, mais il fonctionne. Du côté un peu plus structuré, il y a D3, dont les auteurs ont déjà implémenté des algorithmes modernes de visualisation/mise en page, comme les graphes à forces[2]. Un point de départ plus accessible peut être la famille Processing[3], partie de Java puis portée vers Python, JavaScript, etc.
Cela dit, une seule simulation de tissu, si on la compare à un moteur de jeu, équivaut à peu près à une cellule d’une souris. Les moteurs de jeu sont très vastes et, même là, on finit souvent par faire beaucoup d’intégration interne plutôt que d’écrire directement des simulations
1 - https://github.com/enkimute/ganja.js/blob/master/ganja.js
2 - https://github.com/d3/d3-force/tree/main/src
3 - https://processing.org/
La question ne portait pas précisément sur le développement de jeux, mais les connaissances en graphisme, mathématiques, éclairage et physique y sont généralement très répandues. Si l’on cherche seulement un sujet de niche comme la simulation de tissu, il peut être difficile de trouver des informations qui ne soient pas liées aux ressources de développement de jeux
J’ai lu aujourd’hui https://alextardif.com/LearningGraphics.html, qui peut servir de guide dans plusieurs directions. https://learnopengl.com/ reste régulièrement bien considéré, même aujourd’hui avec des API plus récentes comme Vulkan, Metal et DX12. Mais il faut voir l’API comme environ 5 % du problème à résoudre. Honnêtement, c’est peut-être encore moins, même si Vulkan est plus lourd encore que ce que j’en avais entendu
Si vous ne voulez pas apprendre C/C++, la communauté WebGL est importante, donc vous pouvez commencer par les subreddits ou forums correspondants. Cela dit, l’API et la plateforme sont surtout une enveloppe autour de la partie vraiment impressionnante et nouvelle : la simulation physique elle-même
Pour donner mon contexte, je suis développeur web/Gradle/Java et, après une tentative il y a quelques années, je me remets à créer un moteur de jeu sur mon temps libre
Chaque fois qu’une particule tente de bouger, on transmet la force aux autres points à travers les arêtes avec de la trigonométrie, et on ajoute un peu d’amortissement pour éviter que ça ne s’emballe. La masse détermine ensuite à quel point chaque point est affecté par les forces. Si la 3D vous intimide, commencez en 2D
Cela me rappelle une vidéo de Polygon qui analyse l’incroyable conception des tissus dans Elden Ring : https://youtu.be/wSSqx-Dh6ko
Dans un jeu centré sur les combats au corps à corps et sur des hitboxes précises — ce qui est sans doute l’un des aspects les plus novateurs des jeux FromSoft — les tissus qui flottent librement rendent plus difficile de juger à quelle distance placer son personnage pour toucher, ou à quelle distance rester pour ne pas être touché. Ajoutez à cela des mouvements et des patterns d’attaque imprévisibles, et la difficulté augmente encore, chaque combat devenant unique.
Dans la réalité aussi, le tissu a les mêmes propriétés. Un adversaire en robe ou en cape est beaucoup plus menaçant et plus difficile à affronter.
Personnellement, je n’apprécie pas les jeux FromSoft à cause de leur boucle de gameplay, mais sur le plan du design, je les considère comme faisant partie des jeux vidéo les mieux conçus de l’histoire.
J’ai toujours aimé ce genre d’animation de tissu. La première que j’ai vue était probablement la démo de tissu déchirable sur CodePen de dissimulate, et j’ai du mal à croire que ce code a été écrit il y a 9 ans.
[1] - https://codepen.io/dissimulate/pen/eZxEBO
[2] - https://github.com/Dissimulate/Tearable-Cloth
Je suis d’accord : cette configuration de base est très simple à implémenter, et le résultat est vraiment impressionnant.
J’ai moi-même du mal à y croire, mais quand je pense que c’était avant mon premier emploi de programmeur, ça me paraît vraiment remonter à très loin.
Ces simulateurs de tissu me semblent toujours un peu instables. Si on génère un tissu en grille, il se met à rebondir et à bouger de façon aléatoire.
Je me demande si c’est dû à l’accumulation d’erreurs de virgule flottante IEEE 754.
D’après ce que je comprends, ce n’est pas seulement une simple erreur de virgule flottante : cela vient aussi de la nature même de l’approximation d’une fonction continue par des étapes discrètes simples. L’article Wikipédia lié contient d’ailleurs un graphique montrant qu’avec de grands pas, l’erreur s’accumule bien avant que la précision en virgule flottante ne devienne un problème.
Chaque technique d’intégration numérique a ses compromis. Il y a la méthode d’Euler, Verlet, Runge-Kutta, etc. Certaines méthodes ont tendance à accumuler de l’énergie totale, d’autres à en perdre, et dans les deux cas c’est un comportement incorrect. Les méthodes plus complexes se comportent généralement un peu mieux, mais il faut alors se demander si le gain de chaque étape plus complexe vaut mieux que de répéter davantage un algorithme plus simple et plus rapide.
Les causes ne sont pas seulement les erreurs d’arrondi, mais aussi la quantification du temps et d’autres petites erreurs provenant du modèle mathématique lui-même.
Si l’erreur va dans le sens de l’amortissement, l’énergie se dissipe comme dans la réalité et le mouvement finit par s’arrêter ; si elle va dans le sens de l’accélération, la simulation s’emballe.
J’aimerais dire à l’auteur de ce site que c’est très bien fait. Il fonctionne tel quel, sans JavaScript externe, et marche aussi sur mobile.
On peut difficilement en dire autant de la plupart des sites web textuels aujourd’hui.
Travail vraiment impressionnant. C’est simple, mais on reste à le regarder, et cela montre bien à quel point l’intégration de Verlet est puissante pour produire une simulation de tissu naturelle et crédible.
Si le sujet vous intéresse, je recommande aussi l’article de Jakobsen issu du moteur de jeu Hitman. C’est une référence classique.
J’aime voir quelqu’un poser réellement les questions difficiles sur le fonctionnement de ce genre de choses. Cela me rappelle à chaque fois que tout se construit à partir d’une multitude de petites étapes accumulées pendant des années.
Je me demande si les gens se heurtent à un moment où les maths semblent être un mur, ou s’ils continuent simplement à taper dessus jusqu’à comprendre.
Ce qui me fascine le plus, c’est qu’avec seulement quelques paramètres et contraintes, on obtient des mouvements aussi réalistes.
Cela donne l’impression que le monde qui nous entoure n’est peut-être qu’un ensemble de modèles et de forces cachés, et que notre travail consiste à les découvrir et à les simuler. Très beau travail.