A tecnologia para simular fluidos, fogo e fumaça em tempo real

 (andrewkchan.dev)
2 pontos por GN⁺ 2023-12-20 | 1 comentários | Compartilhar no WhatsApp
  • A simulação de fogo em tempo real baseada em GPU pode ser implementada como um demo em WebGL ao combinar dinâmica dos fluidos, computação paralela em grade e modelos de combustão, empuxo e renderização
  • O modelo básico assume um fluxo incompressível e invíscido, e obtém estabilidade e paralelismo com advecção semi-Lagrangiana, que transporta campos escalares como corante, temperatura e combustível pelo campo de velocidade
  • Na etapa de Navier-Stokes, o campo de velocidade é advectado por si mesmo e, em seguida, a divergência é reduzida com projeção de pressão; a equação de Poisson é tratada com solucionadores aproximados amigáveis para GPU, como iteração de Jacobi
  • Como a interpolação na grade e o método semi-Lagrangiano de primeira ordem enfraquecem os vórtices turbulentos, vorticity confinement e curl noise reforçam pequenos detalhes rotacionais
  • O fogo adiciona campos de densidade de combustível e temperatura para calcular combustão, resfriamento e empuxo térmico, e é renderizado com cores de radiação de corpo negro baseadas na Lei de Planck, fazendo um fluido semelhante à fumaça parecer uma chama

O fluxo completo para simular fogo com GPU

  • O fogo é um problema interessante em computação gráfica, mas no passado geralmente era imitado com métodos não baseados em física
    • Lord of the Rings usou muitas sprites de fumaça porque a simulação de fluidos era cara
    • Aplicações em tempo real, como videogames, também dependiam quase inteiramente de abordagens não físicas
  • Nos últimos 10 anos, graças à GPU, a simulação de fluidos rápida ficou muito mais acessível, e os algoritmos básicos de dinâmica dos fluidos são intuitivos de implementar na GPU
    • A ILM usou esse tipo de técnica em 2009 para modelar e renderizar o fogo de Harry Potter
    • A NVIDIA apresentou em 2014 o FlameWorks, um sistema de efeitos de fogo e fumaça para jogos
  • A implementação é organizada como um demo em WebGL e, do ponto de vista matemático, exige base em cálculo vetorial e equações diferenciais
  • O código-fonte está no GitHub

Primeiro, modelando o fluido

  • Antes de criar o fogo, é preciso simular um fluido; aqui assume-se um fluido incompressível e invíscido
  • O campo de velocidade 2D u(x, t) é representado por uma grade N × N, e cada ponto da grade tem o valor da velocidade naquela posição
  • O processo em que um campo escalar ψ(x, t), como a densidade de corante, se move de acordo com a velocidade do fluido é a advecção
  • Simplesmente mover cada ponto da grade para frente dificulta a paralelização, permite que vários pontos se desloquem para o mesmo ponto de destino e pode se tornar instável quando o intervalo de tempo aumenta

Advecção estável: método semi-Lagrangiano

  • Usando a lei de conservação de massa e o teorema da divergência, a equação de advecção escalar para fluxo incompressível pode ser escrita como ∂ψ/∂t = -u · ∇ψ
  • Em vez de enviar cada ponto da grade para frente segundo a velocidade, um método estável rastreia para trás a partir do ponto atual na direção da velocidade e busca o valor da posição anterior
  • Esse método é a advecção Semi-Lagrangiana, criada por Jos Stam em 1999
    • Cada ponto da grade é atualizado apenas uma vez por iteração, o que facilita a paralelização na GPU
    • Nenhum ponto da grade é atualizado para um valor maior que o máximo dos pontos existentes, então o método é incondicionalmente estável
  • Se um campo de velocidade fixo satisfaz a condição de incompressibilidade, ele pode transportar de forma estável campos escalares como corante

