Mērķis ir izveidot 10 sekunžu ļoti detalizētu šķidruma simulāciju tuvplānam ar ātrumu 60 kadri sekundē.

Pavadījis apmēram dienu, eksperimentējot un salīdzinot MantaFlow ar Flip Fluis, izvēlējos pēdējo, jo MantaFlow uzvedas ļoti neparedzami, atkarībā no izšķirtspējas.

Es izdomāju, ka ūdens sasniegs baseina virsmu 50 kadros + vajag 10 sekundes pašas animācijas ar ātrumu 60 kadri sekundē, kā rezultātā tiek simulēta 650 kadri ar 150 miljonu vokseļu izšķirtspēju. Šī simulācija Ryzen 3700x aizņēma 5 dienas.

Turklāt izrādījās, ka blenderis avarē renderēšanā, ja FlipFluids ģeometrija ir pārāk augsta daudzstūra. Es tiešām negribēju vēlreiz veikt simulāciju ar zemāku izšķirtspēju un atkal gaidīt vairākas dienas. Es pavadīju pāris dienas, meklējot problēmas risinājumu un pat sāku domāt par atgriešanos MantaFlow.

Es pārkonfigurēju ainu no Cycles uz Octane Render, problēma saglabājās, tāpēc es nolēmu atgriezties pie Cycles.

Blenderis kopumā ļoti labi tiek galā ar lielu skaitu daudzstūru, problēma ir ar FlipFluids ģeometriju. Papildinājumu izstrādātāji atzīst problēmu savā GitHub un raksta, ka tā ir Blender pusē, jo tā nedarbojas labi ar HighPoly ģeometriju, kas izveidota Python vai tamlīdzīgi.

Es nolēmu mēģināt eksportēt ģeometriju uz Alembic, lai pēc tam varētu to importēt atpakaļ, tāpēc ar to nevajadzētu rasties problēmām. Es mēģināju eksportēt dažādos veidos, bet tas vienmēr beidzās ar blendera avāriju. Viens eksports aizņēma pat vairāk nekā dienu.

Tad kādā amerikāņu forumā atradu risinājumu, kur bija teikts, ka ģeometrijā pirms eksportēšanas vienkārši jāsamaina modifikatori un jānoliek Smooth modifikators, pēc tam FlipFluids ģeometrija tika ātri eksportēta uz Alembic. Tas izdevās. Es eksportēju ģeometriju uz Alembic, paslēpu oriģinālo FlipFluids ģeometriju no renderēšanas un skata loga, bet atstāju burbuļus un putas un importēju Alembic ģeometriju.

Biju patīkami pārsteigts, ka Alembic ģeometrija saglabāja ātruma informāciju un MotionBlur uz ūdens darbojās pareizi un aina vairs neavarēja. Precīzāk, tas nepacēlās uzreiz, bet nedaudz vēlāk.

Palaidu renderēšanu, tas avarēja tikai nākamajā dienā, pēc kādiem simts kadriem. Tas ir normāli, jūs varat dzīvot, es tikko restartēju renderēšanu no vietas, kur tā apstājās.

Strūklas saskares vietā ar ūdens virsmu šķidrums izskatās tumšs. Nemaz nav "zilā lagūna". Problēma ir PathTracing tehnoloģijas ierobežojumi. Šajā vietā ir milzīgs skaits atspīdumu un refrakciju no ūdens virsmas un burbuļiem, un renderētājs saskaita ne vairāk kā 12 atspulgus un pēc tam zīmē melnumu. Var, protams, iestatīt nevis 12, bet 128, 1024 utt., bet tad mēs mēnešiem gaidīsim renderēšanas rezultātu. Tāpēc burbuļiem pievienoju tirkīza pašspīdumu un pašam ūdenim 10 reizes mazāk tādu pašu pašspīdumu. Jamb ir pazudis, renderēšanas laiks nav mainījies. Es renderēju no sākuma. Tajā pašā laikā nolēmu sākt nevis no 50., bet gan no 100. kadra, kur jau ir redzamas vibrācijas uz ūdens virsmas. Es arī pievienoju spilgtumu gaismas avotiem un nedaudz miglas ūdenim.

Pēc kāda laika testēšanas pamanīju, ka Blender 3.5 sižetā uzvedas daudz stabilāk nekā 3.6 versijā, tāpēc nolēmu turpināt darbu tajā. Materiālus ar Mix karti nācās pārkonfigurēt, jo 3.6 versijā tā darbojas savādāk, un pirmie kadri būs jāpārrenderē, jo tagad daži materiāli izskatās nedaudz savādāk.

Citu dienu vēlāk es aplūkoju iegūtās animācijas pirmās sekundes un pamanīju, ka augi vējā šūpojas ne tā, kā biju plānojis, zaros nebija tekstūras un zāle bija pazudusi. Problēma ir tāda, ka es projektu veicu klēpjdatorā, simulāciju un renderēšanu personālajā datorā, un datorā ar versiju 3.5 bija veca veģetācijas papildinājumu versija. Pārinstalēja veģetācijas papildinājumu, pārkonfigurēja veģetāciju. Pārinstalēja spraudni zālei, pārkonfigurēja zāli. Es iestatīju, lai animācija tiktu renderēta vēlreiz.

Atklāju Batch Render Creator programmu, pateicoties tai, avāriju skaits renderēšanas laikā vēl vairāk samazinājās.

Pašmirdzums no šī leņķa, netālu no tumšās plaisas, kur izplūst ūdens, neizskatās īpaši labi. Diemžēl blenderim nav attāluma kartes, kas ir pieejama 3ds Max un Corona versijās, tāpēc jums būs vēlreiz jāatveido versija bez pašspīdēšanas un jāiejauc tās AfterEffecs, lai apgabalā nebūtu pašspīdēšanas. plaisa, bet ir arī citās vietās.

Bija arī citas problēmas, piemēram, ar kameras pozīciju, jo animācijas sākumu no 50. kadra pārcēlu uz 100. kadru, kā arī daļu no tā nācās renderēt no jauna. Un man bija jāmācās ar ģeometrijas mezgliem, lai nogrieztu dibenu pie ūdens, jo es neveicu simulāciju visam baseina dziļumam.

Atbildot uz potenciālajiem kritiķiem, kuri nekad neko tādu nav darījuši, bet uzskata, ka Houdini vai PhoenixFD ir mazāk problēmu un visu var izdarīt ātrāk, iesaku vispirms izveidot 150+ miljonu vokseļu simulāciju un renderēt to GPU. ar animētu veģetāciju un pārvietošanos, un pēc tam pierakstiet, cik ilgi tas prasīja un ar kādām niansēm un nesaderībām jūs saskārāties.