Em resumo: Estamos construindo um sistema de água para a Unreal Engine com duas promessas: água que parece certa porque luz, cor e espuma são calculadas fisicamente (não ajustadas à mão por cena) e água que se comporta: solte qualquer mesh sobre a superfície e ela flutua, tomba ou afunda corretamente, sem nenhuma configuração. Está em desenvolvimento ativo. Este post explica o que ele cobre, como nos responsabilizamos com fotografias de referência, por que a flutuabilidade é a parte difícil que todos pulam, e onde ele se encaixa ao lado do resto do kit.
O padrão a superar. Repare no que o torna real: espuma nascida de ondas que arrebentam, névoa comendo os penhascos, estatística de carneiros ao longo da ondulação: nada colocado à mão, tudo física. Essa é a barra que estabelecemos.
Por que mais um sistema de água?
A maior parte da água de jogos parece ótima em exatamente uma condição de luz: a da captura de tela da loja. Mova o sol, mude para nublado, ponha a câmera meio abaixo da linha d'água, e ela desmorona.
Há uma segunda falha, mais silenciosa, que importa tanto quanto: quase todo sistema de água trata objetos flutuantes como algo secundário. Você ganha um template de barco, uma página de instruções de aparelhamento de pontões, e a suposição tácita de que ninguém jamais vai jogar uma caixa aleatória no mar. Os jogadores jogam caixas no mar o tempo todo.
Queríamos duas coisas que atualmente não coexistem em um único pacote: visual com qualidade de cinema que sobreviva a qualquer iluminação, e comportamento físico que não exija nenhuma configuração. Nenhum dos dois é alcançável ajustando parâmetros até uma captura ficar bonita: porque uma captura é um único quadro sob um único sol, e no momento em que qualquer um muda, a água ajustada ao gosto mostra suas costuras. Então o alicerce do projeto não é uma lista de recursos. É um teste de aceitação com o qual um humano não pode discutir: uma fotografia.
Julgada contra fotos, não contra o gosto
O desenvolvimento é travado por fotografias de referência com contratos fixos de câmera e iluminação: unidades de luz físicas, um tonemapper travado, e uma métrica de diferença perceptual decidindo aprovado ou reprovado, não o humor do dia de um diretor de arte.
Duas referências são canônicas, e foram escolhidas para serem opostas:
- Um lago claro, câmera na linha d'água. Metade ar, metade água, uma fronteira ondulada sem banda de artefato; água esverdeada tipo costeira cuja cor se aprofunda com a distância; cáusticas nas rochas que combinam com a superfície acima; troncos submersos se curvando corretamente na interface. Esta testa refração, o cruzamento da linha d'água e a absorção de cor submersa, tudo de uma vez.
- Uma costa de tempestade sob céu totalmente encoberto. Sem sol, sem banda de brilho: o mar deve ser lido pelo reflexo suave do céu, um cinza-esverdeado dessaturado, a estatística de carneiros e a névoa sobre os penhascos. Uma boia cavalga a ondulação com um período e inclinação críveis; o comportamento faz parte da aceitação, não só a imagem parada.
A referência encoberta é deliberadamente uma das duas. Água ensolarada favorece todo renderizador da Terra: o brilho especular esconde uma multidão de pecados. Tire o sol, e a água precisa carregar o quadro só pela rugosidade dos reflexos, cor e movimento. Esse é o teste honesto, e é aquele que a maioria dos sistemas evita em silêncio. Um oceano que só parece bom no sol não é lançado.
O lado da câmera é especificado tão rigorosamente quanto o da água, porque uma comparação fotográfica só é justa quando a câmera não pode trapacear. Isso significa intensidades de luz físicas reais (um sol de meio-dia em torno de 100.000 lux, não um controle de brilho arbitrário), uma exposição fixa, e uma configuração fixa de tonemapping e bloom por referência. Mude o tonemapper e qualquer água pode ser feita para combinar com qualquer foto, que é exatamente por que o tonemapper é fixado primeiro.
Drop-a-Mesh: flutuar sem a lição de casa
Arraste qualquer mesh sobre um corpo d'água Numivo e ele se comporta corretamente na hora: o sistema constrói um proxy de física automaticamente, calcula o volume deslocado por quadro a partir da altura de onda real, e deriva flutua-ou-afunda da densidade real.
Submerso é um lugar, não um pós-processo. A cor absorve com a profundidade, a luz filtra em feixes, e a interface acima precisa ser cruzada de forma limpa; a referência do lago existe para manter os três honestos de uma vez.
Um tronco flutua e rola para o lado comprido. Uma caixa balança. Uma estátua de pedra afunda. Sem aparelhamento, sem posicionamento de pontões, sem scripts. Por baixo do capô:
- a forma de colisão é voxelizada automaticamente: de forma assíncrona, e cacheada por asset para acontecer só uma vez: para medir o volume real do objeto;
- a flutuabilidade é calculada fisicamente a cada quadro a partir do volume deslocado contra a densidade da água, e água doce e água salgada diferem de verdade (água salgada é mais densa, então a mesma caixa cavalga mais alto no mar do que num lago);
- flutua-ou-afunda vem da densidade, massa dividida pelo volume do proxy: não há um checkbox "isto deveria flutuar?" como padrão, porque o padrão é a física;
- a estabilidade emerge de como o volume do proxy é distribuído: caixas pesadas em cima emborcam, cascos com peso na quilha se endireitam, uma tábua fica deitada;
- objetos flutuantes se reacoplam à superfície: ondulações, esteiras, um anel de espuma na linha d'água, e efeitos de respingo no impacto.
Há um pequeno painel no actor para overrides: forçar flutuar, forçar afundar, um controle de amortecimento, interruptores de esteira e respingo, mas um override escala a física em vez de substituí-la. Force um matacão a flutuar e ele ainda balança com o período certo e deixa a esteira certa; ele só se comporta como se fosse mais leve. Essa distinção importa: resultados forçados que ignoram o solver parecem props colados a um plano, e os jogadores notam na hora.
O objetivo de design é direto, e é uma demo que queremos poder rodar ao vivo: alguém arrasta vinte props aleatórios para o mar, e tudo simplesmente se comporta: sem abrir uma única janela de configurações antes. Se essa demo precisar de um tutorial, o recurso falhou.
O que ele cobre
Água costeira, oceano aberto, submerso e poças de caverna são todos de primeira classe: ondas baseadas em espectro com ondulação e mar cruzado separados, espuma de ondas que de fato arrebentam, cáusticas movendo os feixes de luz submarinos, e estabilidade sob efeitos cinematográficos.
Especificidades que importam se você liga para água:
- As ondas vêm de espectros oceanográficos (os mesmos modelos estatísticos usados para descrever mares reais), com espalhamento direcional e ondulação controlável de forma independente. Um estado do mar vira uma decisão de clima ("tempestade se formando, ondulação longa do oeste") em vez de trinta controles desconexos que você empurra até parecer tempestuoso.
- A espuma não é uma máscara pintada. Ela se origina onde as ondas realmente arrebentam, envelhece com o tempo e se estria sob o vento. Espuma pintada é o denunciante mais comum de água falsa, porque não se move com a física que deveria representar.
- Submerso é um lugar real. Absorção de cor correta por profundidade (o vermelho vai primeiro, depois o verde, deixando o azul profundo que todos conhecem de filmagens de mergulho), feixes de luz derivados do mesmo campo cáustico que ilumina o fundo, e um cruzamento na linha d'água sem a clássica banda de artefato dura.
- Poças de caverna ganham seu próprio tratamento; água parada ou mal se movendo, perturbações de pingo, reflexos na quase escuridão: porque uma poça interna calma expõe falhas diferentes do oceano aberto.
- As cinemáticas são critérios de aceitação, não algo secundário. A superfície deve permanecer estável sob profundidade de campo, motion blur e grão de filme: sem fireflies especulares que só aparecem depois de aplicado o grão, sem tremulação que uma câmera lenta transforma em estroboscópio.
Por que a flutuabilidade é a parte que todos pulam
O visual pode ser fingido com um bom shader, mas o comportamento não: um flutua-e-afunda convincente precisa de uma estimativa de volume em tempo real e um solver estável, o que é genuinamente difícil, então a maioria dos sistemas lança um prefab de barco e para.
A verdade de engenharia incômoda é que um shader de água bonito é um problema resolvido e um solver de flutuabilidade geral não é. Fingir o visual de uma onda é um problema de textura e normais; fazer um mesh arbitrário, nunca visto antes, se assentar corretamente naquela onda é um problema de física que tem de rodar em velocidade de quadros, sobreviver a passos de tempo rápidos, e não explodir quando uma rocha de mil triângulos encontra uma ondulação de tempestade. Essa lacuna é por que "água" na maioria das engines significa "um plano bonito com o qual você não pode interagir", e por que a parte interativa, quando existe, é um barco feito à mão.
Fechar essa lacuna (tornar o comportamento tão automático quanto o visual) é a razão de este projeto existir e a razão de exigir disciplina de foto de referência mais um solver de verdade em vez de um fim de semana de trabalho de shader.
Quando você pode usar?
Está em desenvolvimento como uma extensão da Unreal Engine, com um rollout em etapas: uma prévia flutuante cinemática chega antes do solver físico completo, para que cenas possam ser povoadas cedo. Não anunciamos uma data; as imagens de referência decidem quando está pronto.
O escalonamento é deliberado. Uma prévia cinemática (objetos seguem a superfície das ondas sem simulação de força completa) chega primeiro, para que artistas possam soltar meshes e povoar um mar enquanto o pesado solver ainda é endurecido: você sente o resultado muito antes de a física estar final. O solver completo, o auto-proxy e o painel completo seguem. Progresso e marcos aparecem na roadmap pública, não numa surpresa de dia de lançamento.
O kit ao lado do qual ele será lançado (scatter, mesh blending, grids, medição) é gratuito para testar hoje. Se você quer ser notificado no momento em que um build público de água existir, o Discord linkado no site é onde será anunciado primeiro, e onde as comparações de aprovado/reprovado das imagens de referência serão postadas conforme acontecem.
Mini-FAQ
Vai exigir as outras ferramentas do Numivo? Não: é uma extensão da mesma família, projetada para se sustentar sozinha. Ela compartilha, porém, o mesmo princípio: os resultados são convertidos em dados nativos da engine sempre que fisicamente possível, para que você seja dono do que faz.
Quais versões de engine? As versões atuais da Unreal Engine 5. As especificidades aterrissam na roadmap conforme a extensão se aproxima de um build público, em vez de serem prometidas agora e revisadas depois.
Como isto difere da água nativa da engine? Sistemas de água nativos são fortes no visual e fracos na interação geral: a flutuabilidade costuma ser um componente separado, ajustado à mão. Todo o ponto aqui é que visual e comportamento vêm de um único sistema fisicamente fundamentado, com a trava da foto de referência mantendo o visual honesto através da iluminação.
Por que anunciar antes do lançamento? Porque o método da fotografia de referência é em si o ponto. Preferimos mostrar a barra publicamente e ser medidos por ela do que revelar algo pronto que ninguém pudesse escrutinar. Este post é essa barra, por escrito: cobre-nos por ela.
