La tecnología para simular fluidos, fuego y humo en tiempo real

 (andrewkchan.dev)
2 puntos por GN⁺ 2023-12-20 | 1 comentarios | Compartir por WhatsApp
  • La simulación de fuego en tiempo real basada en GPU puede implementarse como un demo en WebGL al combinar dinámica de fluidos, cómputo paralelo sobre rejilla y modelos de combustión, flotabilidad y renderizado
  • El modelo base asume un flujo incompresible y no viscoso, y obtiene estabilidad y paralelismo usando advección semi-Lagrangiana para transportar campos escalares como tinte, temperatura y combustible con el campo de velocidad
  • En la etapa de Navier-Stokes, el campo de velocidad se advecta a sí mismo y luego se reduce la divergencia con una proyección de presión; la ecuación de Poisson se resuelve con métodos aproximados amigables con GPU, como la iteración de Jacobi
  • Como la interpolación en rejilla y la advección semi-Lagrangiana de primer orden debilitan los remolinos turbulentos, se refuerzan los pequeños detalles de rotación con vorticity confinement y curl noise
  • El fuego se modela agregando campos de densidad de combustible y temperatura para calcular combustión, enfriamiento y flotabilidad térmica, y se renderiza con color de radiación de cuerpo negro basado en Planck’s Law para que un fluido tipo humo se vea como llamas

Flujo completo para simular fuego con GPU

  • El fuego es un problema interesante en gráficos, pero en el pasado normalmente se imitaba con métodos no basados en física
    • Lord of the Rings usó muchos sprites de humo porque la simulación de fluidos era costosa
    • Las aplicaciones en tiempo real, como los videojuegos, también dependían casi por completo de enfoques no físicos
  • En la última década, las GPU han facilitado la simulación de fluidos rápida, y los algoritmos básicos de dinámica de fluidos son intuitivos de implementar en GPU
    • ILM usó estas técnicas en 2009 para modelar y renderizar fuego en Harry Potter
    • NVIDIA presentó en 2014 FlameWorks, un sistema de efectos de fuego y humo para juegos
  • La implementación consiste en un demo en WebGL y, desde el punto de vista matemático, requiere bases de cálculo vectorial y ecuaciones diferenciales
  • El código fuente está en GitHub

Primero se modela el fluido

  • Antes de crear fuego, hay que simular un fluido; aquí se asume un fluido incompresible e inviscido
  • El campo de velocidad 2D u(x, t) se representa como una rejilla de N × N, y cada punto de la rejilla tiene el valor de velocidad en esa posición
  • El proceso en el que un campo escalar ψ(x, t), como la densidad de tinte, se mueve siguiendo la velocidad del fluido es la advección
  • Mover simplemente cada punto de la rejilla hacia adelante dificulta la paralelización, puede hacer que varios puntos lleguen al mismo punto de destino y puede volverse inestable cuando el intervalo de tiempo es grande

Advección estable: método semi-Lagrangiano

  • Usando la ley de conservación de la masa y el teorema de la divergencia, la ecuación de advección escalar para un flujo incompresible se escribe como ∂ψ/∂t = -u · ∇ψ
  • Un método estable, en vez de empujar cada punto hacia adelante siguiendo la velocidad, retrocede desde el punto actual en la dirección de la velocidad para tomar el valor de la posición anterior
  • Este método es la advección semi-Lagrangiana, creada por Jos Stam en 1999
    • Como cada punto de la rejilla se actualiza solo una vez por iteración, es fácil de paralelizar en GPU
    • Ningún punto de la rejilla se actualiza con un valor mayor que el máximo de los puntos existentes, así que es incondicionalmente estable
  • Si el campo de velocidad fijo cumple la condición de incompresibilidad, se pueden transportar de forma estable campos escalares como el tinte

El campo de velocidad se actualiza con Navier-Stokes

  • Las Navier-Stokes equations definen cómo cambia con el tiempo el campo de velocidad de un fluido en un flujo incompresible
  • Al asumir un fluido inviscido y omitir por ahora las fuerzas externas, quedan dos términos principales
    • La self-advection, donde el campo de velocidad se transporta a sí mismo
    • La pressure, necesaria para cumplir la condición de incompresibilidad
  • El ciclo de simulación sigue aproximadamente este orden
    • Advectar el campo de velocidad u consigo mismo
    • Calcular la presión p
    • Restar el gradiente de presión con u = u - gradient(p) para imponer incompresibilidad
    • Advectar el campo de densidad con el nuevo campo de velocidad