Atualizando o campo de velocidade com Navier-Stokes

  • As equações de Navier-Stokes definem como o campo de velocidade de um fluido evolui no tempo em um fluxo incompressível
  • Assumindo um fluido invíscido, remove-se o termo de viscosidade e, ignorando forças externas por enquanto, restam dois termos principais
    • self-advection, em que o campo de velocidade transporta a si mesmo
    • pressure, para satisfazer a condição de incompressibilidade
  • O loop de simulação segue aproximadamente esta ordem
    • advectar o campo de velocidade u por ele mesmo
    • calcular a pressão p
    • subtrair o gradiente de pressão com u = u - gradient(p) para impor incompressibilidade
    • advectar o campo de densidade com o novo campo de velocidade

O cálculo da pressão tem a equação de Poisson como gargalo

  • O campo de velocidade candidato u' obtido após a self-advection não garante satisfazer a condição de divergência zero, então ele precisa ser corrigido pela pressão
  • Reorganizando a condição, obtém-se uma equação de Poisson na forma ∇²p = ∇ · u'
  • Ao discretizar a divergência e o Laplaciano na grade, surge um sistema linear com N² equações lineares e N² incógnitas para uma grade N × N
  • Métodos exatos para resolver esse sistema linear têm custo que cresce de forma superlinear com o tamanho da grade, o que pesa em simulações em tempo real
  • Na GPU, em vez de uma solução exata, é possível encontrar iterativamente uma aproximação suficientemente boa
    • O método de Jacobi atualiza em paralelo a estimativa de cada elemento, o que se encaixa bem na implementação em GPU
    • Solvers que convergem mais rápido, como Conjugate Gradient e Multigrid, também podem ser implementados em GPU
    • Em fumaça e fogo, como as mudanças de volume não são tão evidentes quanto na água, a qualidade da advecção ou a facilidade de implementação pode ser mais importante que a precisão da pressão

Recuperando os detalhes dos redemoinhos

  • Ao armazenar o campo de velocidade em uma grade, o processo de interpolação gera uma suavização numérica indesejada
  • Somando a isso a aproximação grosseira da advecção semi-Lagrangiana de primeira ordem, os vórtices turbulentos desaparecem e o fluido fica excessivamente suave e monótono
  • Aumentar a resolução pode aliviar o problema, mas em simulação em tempo real os recursos computacionais são limitados
  • Vorticity confinement é uma técnica que encontra e amplifica, a cada passo, pequenos detalhes que desaparecem
    • Não é um método totalmente realista, mas preserva detalhes de pequena escala em posições geralmente compatíveis com a física
    • Originalmente, foi criado para lidar com campos de escoamento complexos ao redor de pás de helicóptero em simulações de engenharia
  • Mede-se a vorticidade pelo curl em cada ponto da grade, calcula-se a direção em que a vorticidade ao redor é maior e adiciona-se ao campo de velocidade uma força rotacional controlada por uma constante de confinement ε > 0
    • Mesmo valores baixos de confinement, em torno de 0–15, já produzem grande diferença
    • Valores mais altos podem criar fluxos volumosos e estilizados

Sintetizando turbulência com curl noise

  • Curl noise, em vez de medir e amplificar a vorticidade do campo de velocidade existente, cria um novo campo escalar de vorticidade com uma função de ruído
  • Matematicamente, sintetiza-se um campo aleatório de vorticidade φ = rand * z e depois ele é somado à vorticidade existente ω, formando a vorticidade final ω* = ω + φ
  • Fluidos que se movem rapidamente e têm muita turbulência, como fumaça e fogo, são bastante afetados por vorticity confinement e curl noise
  • Na prática, o campo de curl noise φ varia ao longo do tempo e também é advectado junto com o escoamento do fluido

