L'obiettivo è realizzare 10 secondi di simulazione fluida altamente dettagliata per uno scatto ravvicinato a 60 fotogrammi al secondo.

Dopo aver trascorso circa una giornata sperimentando e confrontando MantaFlow con Flip Fluis, ho scelto quest'ultimo, poiché MantaFlow si comporta in modo molto imprevedibile, a seconda della risoluzione.

Ho calcolato che l'acqua raggiungerebbe la superficie della piscina in 50 fotogrammi + sono necessari 10 secondi dell'animazione stessa a 60 fps, il che si traduce in una simulazione di 650 fotogrammi con una risoluzione di 150 milioni di voxel. Questa simulazione sul Ryzen 3700x ha richiesto 5 giorni.

Inoltre si è scoperto che il frullatore si blocca nel rendering se la geometria in FlipFluids è troppo poligonale. Non volevo davvero ripetere la simulazione con una risoluzione inferiore e aspettare ancora diversi giorni. Ho trascorso un paio di giorni alla ricerca di una soluzione al problema e ho persino iniziato a pensare di tornare a MantaFlow.

Ho riconfigurato la scena da Cycles a Octane Render, il problema persisteva, quindi ho deciso di tornare a Cycles.

Blender, in generale, gestisce molto bene un gran numero di poligoni, il problema è con la geometria FlipFluid. Gli sviluppatori del componente aggiuntivo ammettono il problema sul loro GitHub e scrivono che è dal lato di Blender poiché non funziona bene con la geometria HighPoly realizzata in Python o qualcosa del genere.

Ho deciso di provare ad esportare la geometria su Alembic in modo da poterla poi importare nuovamente, quindi non dovrebbero esserci problemi. Ho provato a esportare in diversi modi, ma il risultato è sempre stato il crash del frullatore. Un'esportazione ha richiesto addirittura più di un giorno.

Poi su un forum americano ho trovato una soluzione in cui si diceva che nella geometria prima di esportare basta scambiare i modificatori e mettere giù il modificatore Smooth, dopodiché la geometria FlipFluids è stata rapidamente esportata in Alembic. Ha funzionato. Ho esportato la geometria in Alembic, ho nascosto la geometria FlipFluids originale dal rendering e dal viewport, ma ho lasciato le bolle e la schiuma e ho importato la geometria Alembic.

Sono rimasto piacevolmente sorpreso dal fatto che la geometria dell'Alembic mantenga le informazioni sulla velocità e che il MotionBlur sull'acqua funzioni correttamente e la scena non si blocchi più. Più precisamente, non è decollato subito, ma poco dopo.

Ho lanciato il render, si è bloccato solo il giorno dopo, dopo circa un centinaio di fotogrammi. È normale, puoi vivere, ho appena riavviato il rendering da dove si era interrotto.

Nel punto di contatto del getto con la superficie dell'acqua il liquido appare scuro. Non è affatto una “laguna blu”. Il problema sono i limiti della tecnologia PathTracing. In questo luogo c'è un numero enorme di riflessi e rifrazioni dalla superficie dell'acqua e delle bolle, e il renderer conta un massimo di 12 riflessi, quindi disegna l'oscurità. Ovviamente puoi impostare non 12, ma 128, 1024, ecc., Ma poi aspetteremo mesi per il risultato del rendering. Pertanto, ho aggiunto l'autoluminescenza turchese alle bolle e 10 volte meno della stessa autoluminosità all'acqua stessa. Lo stipite è sparito, i tempi di rendering non sono cambiati. Rendo dall'inizio. Allo stesso tempo ho deciso di partire non dal frame 50, ma dal frame 100, dove le vibrazioni sono già visibili sulla superficie dell'acqua. Ho anche aggiunto luminosità alle fonti di luce e un po' di nebbia all'acqua.

Dopo un po' di test, ho notato che in Blender 3.5 la scena si comporta in modo molto più stabile rispetto alla versione 3.6, quindi ho deciso di continuare a lavorarci. I materiali con la scheda Mix dovevano essere riconfigurati, perché nella versione 3.6 funziona diversamente, e i primi fotogrammi dovranno essere renderizzati nuovamente, perché ora alcuni materiali sembrano leggermente diversi.

Un altro giorno dopo, ho guardato i primi secondi dell'animazione risultante e ho notato che le piante non ondeggiavano al vento come avevo previsto, non c'era consistenza sui rami e mancava l'erba. Il problema è che ho eseguito il progetto su un laptop, mentre la simulazione e il rendering su un PC, e sul PC nella versione 3.5 c'era una vecchia versione dei componenti aggiuntivi della vegetazione. Reinstallato il componente aggiuntivo della vegetazione, riconfigurato la vegetazione. Reinstallato il plugin per grass, riconfigurato grass. Ho impostato nuovamente il rendering dell'animazione.

Ho scoperto il programma Batch Render Creator, grazie ad esso il numero di arresti anomali durante il rendering è diminuito ancora di più.

L’autoluce da questa angolazione, vicino alla fessura scura da cui fuoriesce l’acqua, non sembra molto bello. Sfortunatamente, Blender non ha una mappa Distanza, che è disponibile in 3ds Max e Corona, quindi dovrai eseguire nuovamente il rendering della versione senza auto-bagliore e mescolarli in AfterEffecs in modo che non ci sia auto-bagliore nell'area di il divario, ma c'è in altri posti.

Ci sono stati anche altri problemi, ad esempio con la posizione della telecamera, perché ho spostato l'inizio dell'animazione dal fotogramma 50 al fotogramma 100, e ho dovuto anche renderizzarne una parte. E ho dovuto armeggiare con i Geometry Nodes per tagliare il fondo vicino all'acqua, dato che non ho fatto la simulazione per l'intera profondità della piscina.

In risposta ai potenziali critici che non hanno mai fatto nulla del genere, ma credono che in Houdini o PhoenixFD ci siano meno problemi e tutto possa essere fatto più velocemente, suggerisco di realizzare prima una simulazione di oltre 150 milioni di voxel e di renderizzarla sulla GPU insieme con vegetazione animata e spostamento, e poi scrivi quanto tempo hai impiegato e quali sfumature e incompatibilità hai riscontrato.