El cálculo de presión tiene como cuello de botella la ecuación de Poisson

  • No se puede garantizar que el campo de velocidad candidato u' obtenido tras la self-advection cumpla la condición de divergencia cero, así que debe corregirse con presión
  • Al ordenar la condición, se obtiene la Poisson equation con forma ∇²p = ∇ · u'
  • Al discretizar la divergencia y el Laplaciano sobre la rejilla, aparece un sistema lineal con N² ecuaciones lineales y N² incógnitas para una rejilla de N × N
  • Los métodos exactos para resolver el sistema lineal aumentan su costo de forma superlineal con el tamaño de la rejilla, así que son pesados para simulación en tiempo real
  • En GPU, en lugar de una solución exacta, se puede calcular iterativamente una aproximación suficientemente buena
    • El Jacobi method actualiza en paralelo la estimación de cada elemento, así que encaja bien en GPU
    • También pueden implementarse en GPU métodos que convergen más rápido, como Conjugate Gradient y Multigrid
    • En humo y fuego, como los cambios de volumen no son tan evidentes como en el agua, la calidad de la advección o la facilidad de implementación pueden importar más que la precisión de la presión

Recuperar el detalle de los remolinos

  • Al guardar el campo de velocidad en una rejilla, la interpolación introduce un suavizado numérico no deseado
  • Si además se suma la aproximación burda de la advección semi-Lagrangiana de primer orden, los remolinos turbulentos desaparecen y el fluido se vuelve demasiado suave y monótono
  • Aumentar la resolución puede aliviarlo, pero en simulación en tiempo real los recursos de cómputo son limitados
  • Vorticity confinement busca y amplifica en cada paso los pequeños detalles que se pierden
    • No es un método completamente realista, pero conserva detalles de pequeña escala en ubicaciones que suelen ser físicamente plausibles
    • Originalmente se ideó para tratar campos de flujo complejos alrededor de aspas de helicóptero en simulaciones de ingeniería
  • Se mide la vorticidad con el curl en cada punto de la rejilla, se calcula la dirección en la que la vorticidad es mayor alrededor y luego se suma al campo de velocidad una fuerza de rotación controlada por la constante de confinement ε > 0
    • Incluso un valor bajo de confinement, alrededor de 0–15, puede producir una gran diferencia
    • Valores más altos pueden crear flujos abultados y estilizados

Sintetizar turbulencia con curl noise

  • Curl noise no amplifica la vorticidad del campo de velocidad existente, sino que crea un nuevo campo escalar de vorticidad mediante una función de ruido
  • Matemáticamente, se sintetiza un campo de vorticidad aleatorio φ = rand * z, luego se suma a la vorticidad existente ω para obtener la vorticidad final ω* = ω + φ
  • Los fluidos que se mueven rápido y tienen mucha turbulencia, como el humo y el fuego, se ven muy afectados por vorticity confinement y curl noise
  • En la práctica, el campo de curl noise φ cambia con el tiempo y también se advecta con el flujo del fluido

Agregar combustible y temperatura para el fuego

  • Solo con la rutina base del fluido ya se puede crear un flujo parecido al humo, pero para simular fuego y humo hacen falta algunos canales más
  • El modelo de combustión agrega densidad de combustible ρ y campo de temperatura T
    • 0 ≤ ρ ≤ 1 es la densidad de combustible
    • T > 0 es la temperatura en cada posición
  • Aquí se asume que el combustible dentro del sistema ya está encendido y sigue aportando calor, y no se aborda el problema del combustible no encendido
  • En cada timestep, el combustible eleva la temperatura según una temperatura de combustión definida
    • La temperatura se actualiza como T' = max(T, ρ * T_burn)
  • El calor se difunde de las zonas calientes a las frías, y el flujo general del fluido también transporta el calor
    • En la simulación, el campo de temperatura se advecta con el campo de velocidad
    • Como las moléculas reactivas también se mueven con el fluido, el campo de combustible también se advecta
  • Las moléculas calientes emiten su temperatura en forma de luz según la Stefan-Boltzmann Law
    • En una simulación físicamente correcta se usaría la constante de Stefan-Boltzmann
    • En una simulación gráfica suele ser más útil que el artista pueda ajustar la tasa de enfriamiento σ_cool
  • El combustible disminuye en cada timestep según la tasa de combustión γ_fuel