Adicionando combustível e temperatura para o fogo

  • Só com a rotina básica de fluidos já é possível criar um escoamento parecido com fumaça, mas para simular fogo e fumaça são necessários alguns canais a mais
  • O modelo de combustão adiciona a densidade de combustível ρ e o campo de temperatura T
    • 0 ≤ ρ ≤ 1 representa a densidade de combustível
    • T > 0 representa a temperatura em cada posição
  • Aqui assume-se que o combustível no sistema já está aceso e continua adicionando calor; o problema do combustível ainda não inflamado não é tratado
  • A cada timestep, o combustível eleva a temperatura de acordo com uma temperatura de combustão definida
    • A temperatura é atualizada na forma T' = max(T, ρ * T_burn)
  • O calor se difunde das regiões quentes para as frias, e o grande escoamento do fluido também transporta calor
    • Na simulação, o campo de temperatura é advectado pelo campo de velocidade
    • Como as moléculas reativas também se movem junto com o fluido, o campo de combustível também é advectado
  • Moléculas quentes irradiam sua temperatura como luz segundo a Lei de Stefan-Boltzmann
    • Em uma simulação fisicamente correta, usa-se a constante de Stefan-Boltzmann
    • Em simulação gráfica, costuma ser mais útil permitir que o artista ajuste a taxa de resfriamento σ_cool
  • O combustível diminui a cada timestep de acordo com a taxa de combustão γ_fuel

Elevando o fluido quente com empuxo térmico

  • Se apenas o campo de temperatura for calculado, ele ainda não afeta o escoamento do fluido; então é preciso adicionar o efeito do ar quente subindo e do ar frio descendo
  • Empuxo térmico adiciona ao campo de velocidade uma força para cima proporcional à temperatura
    • Como se assume fluxo incompressível, a expansão real do ar não é tratada
    • O campo de velocidade é atualizado na forma u' = u + (β T Δt) j
    • β é uma constante de empuxo positiva e j é o vetor unitário para cima
  • Ao combinar o modelo de combustão com empuxo térmico, é possível criar um fluido com aparência de fogo
    • Com valores adequados de empuxo e resfriamento, obtém-se uma grande coluna de matéria inflada e ascendente
    • O resultado nesta etapa ainda se parece mais com fumaça do que com uma chama precisa
  • O loop completo consiste em self-advection da velocidade, combustão, vorticity confinement, empuxo térmico, projeção de pressão e advecção de densidade, temperatura e combustível

Renderizando a cor da chama com radiação de corpo negro

  • O fogo é um participating medium e emite luz por radiação de corpo negro
  • As cores laranja e vermelha do fogo vêm da radiação de corpo negro, e ao renderizar corretamente a simulação de combustível em combustão com a fórmula adequada, é possível passar de fumaça para fogo
  • A Lei de Planck descreve a densidade espectral da luz emitida por um corpo negro à temperatura T
  • Implementando a renderização de corpo negro em um fragment shader, é possível construir uma simulação completa de fogo sobre os modelos de fluido, combustão e empuxo
  • Ainda restam temas de extensão que não foram abordados
    • técnicas sem grade para resolver simulações em um volume fixo
    • problemas de domínio variável, em que o fluido ocupa regiões diferentes dentro da grade, como água em um copo meio cheio
    • obstáculos dinâmicos
    • formas de melhorar a renderização, como radiação de corpo negro mais precisa, espalhamento de luz e efeitos de pós-processamento

Leituras relacionadas

