Probleemid vedeliku simulatsiooniga ja miks see on kallis?

Eesmärk on teha 10 sekundit väga üksikasjalikku vedeliku simulatsiooni lähivõtete tegemiseks kiirusega 60 kaadrit sekundis.

Pärast umbes päeva katsetamist ja MantaFlow Flip Fluisiga võrdlemist valisin viimase, kuna MantaFlow käitub olenevalt resolutsioonist väga ettearvamatult.

Arvasin, et vesi jõuab basseini pinnale 50 kaadriga + vajate 10 sekundit animatsiooni ennast 60 kaadrit sekundis, mille tulemuseks on 650 kaadri simulatsioon 150 miljoni voksli eraldusvõimega. See simulatsioon Ryzen 3700x võttis aega 5 päeva.

Lisaks selgus, et segisti jookseb renderduses kokku, kui FlipFluidsi geomeetria on liiga kõrge hulknurkne. Ma tõesti ei tahtnud simulatsiooni uuesti teha madalama eraldusvõimega ja oodata uuesti mitu päeva. Otsisin paar päeva probleemile lahendust ja hakkasin isegi mõtlema MantaFlow'sse naasmisele.

Seadistasin stseeni tsüklitest ümber oktaanirenderduseks, probleem püsis, nii et otsustasin naasta Cyclesi juurde.

Blender saab üldiselt paljude hulknurkadega väga hästi hakkama, probleem on FlipFluidsi geomeetrias. Lisandmoodulite arendajad tunnistavad oma GitHubi probleemi ja kirjutavad, et see on Blenderi poolel, kuna see ei tööta hästi Pythonis tehtud HighPoly geomeetriaga või muu sellisega.

Otsustasin proovida eksportida geomeetria Alembicu, et saaksin selle seejärel tagasi importida, nii et sellega ei tohiks probleeme tekkida. Proovisin eksportida erinevatel viisidel, kuid see lõppes alati blenderi kokkujooksmisega. Üks eksport võttis isegi üle päeva.

Siis ühest ameerika foorumist leidsin lahenduse, kus öeldi, et geomeetrias tuleb enne eksportimist lihtsalt modifikaatorid ära vahetada ja Smoothi modifikaator alla panna, misjärel eksporditi FlipFluidsi geomeetria kiiresti Alembicu. See töötas. Eksportisin geomeetria Alembicu, peitsin originaalse FlipFluidsi geomeetria renderdus- ja vaateaknas, kuid jätsin mullid ja vahu ning importisin Alembicu geomeetria.

Olin meeldivalt üllatunud, et Alembicu geomeetria säilitas kiirusteabe ja MotionBlur vee peal töötas õigesti ning stseen enam kokku ei jooksnud. Täpsemalt, see ei tõusnud kohe, vaid veidi hiljem.

Käivitasin renderduse, see jooksis kokku alles järgmisel päeval, umbes saja kaadri järel. See on normaalne, sa saad elada, ma lihtsalt taaskäivitasin renderduse sealt, kus see peatus.

Joa kokkupuutepunktis veepinnaga tundub vedelik tume. Üldse mitte "sinine laguun". Probleemiks on PathTracingi tehnoloogia piirangud. Selles kohas on veepinnalt ja mullidest tohutult palju peegeldusi ja murdumisi ning renderdaja loeb maksimaalselt 12 peegeldust ja seejärel joonistab mustuse. Muidugi saab määrata mitte 12, vaid 128, 1024 jne, aga siis ootame renderdamise tulemust kuid. Seetõttu lisasin mullidesse türkiissinist isehelendust ja veele endale 10 korda vähem sama isesähki. Jamb on kadunud, renderdusaeg pole muutunud. Renderdan algusest peale. Samas otsustasin alustada mitte 50. kaadrist, vaid 100. kaadrist, kus vibratsioonid on juba veepinnal näha. Valgusallikatele lisasin ka heledust ja veele veidi udu.

Pärast mõnda aega testimist märkasin, et Blender 3.5-s käitub stseen palju stabiilsemalt kui versioonis 3.6, seega otsustasin sellega edasi töötada. Mix kaardiga materjalid tuli ümber seadistada, sest versioonis 3.6 töötab see teisiti ning esimesed kaadrid tuleb uuesti renderdada, sest nüüd näevad osad materjalid välja veidi teistmoodi.

Veel üks päev hiljem vaatasin saadud animatsiooni esimesi sekundeid ja märkasin, et taimed ei õõtsunud tuule käes nii, nagu olin plaaninud, okstel polnud tekstuuri ja muru oli kadunud. Probleem on selles, et tegin projekti sülearvutis ning simulatsiooni ja renderdamist arvutis ning arvutis versiooniga 3.5 oli taimestiku lisade vana versioon. Taimkatte lisand installitud uuesti, taimestik ümber seadistatud. Installisin uuesti muru plugina, seadistasin muru ümber. Panin animatsiooni uuesti renderdama.

Avastasin programmi Batch Render Creator, tänu sellele vähenes renderdamisel krahhide arv veelgi.

Selle nurga alt, pimeda prao lähedal, kust vesi välja voolab, ei tundu isehelend eriti hea. Kahjuks ei ole blenderil vahemaakaarti, mis on saadaval versioonides 3ds Max ja Corona, nii et peate ilma iseheleneva versiooni uuesti renderdama ja need AfterEffecsis segama, et automaatse helendumise alal ei tekiks ​lõhe, kuid seda on teistes kohtades.

Probleeme oli ka muid, näiteks kaamera asendiga, kuna nihutasin animatsiooni algust kaadrilt 50 kaadrilt 100 ja pidin ka osa ümber renderdama. Ja ma pidin geomeetriasõlmedega nokitsema, et vee lähedalt põhi ära lõigata, kuna ma ei teinud simulatsiooni kogu basseini sügavuse ulatuses.

Vastuseks potentsiaalsetele kriitikutele, kes pole kunagi midagi sellist teinud, kuid usuvad, et Houdinis või PhoenixFD-s on probleeme vähem ja kõike saab kiiremini teha, soovitan teil esmalt teha 150+ miljoni voksli simulatsioon ja renderdada see GPU-s. animeeritud taimestiku ja nihkega ning seejärel kirjutage üles, kui kaua see aega võttis ning milliseid nüansse ja vastuolusid kohtasite.

Lisa kommentaar

Sinu e-postiaadressi ei avaldata. Nõutavad väljad on tähistatud *-ga