Elevar el fluido caliente con flotabilidad térmica

  • Si solo se calcula el campo de temperatura, todavía no hay efecto sobre el flujo del fluido, así que hay que añadir el efecto de que el aire caliente sube y el aire frío baja
  • La thermal buoyancy agrega al campo de velocidad una fuerza hacia arriba proporcional a la temperatura
    • Como se asume un flujo incompresible, no se maneja la expansión real del aire
    • El campo de velocidad se actualiza como u' = u + (β T Δt) j
    • β es una constante positiva de flotabilidad y j es el vector unitario hacia arriba
  • Al combinar el modelo de combustión con la flotabilidad térmica se puede obtener un fluido que parezca fuego
    • Con valores adecuados de flotabilidad y enfriamiento se pueden obtener grandes columnas de materia hinchadas y ascendentes
    • El resultado en esta etapa todavía se parece más al humo que a una llama precisa
  • El ciclo completo queda compuesto por self-advection de la velocidad, combustión, vorticity confinement, flotabilidad térmica, proyección de presión y advección de densidad, temperatura y combustible

Renderizar el color de la llama con radiación de cuerpo negro

  • El fuego es un participating medium y emite luz mediante radiación de cuerpo negro
  • Los tonos naranjas y rojos del fuego provienen de la radiación de cuerpo negro, y si una simulación de combustible en combustión se renderiza con la fórmula correcta puede pasar de verse como humo a verse como fuego
  • La Planck’s Law describe la densidad espectral de la luz emitida por un cuerpo negro a una temperatura específica T
  • Si se implementa el renderizado de cuerpo negro en un fragment shader, se puede construir una simulación completa de fuego sobre el modelo de fluido, combustión y flotabilidad
  • Todavía quedan temas de extensión que no se abordan
    • Técnicas sin rejilla para resolver simulaciones dentro de un volumen fijo
    • Problemas de dominio variable, donde el fluido ocupa distintas regiones dentro de la rejilla, como el agua en un vaso medio lleno
    • Obstáculos dinámicos
    • Métodos de renderizado mejorados, como radiación de cuerpo negro más precisa, dispersión de luz y efectos de posprocesado

Lecturas relacionadas