1 comentários

 
GN⁺ 2023-12-20
Comentários do Hacker News

  • Tenho um doutorado em CFD, mas foi a primeira vez que vi as técnicas de confinamento de vorticidade e turbulência com ruído curl
    Em domínios com números de Reynolds mais altos, como no CFD industrial, normalmente não se quer uma abordagem que tente compensar a dissipação artificial dos métodos numéricos com ruído
    Pelo contrário, muitas vezes deseja-se dissipação artificial para estabilizar simulações de alto número de Reynolds, e em computação gráfica parece que o mais importante não é estar fisicamente correto, mas parecer plausível

  • Li algo em algum lugar há muito tempo e cheguei a fazer uma simulação de chamas extremamente simples, de nível brinquedo, em C
    Basta definir o brilho de cada pixel como a média do brilho dos pixels imediatamente adjacentes e calcular de baixo para cima
    Se você só adicionar alguns pixels “quentes” na parte de baixo, movendo-se para os lados, surge fogo instantaneamente; o código é mínimo e, mesmo sem cálculo, fica bem legal

    • Isso é o operador laplaciano
      Em uma dimensão, é apenas a segunda derivada, ou seja, a curvatura; quanto mais pontudo o pico, mais negativo, e quanto mais pontudo o vale, mais positivo
      Mudar o valor nessa proporção produz um efeito de suavização, e sua forma discretizada é literalmente tirar a média
      Na verdade, você esteve fazendo cálculo o tempo todo
      Conhecer o caminho e caminhar por ele são coisas diferentes
      Há também um vídeo do 3Blue1Brown explicando isso com gráficos intuitivos: https://youtube.com/watch?v=ToIXSwZ1pJU
    • “Definir o brilho de cada pixel como a média do brilho dos pixels imediatamente adjacentes” soa como uma convolução

  • Estão falando de simulação de fogo e fumaça para jogos e de simulação de fluidos na GPU, mas se esses efeitos rodam em jogos, dá a impressão de que a GPU já estaria ocupada
    Rodar um problema de CFD e renderizar ao mesmo tempo parece uma carga bem pesada
    Também tenho curiosidade se isso pode rodar na iGPU enquanto a dGPU cuida do trabalho de renderização, ou se a iGPU é fraca demais e seria melhor simplesmente mandar isso para a CPU

    • A resposta curta é que a GPU não está “já ocupada”
      As GPUs de hoje são muito poderosas e conseguem processar física, passes de renderização sofisticados, simulações de fluidos e busca de caminhos de unidades de “IA de jogo” a mais de 100 FPS
      A resposta longa é que o tempo entre renderizar quadros de um “slideshow” muito rápido, acima de 60 FPS, é o orçamento de frame, e normalmente há de 5 a 30 ms para fazer os cálculos necessários para o estado do próximo frame e para a renderização
      Isso pode incluir mover unidades no mapa, calcular a física do fogo, copiar texturas de terreno, renderizar vértices com materiais etc., e em muitos motores de jogo a GPU realiza dezenas desses cálculos separados por frame
      A GPU é basicamente um computador auxiliar conectado ao computador principal; você envia vários trabalhos a cada frame, ela devolve os resultados, e então tudo isso é combinado para parecer um jogo
      Quase ninguém usa iGPU
      Em geral ela é tão inútil em comparação com a dGPU principal que costuma ser ignorada
    • Agora que LLMs também rodam em GPU, as GPUs do futuro terão que dividir recursos entre gráficos, física e IA para NPCs
      Deve ser interessante essa era de equilibrar isso, e parece provável que os recursos de computação locais e remotos passem cada vez mais a compartilhar a carga
    • Antigamente, os cálculos de PhysX às vezes eram executados em uma GPU dedicada opcional
      Lembro de ter atribuído essa configuração, ou pelo menos percebido isso, ao ver as paredes se despedaçando o tempo todo em Red Faction
      Era quase Minecraft, mas em Marte com um lançador de foguetes

  • Para usar a GPU, não é necessário estar jogando
    Hoje em dia também existem muitos softwares de renderização com modo GPU
    Só que os algoritmos de GPU costumam ser diferentes dos algoritmos de simulação em CPU, porque são altamente paralelizados

  • EmberGen é um software realmente insano que simula fogo e fumaça em tempo real em GPUs de consumo e ainda oferece um fluxo de trabalho baseado em nós, o que facilita criar novos efeitos
    Um fluxo de trabalho que antes levava horas agora pode ser ajustado em poucos minutos
    https://jangafx.com/software/embergen/
    Achei que este texto seria sobre o EmberGen e, sinceramente, é um pouco uma pena que o EmberGen não tenha recebido tanta atenção no HN: https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
    Não tenho relação com EmberGen/JangaFX, sou apenas um cliente satisfeito

  • Se você gosta desse tipo de coisa, Ten Minute Physics também pode ser divertido
    Principalmente o capítulo 17, “How to write an Eulerian Fluid Simulator with 200 lines of code”
    https://matthias-research.github.io/pages/tenMinutePhysics/i...

  • Tenho curiosidade sobre quais materiais seriam recomendados para alguém que saiu da matemática para engenharia de software e quer começar em simulação CFD
    Esse tema é realmente fascinante, mas faz muito tempo que não mexo com cálculo vetorial ou equações diferenciais parciais, então minha matemática está bem enferrujada

    • Se seu interesse é mais em simulação física para pesquisa, não consigo ajudar muito, mas para simulação voltada a entretenimento é difícil superar o SideFX Houdini
      https://www.youtube.com/watch?v=zxiqA8_CiC4
      A versão gratuita não comercial “Apprentice” só tem limitações em renderização e colaboração
      Mas é uma ferramenta bem profunda
      Para quem vem de software para esse setor, o fluxo de trabalho de aprender uma ferramenta dessas é completamente diferente
      Muita gente diz que o Houdini se parece mais com uma IDE do que com um programa de modelagem 3D, e em muitos aspectos eu concordo
      Em vez de usar ferramentas visuais como o Blender, você basicamente constrói redes de nós e ajusta atributos e parâmetros para quase tudo
      Dá para fazer a maior parte em Python e é mais limpo do que algo como o 3ds Max, mas como não é compilado, o desempenho fica ruim em simulações grandes
      A linguagem própria deles, parecida com C, chamada VEX, também é bastante útil, e há um sistema de nós mais granular para trabalhos mais detalhados, como matemática mais complexa
      Do ponto de vista técnico, é quase tudo um fluxo de trabalho orientado a dados
      Mas, se você é do tipo que “aprende lendo documentação”, vai ter que aprender a gostar de tutoriais rapidamente
      É muito diferente de qualquer ambiente ou paradigma com que eu já tenha trabalhado, e a comunidade em geral é gentil, mas sofre bastante com a maldição do conhecimento
    • Outra opção é se candidatar a lugares como a StarCCM e trabalhar na área
    • Eu fazia esse tipo de trabalho como contratado da NASA
      Se você realmente quer isso, o ideal é conseguir um emprego na área e vale a pena tentar vagas federais ou de contratadas no Marshall Space Flight Center ou em Ames
      Em Ames existem os sistemas Aitken [#85, 9.07 PFlops], Pleiades [#132, 5.95 PFlops] e Electra [#143, 5.44 PFlops] segundo o Top500
      GRC, LARC e JSC também têm alguma coisa
      Pelo menos alguns anos atrás, a integração Contractor/Federal funcionava muito bem e, tirando a questão de alocação de verba, era quase transparente
      Dentro da NASA, o grupo Propulsion Structural, Thermal & Fluid Analysis [2][3] do MSFC e o grupo Entry Systems [4] de Ames são bastante conhecidos
      Na época, usávamos Overflow/LARC [5] ou Loci/Mississippi State University [6] para rodar simulações híbridas RANS/LES de veículo ou veículo+plataforma de lançamento com cerca de 100 milhões de células, incluindo malhas sobrepostas móveis, algo como 10 a 20 espécies químicas de combustão reativa e dinâmica de partículas evaporativas lagrangianas
      O SSME e os SRBs eram acionados juntos, e o sistema de supressão por água no lançamento também era incluído
      Mas essas informações são de 10 anos atrás, então não sei qual é o estado da arte hoje; imagino que já tenha avançado além disso
      Se quiser entender a direção que interessa ao setor, o CFD Vision 2030 Study de 2014, apesar de antigo, não é uma introdução ruim [7]
      Também vale a pena conseguir ingresso para a Supercomputing e circular por lá
      Este ano foi em Denver [8]
      Mas o foco é mais em coisas “grandes”, então você provavelmente vai ver mais simulações meteorológicas gigantescas ou dinâmica de nebulosas
      Eu gosto da conferência em si, mas é difícil chamar atenção sem resultados em escala de #CPUs/#GPUs/#FPGAs++
      Fora da NASA, no lado governamental, há NIST (Gaithersburg), DOE (Oak Ridge, Sandia, Los Alamos), Air Force (AF Research Lab) e 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] Exemplos um tanto antigos: 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] Estudo CFD Vision 2030: https://ntrs.nasa.gov/api/citations/20140003093/downloads/20...
[8] Supercomputing SC23: https://sc23.supercomputing.org/