Une technique pour simuler en temps réel les fluides, le feu et la fumée

 (andrewkchan.dev)
2 points par GN⁺ 2023-12-20 | 1 commentaires | Partager sur WhatsApp
  • La simulation de feu en temps réel sur GPU peut être implémentée sous forme de démo WebGL en combinant dynamique des fluides, calcul parallèle sur grille, modèles de combustion, de flottabilité et de rendu
  • Le modèle de base suppose un écoulement incompressible et non visqueux, et gagne en stabilité comme en parallélisme grâce à l’advection semi-lagrangienne, qui transporte des champs scalaires comme la teinture, la température et le combustible au moyen du champ de vitesse
  • Dans l’étape de Navier-Stokes, le champ de vitesse est advecté par lui-même, puis sa divergence est réduite par projection de pression ; l’équation de Poisson est traitée avec des méthodes d’approximation adaptées au GPU, comme les itérations de Jacobi
  • L’interpolation sur grille et la méthode semi-lagrangienne du premier ordre atténuent les tourbillons turbulents ; on renforce donc les petits détails de rotation avec le vorticity confinement et le curl noise
  • Le feu ajoute une densité de combustible et un champ de température pour calculer combustion, refroidissement et flottabilité thermique, puis est rendu avec une couleur de rayonnement de corps noir fondée sur la loi de Planck, ce qui fait apparaître un fluide de type fumée comme une flamme

Le flux complet pour simuler le feu sur GPU

  • Le feu est un problème intéressant en graphisme, mais par le passé il était généralement imité avec des méthodes non fondées sur la physique
    • Lord of the Rings utilisait de nombreux sprites de fumée, car la simulation de fluides était coûteuse
    • Les applications temps réel comme les jeux vidéo dépendaient elles aussi presque entièrement d’approches non physiques
  • Depuis une dizaine d’années, les GPU ont facilité la simulation de fluides rapide, et les algorithmes de base de dynamique des fluides sont assez intuitifs à implémenter sur GPU
    • ILM a utilisé ces techniques en 2009 pour modéliser et rendre le feu dans Harry Potter
    • NVIDIA a présenté en 2014 FlameWorks, un système d’effets de feu et de fumée pour les jeux
  • L’implémentation prend la forme d’une démo WebGL et, sur le plan mathématique, elle demande des bases en calcul vectoriel et en équations différentielles
  • Le code source est disponible sur GitHub

Modéliser d’abord le fluide

  • Avant de créer du feu, il faut simuler un fluide ; ici, on suppose un fluide incompressible et non visqueux (inviscid)
  • Un champ de vitesse 2D u(x, t) est représenté par une grille N × N, et chaque point de la grille contient la valeur de vitesse à cette position
  • Le processus par lequel un champ scalaire ψ(x, t), comme une densité de teinture, se déplace selon la vitesse du fluide s’appelle advection
  • Déplacer simplement chaque point de grille vers l’avant est difficile à paralléliser, plusieurs points pouvant se déplacer vers le même point cible, et la méthode peut devenir instable lorsque le pas de temps augmente

Une advection stable : la méthode semi-lagrangienne

  • En utilisant la loi de conservation de la masse et le théorème de la divergence, l’équation d’advection scalaire d’un écoulement incompressible se résume à ∂ψ/∂t = -u · ∇ψ
  • La méthode stable consiste, au lieu d’envoyer chaque point de grille vers l’avant le long de la vitesse, à remonter à rebours depuis le point de grille courant dans la direction de la vitesse afin de récupérer la valeur à la position précédente
  • Cette méthode est la Semi-Lagrangian advection, créée par Jos Stam en 1999
    • Chaque point de grille n’est mis à jour qu’une seule fois par itération, ce qui facilite la parallélisation sur GPU
    • Aucun point de grille n’est mis à jour avec une valeur supérieure au maximum des points de grille existants, ce qui la rend inconditionnellement stable
  • Si le champ de vitesse fixe satisfait la condition d’incompressibilité, il peut transporter de manière stable un champ scalaire comme une teinture