1 comentarios

 
GN⁺ 2023-12-20
Opiniones de Hacker News

  • Hice un doctorado en CFD, pero es la primera vez que veo la técnica de confinamiento de vorticidad (vorticity confinement) y la turbulencia por ruido de rotacional (curl-noise turbulence)
    En ámbitos con números de Reynolds más altos, como en CFD industrial, por lo general no se quiere compensar con ruido la disipación artificial de los métodos numéricos
    Más bien, muchas veces se busca disipación artificial para estabilizar simulaciones con números de Reynolds altos, y en gráficos por computadora parece importar más que se vea creíble que que sea físicamente correcto

    • La primera regla de los gráficos por computadora en tiempo real prácticamente siempre ha sido “engaña lo suficiente como para que no se note; y normalmente, aunque se note, engaña lo más que puedas”
      Ni siquiera hace falta que parezca correcto; basta con que se vea genial
    • Eso es correcto
      Como nerd de la física, en las arcades la gente solía reírse cuando señalaba escenas que violaban las leyes de la física
      Fue interesante una entrevista traducida a un físico que trabajó en Mario World en Nintendo: enfatizaba que, aunque la física del mundo de Mario no fuera igual a la física “real”, tenía reglas coherentes como la física real, y eso era importante para que los jugadores entendieran qué podían hacer en el juego y resolvieran acertijos
    • El paper de curl noise parece ser de 2007: https://www.cs.ubc.ca/~rbridson/docs/bridson-siggraph2007-cu...
      Usé la idea básica de ese paper para hacer un programa bastante decente que genera texturas de planetas gaseosos: https://github.com/smcameron/gaseous-giganticus
    • Lamentablemente tuve que tener esta conversación varias veces
      Más de una vez me preguntaron: “¿por qué Unreal Engine lo hace en unos segundos, pero tu software de CFD tarda horas en una sola simulación?”
    • Es una lástima que no se haya citado al verdadero inventor del confinamiento de vorticidad, el Dr. John Steinhoff del University of Tennessee Space Institute
      https://en.wikipedia.org/wiki/John_Steinhoff
      https://en.wikipedia.org/wiki/Vorticity_confinement
      También hay papers relacionados:
      https://www.researchgate.net/publication/239547604_Modificat...
      https://www.researchgate.net/publication/265066926_Computati...

  • Hace tiempo leí un artículo en algún lado e hice en C una simulación de fuego muy simple, a nivel de juguete
    Basta con poner el brillo de cada píxel como el promedio del brillo de los píxeles inmediatamente vecinos y calcular de abajo hacia arriba
    Si agregas abajo unos cuantos píxeles “calientes” que se muevan de izquierda a derecha, obtienes fuego al instante; requiere muy poco código y, sin cálculo diferencial, se ve bastante genial

    • Eso es el operador laplaciano
      En una dimensión es simplemente la segunda derivada, es decir, la curvatura: cuanto más agudo es un pico, más negativa; cuanto más agudo es un valle, más positiva
      Si cambias el valor en esa medida, obtienes un efecto de promediado, y su forma discretizada es literalmente sacar promedios
      En realidad estabas haciendo cálculo todo el tiempo
      Una cosa es conocer el camino y otra recorrerlo
      También hay un video de 3Blue1Brown que lo explica con gráficos intuitivos: https://youtube.com/watch?v=ToIXSwZ1pJU
    • “Poner el brillo de cada píxel como el promedio del brillo de los píxeles inmediatamente vecinos” suena a convolución

  • Se habla de simulación de fuego y humo para juegos, y de simulación de fluidos en GPU, pero me pregunto si, cuando estos efectos corren en un juego, la GPU no está ya ocupada
    Correr un problema de CFD y renderizar al mismo tiempo parece una carga bastante grande
    También me da curiosidad si se podría correr esto en la iGPU mientras la dGPU hace tareas relacionadas con el renderizado, o si la iGPU es demasiado débil y sería mejor pasarlo a la CPU

    • La respuesta corta es que la GPU no está “ya ocupada”
      Las GPU modernas son muy potentes y pueden manejar física, pases de renderizado vistosos, simulación de fluidos, pathfinding de unidades de “IA de juego”, etc., a más de 100 FPS
      La respuesta larga es que el tiempo entre renderizar frames de una “presentación de diapositivas” muy rápida de más de 60 FPS es el presupuesto de frame, y normalmente hay que calcular el estado del siguiente frame y los cálculos necesarios para renderizarlo en unos 5 a 30 ms
      Ahí pueden entrar cosas como mover unidades por el mapa, calcular la física de las llamas, copiar texturas del terreno, renderizar vértices con materiales, etc.; en muchos motores de juego, la GPU realiza decenas de estos cálculos separados por cada frame
      Básicamente, la GPU es una computadora auxiliar conectada a la computadora principal: en cada frame se le envían varias tareas, entrega resultados y esos resultados se combinan para que se vea como un juego
      Casi nadie usa la iGPU
      Normalmente es completamente inútil comparada con la dGPU principal, así que se la ignora
    • Ahora que los LLM también corren en la GPU, las GPU del futuro tendrán que repartir recursos entre gráficos, física e IA para NPC
      La época de equilibrar eso se pondrá interesante, y parece que cada vez más los recursos de cómputo locales y remotos se repartirán la carga
    • Antes los cálculos de PhysX solían ejecutarse en una GPU dedicada seleccionada
      Recuerdo haber asignado o notado esa configuración mientras veía paredes romperse constantemente en Red Faction
      Era casi como Minecraft, pero en Marte y con un lanzacohetes

  • No hace falta estar jugando para usar la GPU
    Hoy en día también hay mucho software de renderizado con modo GPU
    Pero los algoritmos para GPU suelen estar altamente paralelizados, así que muchas veces son distintos de los algoritmos de simulación para CPU

  • EmberGen es un software realmente impresionante que simula fuego y humo en tiempo real en GPUs de consumo, y además admite flujos de trabajo basados en nodos, lo que facilita crear efectos nuevos
    Flujos de trabajo que antes tomaban horas ahora se pueden ajustar en cuestión de minutos
    https://jangafx.com/software/embergen/
    Pensé que este artículo iba a tratar sobre EmberGen y, sinceramente, me da un poco de pena que EmberGen no haya recibido mucha atención en HN: https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
    No tengo relación con EmberGen/JangaFX; solo soy un cliente satisfecho

  • Si te gustan este tipo de cosas, Ten Minute Physics también te puede resultar interesante
    En particular, el capítulo 17, “How to write an Eulerian Fluid Simulator with 200 lines of code”, es muy bueno
    https://matthias-research.github.io/pages/tenMinutePhysics/i...

  • Me pregunto qué materiales recomendarían para que alguien que pasó de estudiar matemáticas a ser ingeniero de software se inicie en la simulación CFD
    El tema me parece fascinante, pero hace mucho que no hago cálculo vectorial ni ecuaciones diferenciales parciales, así que tengo las matemáticas bastante oxidadas

    • Si te interesa más la simulación física para investigación, no puedo ayudar mucho; pero si hablamos de simulación orientada al entretenimiento, es difícil superar a SideFX Houdini
      https://www.youtube.com/watch?v=zxiqA8_CiC4
      La versión gratuita no comercial “Apprentice” solo limita el renderizado y las funciones de colaboración
      Eso sí, es una herramienta bastante profunda
      Si vienes del mundo del software a esta industria, el flujo de trabajo para aprender este tipo de herramientas es completamente distinto
      Mucha gente dice que Houdini se parece más a un IDE que a un programa de modelado 3D, y en muchos sentidos estoy de acuerdo
      En lugar de usar una herramienta visual como Blender, casi todo consiste en construir redes de nodos y modificar atributos y parámetros
      Puedes hacer la mayor parte en Python, y es más limpio que cosas como 3ds Max, pero al no estar compilado, el rendimiento es malo en simulaciones grandes
      Su propio lenguaje de la familia de C, VEX, también es bastante usable, y además hay un sistema de nodos más granular para trabajos finos como matemáticas más complejas
      En lo técnico, casi todo es un flujo de trabajo orientado a datos
      Pero si eres del tipo que “aprende leyendo la documentación”, vas a tener que aprender a amar los tutoriales rápidamente
      Es muy distinto de cualquier entorno o paradigma que haya usado, y aunque la comunidad suele ser amable, sufre bastante de la maldición del conocimiento
    • Otra opción es postularte a un lugar como StarCCM y trabajar en ese campo
    • Antes hice este trabajo como contratista de la NASA
      Si de verdad quieres hacerlo, lo mejor es conseguir un empleo en el área; podrías postularte por la vía federal o como contratista en Marshall Space Flight Center o Ames
      Ames tiene los sistemas Aitken [#85, 9.07 PFlops], Pleiades [#132, 5.95 PFlops] y Electra [#143, 5.44 PFlops] según el Top500
      También hay algo en GRC, LARC y JSC
      Al menos hasta hace unos años, la integración entre contratistas y personal federal era bastante buena, y salvo por la asignación de dinero, era casi transparente
      Dentro de la NASA, los grupos Propulsion Structural, Thermal & Fluid Analysis [2][3] de MSFC y Entry Systems [4] de Ames son bastante conocidos
      En esa época usábamos Overflow/LARC [5] o Loci/Mississippi State University [6] para correr simulaciones Hybrid RANS/LES de un vehículo, o de un vehículo más plataforma de lanzamiento, de unos 100 millones de celdas, con mallas superpuestas móviles, unas 10 a 20 especies químicas de combustión reactiva y dinámica de partículas lagrangianas en evaporación
      Incluía el encendido conjunto del SSME y los SRB, y también el sistema de supresión de agua durante el lanzamiento
      Pero esa información es de hace 10 años, así que no sé cuál es el estado del arte actual; seguramente ya avanzaron más
      Si quieres entender hacia dónde mira la industria, aunque ya tiene sus años, el CFD Vision 2030 Study de 2014 no es un mal material introductorio [7]
      También es buena idea conseguir una entrada para Supercomputing y recorrerlo
      Este año fue en Denver [8]
      Eso sí, el foco está en lo “grande”, así que principalmente verás simulaciones meteorológicas enormes o dinámica de nebulosas
      Me gusta la conferencia en sí, pero sin logros de escala tipo #CPUs/#GPUs/#FPGAs++ es difícil llamar la atención
      Fuera de la NASA, del lado del gobierno están NIST(Gaithersburg), DOE(Oak Ridge, Sandia, Los Alamos), Air Force(AF Research Lab) y 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] Ejemplos algo antiguos: 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] Estudio CFD Vision 2030: https://ntrs.nasa.gov/api/citations/20140003093/downloads/20...
[8] Supercomputing SC23: https://sc23.supercomputing.org/