O objetivo é fazer 10 segundos de simulação de fluidos altamente detalhada para um close-up a 60 quadros por segundo.

Depois de passar cerca de um dia experimentando e comparando o MantaFlow com o Flip Fluis, escolhi o último, pois o MantaFlow se comporta de maneira muito imprevisível, dependendo da resolução.

Imaginei que a água chegaria à superfície da piscina em 50 frames + são necessários 10 segundos da própria animação a 60fps, o que resulta em uma simulação de 650 frames com resolução de 150 milhões de voxels. Esta simulação no Ryzen 3700x levou 5 dias.

Além disso, descobriu-se que o liquidificador trava na renderização se a geometria no FlipFluids for poligonal muito alta. Eu realmente não queria fazer a simulação novamente em uma resolução mais baixa e esperar vários dias novamente. Passei alguns dias procurando uma solução para o problema e até comecei a pensar em voltar ao MantaFlow.

Reconfigurei a cena do Cycles para o Octane Render, o problema persistiu, então resolvi voltar para o Cycles.

O Blender, em geral, lida muito bem com um grande número de polígonos, o problema está na geometria do FlipFluids. Os desenvolvedores do addon admitem o problema em seu GitHub e escrevem que está no lado do Blender, pois não funciona bem com a geometria HighPoly feita em Python ou algo parecido.

Decidi tentar exportar a geometria para o Alembic para poder importá-la de volta, para que não haja problemas com isso. Tentei exportar de diversas maneiras, mas sempre terminava com o liquidificador travando. Uma exportação demorou mais de um dia.

Aí em um fórum americano encontrei uma solução onde dizia que na geometria antes de exportar basta trocar os modificadores e colocar o modificador Smooth para baixo, após o que a geometria FlipFluids foi rapidamente exportada para o Alembic. Funcionou. Exportei a geometria para o Alembic, escondi a geometria original do FlipFluids da renderização e da viewport, mas deixei as bolhas e a espuma e importei a geometria do Alembic.

Fiquei agradavelmente surpreso que a geometria do Alembic manteve as informações de velocidade e o MotionBlur na água funcionou corretamente e a cena não travou mais. Mais precisamente, não decolou imediatamente, mas um pouco mais tarde.

Lancei o render, ele travou só no dia seguinte, depois de cerca de cem frames. É normal, você pode viver, acabei de reiniciar o render de onde parou.

No ponto de contato do jato com a superfície da água, o líquido parece escuro. Não é uma “lagoa azul”. O problema são as limitações da tecnologia PathTracing. Neste local há um grande número de reflexos e refrações da superfície da água e das bolhas, e o renderizador conta no máximo 12 reflexos e depois desenha a escuridão. Você pode, é claro, definir não 12, mas 128, 1024, etc., mas então esperaremos meses pelo resultado da renderização. Portanto, adicionei auto-brilho turquesa às bolhas e 10 vezes menos do mesmo auto-brilho à própria água. O batente desapareceu, o tempo de renderização não mudou. Eu renderizo desde o início. Ao mesmo tempo, decidi começar não pelo quadro 50, mas pelo quadro 100, onde as vibrações já são visíveis na superfície da água. Também adicionei brilho às fontes de luz e um pouco de neblina à água.

Depois de algum tempo de testes, percebi que no Blender 3.5 a cena se comporta de forma muito mais estável que na versão 3.6, então resolvi continuar trabalhando nela. Os materiais com o cartão Mix tiveram que ser reconfigurados, pois na versão 3.6 funciona de forma diferente, e os primeiros frames terão que ser re-renderizados, pois agora alguns materiais ficam um pouco diferentes.

Outro dia depois, olhei os primeiros segundos da animação resultante e percebi que as plantas não balançavam com o vento como planejei, não havia textura nos galhos e a grama havia sumido. O problema é que fiz o projeto em um laptop, e a simulação e renderização em um PC, e no PC na versão 3.5 havia uma versão antiga de addons de vegetação. Reinstalei o addon de vegetação, reconfigurei a vegetação. Reinstalei o plugin para grama, reconfigurei a grama. Eu configurei a animação para ser renderizada novamente.

Descobri o programa Batch Render Creator, graças a ele o número de travamentos durante a renderização diminuiu ainda mais.

O brilho próprio deste ângulo, perto da fenda escura por onde a água flui, não parece muito bom. Infelizmente, o blender não possui um mapa de Distância, que está disponível no 3ds Max e Corona, então você terá que renderizar a versão sem auto-brilho novamente e misturá-los no AfterEffecs para que não haja auto-brilho na área de a lacuna, mas existe em outros lugares.

Houve também outros problemas, por exemplo, com a posição da câmera, porque mudei o início da animação do quadro 50 para o quadro 100 e também tive que renderizar novamente parte dela. E tive que mexer nos Geometry Nodes para cortar o fundo próximo à água, já que não fiz a simulação para toda a profundidade da piscina.

Em resposta a possíveis críticos que nunca fizeram nada parecido, mas acreditam que há menos problemas em Houdini ou PhoenixFD e tudo pode ser feito mais rápido, sugiro que você primeiro faça uma simulação de mais de 150 milhões de voxels e renderize-a na GPU junto com vegetação e deslocamento animados e, em seguida, anote quanto tempo demorou e quais nuances e incompatibilidades você encontrou.