Mettre à jour le champ de vitesse avec Navier-Stokes

  • Les Navier-Stokes equations définissent la manière dont le champ de vitesse d’un fluide évolue dans le temps dans un écoulement incompressible
  • En supposant un fluide non visqueux, ce qui retire le terme de viscosité, et en ignorant pour commencer les forces externes, deux termes essentiels restent
    • la self-advection, où le champ de vitesse se transporte lui-même
    • la pressure, nécessaire pour satisfaire la condition d’incompressibilité
  • La boucle de simulation se déroule approximativement dans l’ordre suivant
    • advecter le champ de vitesse u par lui-même
    • calculer la pression p
    • soustraire le gradient de pression avec u = u - gradient(p) afin d’imposer l’incompressibilité
    • advecter le champ de densité avec le nouveau champ de vitesse

Le calcul de la pression est limité par l’équation de Poisson

  • Rien ne garantit que le champ de vitesse candidat u', obtenu après auto-advection, satisfasse la condition de divergence nulle ; il faut donc le corriger par la pression
  • En reformulant la condition, on obtient une Poisson equation de la forme ∇²p = ∇ · u'
  • En discrétisant la divergence et le laplacien sur la grille, on obtient, pour une grille N × N, un système linéaire comportant N² équations linéaires et N² inconnues
  • Les méthodes exactes de résolution de systèmes linéaires voient leur coût croître de façon superlinéaire avec la taille de la grille, ce qui les rend lourdes pour une simulation temps réel
  • Sur GPU, on peut chercher itérativement une approximation suffisamment bonne plutôt qu’une solution exacte
    • La Jacobi method met à jour en parallèle l’estimation de chaque élément, ce qui convient bien à une implémentation GPU
    • Des méthodes qui convergent plus vite, comme Conjugate Gradient et Multigrid, peuvent aussi être implémentées sur GPU
    • Pour la fumée et le feu, les variations de volume n’étant pas aussi évidentes que dans l’eau, la qualité de l’advection ou la simplicité d’implémentation peuvent compter davantage que la précision de la pression

Restaurer les détails de tourbillons

  • Stocker le champ de vitesse sur une grille provoque un lissage numérique indésirable lors de l’interpolation
  • Si l’on ajoute l’approximation grossière de l’advection semi-lagrangienne du premier ordre, les tourbillons turbulents disparaissent et le fluide devient trop lisse et monotone
  • Augmenter la résolution peut atténuer le problème, mais les ressources de calcul sont limitées en simulation temps réel
  • Le vorticity confinement consiste à repérer et amplifier, à chaque étape, les petits détails qui disparaissent
    • Ce n’est pas une méthode parfaitement réaliste, mais elle conserve des détails à petite échelle à des emplacements généralement cohérents physiquement
    • Elle a été conçue à l’origine pour traiter, dans des simulations d’ingénierie, les champs d’écoulement complexes autour des pales d’hélicoptère
  • On mesure la vorticité par le curl en chaque point de la grille, on calcule la direction dans laquelle la vorticité est élevée autour du point, puis on ajoute au champ de vitesse une force de rotation réglée par une constante de confinement ε > 0
    • De faibles valeurs de confinement, autour de 0–15, peuvent déjà faire une grande différence
    • Des valeurs plus élevées peuvent produire un écoulement billowing stylisé

Synthétiser la turbulence avec le curl noise

  • Le curl noise, au lieu de mesurer et d’amplifier la vorticité du champ de vitesse existant, crée un nouveau champ de vorticité scalaire à partir d’une fonction de bruit
  • Mathématiquement, on synthétise un champ de vorticité aléatoire φ = rand * z, puis on l’ajoute à la vorticité existante ω pour former la vorticité finale ω* = ω + φ
  • Les fluides rapides et fortement turbulents comme la fumée et le feu sont très sensibles au vorticity confinement et au curl noise
  • En pratique, le champ de curl noise φ varie dans le temps et est advecté avec l’écoulement du fluide

Ajouter combustible et température pour le feu

  • La routine de fluide de base permet déjà de créer un écoulement semblable à de la fumée ; pour simuler le feu et la fumée, quelques canaux supplémentaires sont nécessaires
  • Le modèle de combustion ajoute une densité de combustible ρ et un champ de température T
    • 0 ≤ ρ ≤ 1 est la densité de combustible
    • T > 0 est la température en chaque position
  • Ici, on suppose que le combustible présent dans le système est déjà enflammé et continue d’ajouter de la chaleur ; le problème du combustible non encore enflammé n’est pas traité
  • À chaque pas de temps, le combustible augmente la température selon une température de combustion donnée
    • La température est mise à jour sous la forme T' = max(T, ρ * T_burn)
  • La chaleur diffuse des zones chaudes vers les zones froides, et les grands mouvements du fluide transportent aussi la chaleur
    • Dans la simulation, le champ de température est advecté par le champ de vitesse
    • Les molécules réactives se déplaçant elles aussi avec le fluide, le champ de combustible est également advecté
  • Les molécules chaudes émettent leur température sous forme de lumière selon la loi de Stefan-Boltzmann
    • Une simulation physiquement exacte utiliserait la constante de Stefan-Boltzmann
    • Dans une simulation graphique, il est utile de permettre à l’artiste de régler le taux de refroidissement σ_cool
  • Le combustible diminue à chaque pas de temps selon le taux de combustion γ_fuel

Faire monter le fluide chaud avec la flottabilité thermique

  • Si l’on ne calcule que le champ de température, il n’a pas encore d’effet sur l’écoulement du fluide ; il faut ajouter l’effet qui fait monter l’air chaud et descendre l’air froid
  • La Thermal buoyancy ajoute au champ de vitesse une force vers le haut proportionnelle à la température
    • Comme on suppose un écoulement incompressible, l’expansion réelle de l’air n’est pas traitée
    • Le champ de vitesse est mis à jour sous la forme u' = u + (β T Δt) j
    • β est une constante de flottabilité positive et j est le vecteur unitaire vers le haut
  • En ajoutant le modèle de combustion et la flottabilité thermique, on peut obtenir un fluide qui ressemble à du feu
    • Avec des valeurs appropriées de flottabilité et de refroidissement, on obtient de grandes colonnes de matière gonflées
    • À ce stade, le résultat ressemble davantage à de la fumée qu’à de véritables flammes
  • La boucle complète suit l’ordre suivant : auto-advection de la vitesse, combustion, vorticity confinement, flottabilité thermique, projection de pression, puis advection de la densité, de la température et du combustible

Rendre la couleur des flammes avec le rayonnement de corps noir

  • Le feu est un participating medium et émet de la lumière par rayonnement de corps noir
  • Les couleurs orange et rouge du feu proviennent du rayonnement de corps noir ; en rendant une simulation de combustible en combustion avec les bonnes formules, on peut passer de la fumée au feu
  • La loi de Planck décrit la densité spectrale de la lumière émise par un corps noir à une température T donnée
  • En implémentant le rendu du corps noir dans un fragment shader, on peut construire une simulation complète de feu au-dessus des modèles de fluide, de combustion et de flottabilité
  • Plusieurs extensions restent non traitées
    • les techniques non fondées sur une grille pour résoudre une simulation dans un volume fixe
    • les problèmes à domaine variable, où le fluide occupe différentes régions de la grille, comme l’eau dans une tasse à moitié pleine
    • les obstacles dynamiques
    • les améliorations de rendu telles qu’un rayonnement de corps noir plus précis, la diffusion de la lumière et les effets de post-traitement

À lire aussi

1 commentaires

 
GN⁺ 2023-12-20
Avis de Hacker News

  • J’ai fait un doctorat en CFD, mais je n’avais encore jamais vu les techniques de confinement de la vorticité (vorticity confinement) ni de turbulence par bruit de rotationnel (curl-noise turbulence)
    Dans des domaines à nombre de Reynolds plus élevé, comme la CFD industrielle, chercher à compenser par du bruit la dissipation artificielle des méthodes numériques n’est généralement pas souhaitable
    Au contraire, on veut souvent de la dissipation artificielle pour stabiliser les simulations à haut nombre de Reynolds ; en infographie, il semble que ce qui compte davantage que l’exactitude physique, c’est que ça ait l’air plausible

    • La première règle de l’infographie temps réel a en fait presque toujours été : « triche autant que possible, tant que ça ne se voit pas — et souvent même si ça se voit »
      Il n’est même pas nécessaire que ça ait l’air exact, il suffit que ça ait de la gueule
    • C’est exactement ça
      En tant que passionné de physique, il m’est arrivé de faire rire les gens dans les salles d’arcade en pointant les scènes qui enfreignaient les lois de la physique
      Une interview traduite d’un physicien ayant travaillé sur Mario World chez Nintendo était intéressante : il y expliquait que la physique du monde de Mario, même si elle n’était pas la physique « réelle », avait des règles cohérentes comme la physique réelle, et soulignait que c’était important pour que les joueurs comprennent ce qu’ils pouvaient faire dans le jeu et résolvent les énigmes
    • L’article sur le curl noise semble dater de 2007 : https://www.cs.ubc.ca/~rbridson/docs/bridson-siggraph2007-cu...
      En utilisant l’idée de base de cet article, j’ai créé un programme assez correct pour générer des textures de planètes gazeuses : https://github.com/smcameron/gaseous-giganticus
    • J’ai malheureusement dû avoir ce genre de conversation plusieurs fois
      On m’a demandé plus d’une fois : « Pourquoi Unreal Engine le fait en quelques secondes, alors que votre logiciel de CFD met des heures pour une seule simulation ? »
    • Dommage de ne pas citer le véritable inventeur du confinement de la vorticité, Dr. John Steinhoff de l’University of Tennessee Space Institute
      https://en.wikipedia.org/wiki/John_Steinhoff
      https://en.wikipedia.org/wiki/Vorticity_confinement
      Il y a aussi des articles connexes :
      https://www.researchgate.net/publication/239547604_Modificat...
      https://www.researchgate.net/publication/265066926_Computati...

  • Il y a longtemps, après avoir lu un article quelque part, j’avais bricolé en C une simulation de flammes très simple, au niveau jouet
    Il suffit de fixer la luminosité de chaque pixel à la moyenne de celle des pixels immédiatement voisins, puis de calculer de bas en haut
    Ajoutez en bas quelques pixels « chauds » qui se déplacent de gauche à droite, et vous obtenez instantanément des flammes ; le code est très court et ça rend plutôt bien sans calcul différentiel

    • C’est l’opérateur laplacien
      En une dimension, c’est simplement la dérivée seconde, autrement dit la courbure : plus un pic est pointu, plus elle est négative ; plus un creux est pointu, plus elle est positive
      Modifier les valeurs en conséquence produit un effet de moyenne, et la forme discrétisée est littéralement une moyenne
      En réalité, vous faisiez du calcul différentiel depuis le début
      Connaître le chemin et l’emprunter sont deux choses différentes
      Il y a aussi une vidéo de 3Blue1Brown qui l’explique avec des graphismes intuitifs : https://youtube.com/watch?v=ToIXSwZ1pJU
    • « Fixer la luminosité de chaque pixel à la moyenne de celle des pixels immédiatement voisins », ça ressemble à une convolution

  • On parle de simulation de feu et de fumée pour les jeux, de simulation de fluides sur GPU, mais si ces effets tournent dans un jeu, le GPU n’est-il pas déjà occupé ?
    Faire tourner un problème de CFD tout en rendant l’image semble être une charge assez lourde
    Je me demande si ce genre de calcul peut tourner sur l’iGPU pendant que le dGPU s’occupe des tâches liées au rendu, ou si l’iGPU est trop faible et qu’il vaut mieux basculer sur le CPU

    • Réponse courte : le GPU n’est pas « déjà occupé »
      Les GPU modernes sont extrêmement puissants et peuvent gérer la physique, des passes de rendu sophistiquées, la simulation de fluides, le pathfinding d’unités de « l’IA de jeu », etc., à plus de 100 FPS
      Version longue : le temps entre les images d’un « diaporama » très rapide à plus de 60 FPS constitue le budget de frame, et il faut généralement, en 5 à 30 ms, calculer l’état de la frame suivante ainsi que ce qui est nécessaire au rendu
      Cela peut inclure le déplacement d’unités sur une carte, le calcul de la physique des flammes, la copie de textures de terrain, le rendu de sommets avec matériaux, etc. Dans beaucoup de moteurs de jeu, le GPU effectue des dizaines de ces calculs distincts à chaque frame
      Un GPU est fondamentalement un ordinateur auxiliaire relié à l’ordinateur principal : à chaque frame, on lui envoie plusieurs tâches, il renvoie des résultats, puis ces résultats sont assemblés pour donner l’apparence d’un jeu
      Presque personne n’utilise l’iGPU
      Il est en général complètement inutile par rapport au dGPU principal, donc on l’ignore
    • Maintenant que les LLM tournent aussi sur GPU, les GPU du futur devront partager leurs ressources entre graphismes, physique et IA des NPC
      L’époque où il faudra équilibrer tout ça promet d’être intéressante, et il semble probable que les ressources de calcul locales et distantes se répartissent de plus en plus la charge
    • À l’époque, on faisait parfois tourner les calculs PhysX sur un GPU dédié choisi pour ça
      Je me souviens avoir attribué ou remarqué ce réglage en regardant les murs se détruire en continu dans Red Faction
      C’était presque Minecraft, mais sur Mars avec un lance-roquettes

  • Il n’est pas nécessaire d’être en train de jouer pour utiliser un GPU
    Aujourd’hui, beaucoup de logiciels de rendu disposent aussi d’un mode GPU
    Cela dit, les algorithmes GPU sont fortement parallélisés, et sont donc souvent différents des algorithmes de simulation CPU

  • EmberGen est un logiciel vraiment dingue qui simule le feu et la fumée en temps réel sur des GPU grand public, avec en plus un workflow à base de nœuds qui facilite la création de nouveaux effets
    Des workflows qui prenaient autrefois des heures peuvent maintenant être ajustés en quelques minutes
    https://jangafx.com/software/embergen/
    Je pensais que cet article parlerait d’EmberGen, et honnêtement je trouve un peu dommage qu’EmberGen n’ait pas davantage attiré l’attention sur HN : https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
    Je n’ai aucun lien avec EmberGen/JangaFX, je suis juste un client satisfait

  • Si vous aimez ce genre de choses, Ten Minute Physics devrait aussi vous plaire
    En particulier le chapitre 17, « How to write an Eulerian Fluid Simulator with 200 lines of code », est excellent
    https://matthias-research.github.io/pages/tenMinutePhysics/i...

  • Je me demande quelles ressources recommander à quelqu’un passé des maths au génie logiciel pour débuter en simulation CFD
    Le sujet m’intéresse vraiment, mais cela fait longtemps que je n’ai pas fait de calcul vectoriel ni d’équations aux dérivées partielles, donc mes maths sont bien rouillées

    • Si vous vous intéressez davantage aux simulations physiques pour la recherche, je ne pourrai pas vraiment aider, mais pour les simulations orientées divertissement, difficile de battre SideFX Houdini
      https://www.youtube.com/watch?v=zxiqA8_CiC4
      La version gratuite non commerciale « Apprentice » ne limite que le rendu et les fonctions de collaboration
      C’est toutefois un outil assez profond
      Quand on vient du logiciel et qu’on passe à ce secteur, le workflow d’apprentissage de ce type d’outil est complètement différent
      Beaucoup disent que Houdini ressemble davantage à un IDE qu’à un logiciel de modélisation 3D, et je suis d’accord à bien des égards
      Au lieu d’utiliser un outil visuel comme Blender, on construit presque entièrement des réseaux de nœuds et on modifie des attributs et des paramètres
      On peut faire la majeure partie en Python, et c’est plus propre que quelque chose comme 3ds Max, mais comme ce n’est pas compilé, les performances sont mauvaises sur les grosses simulations
      Son propre langage de la famille C, VEX, est également utilisable, et il existe aussi un système de nœuds plus granulaire pour les travaux fins comme les maths plus complexes
      Techniquement, c’est presque entièrement un workflow orienté données
      En revanche, si vous êtes du genre à « apprendre en lisant la documentation », il va falloir vite tomber amoureux des tutoriels
      C’est très différent de tous les environnements ou paradigmes que j’ai manipulés, et la communauté est globalement bienveillante, mais la malédiction de l’expertise y est assez marquée
    • Postuler dans un endroit comme StarCCM pour travailler dans le domaine est aussi une option
    • J’ai fait ce travail autrefois comme contractant pour la NASA
      Si vous voulez vraiment en faire, le mieux est de décrocher un poste dans le domaine, et cela peut valoir le coup de postuler côté fédéral ou contractant au Marshall Space Flight Center ou à Ames
      À Ames, il y a les systèmes Aitken [#85, 9,07 PFlops], Pleiades [#132, 5,95 PFlops] et Electra [#143, 5,44 PFlops] selon le classement Top500
      Il y en a aussi quelques-uns au GRC, au LARC et au JSC
      Au moins il y a quelques années, l’intégration Contractor/Federal était plutôt bien faite et, hormis l’allocation des budgets, presque transparente
      À la NASA, les groupes Propulsion Structural, Thermal & Fluid Analysis [2][3] du MSFC et Entry Systems [4] d’Ames sont assez connus
      À l’époque, on utilisait Overflow/LARC [5] ou Loci/Mississippi State University [6] pour exécuter des simulations hybrides RANS/LES d’environ 100 millions de cellules, sur un véhicule ou un véhicule + pas de tir, avec maillages chimères mobiles, une dizaine à une vingtaine d’espèces chimiques de combustion réactives, et dynamique de particules lagrangiennes en évaporation
      Le SSME et les SRB étaient allumés ensemble, avec aussi le système de suppression par eau au lancement
      Mais ces informations datent d’il y a 10 ans, donc je ne connais pas l’état de l’art actuel, et les choses ont sans doute progressé depuis
      Si vous voulez comprendre les directions qui intéressent le secteur, l’ancienne CFD Vision 2030 Study de 2014 reste une introduction pas mauvaise [7]
      Obtenir un billet pour Supercomputing et y faire un tour peut aussi être une bonne idée
      Cette année, c’était à Denver [8]
      Mais l’accent est mis sur le « très grand », donc vous verrez surtout d’énormes simulations météo ou de la dynamique de nébuleuses
      J’aime la conférence elle-même, mais il est vrai qu’il est difficile d’attirer l’attention sans performances à grande échelle du type #CPUs/#GPUs/#FPGAs++
      Côté gouvernemental hors NASA, il y a le NIST (Gaithersburg), le DOE (Oak Ridge, Sandia, Los Alamos), l’Air Force (AF Research Lab) et Huntington Beach
      [1] NASA Advanced Supercomputing Division : https://en.wikipedia.org/wiki/NASA_Advanced_Supercomputing_D...
      [2] NASA, MSFC : https://www.nasa.gov/wp-content/uploads/2016/01/g-28367g_pst...

[3] Exemples un peu anciens : https://ntrs.nasa.gov/api/citations/20140016892/downloads/20...
[4] NASA Ames : https://www.nasa.gov/entry-systems-and-technology-division/
[5] OVERFLOW/NASA/LARC : https://overflow.larc.nasa.gov/
[6] Loci/MSU : https://simcenter.msstate.edu/
[7] Étude CFD Vision 2030 : https://ntrs.nasa.gov/api/citations/20140003093/downloads/20...
[8] Supercomputing SC23 : https://sc23.supercomputing.org/