Ongelmia nestesimulaatiossa ja miksi se on kallista?

Tavoitteena on tehdä 10 sekuntia erittäin yksityiskohtainen nestesimulaatio lähikuvaa varten 60 kuvaa sekunnissa.

Kun olin käyttänyt noin päivän kokeilemalla ja vertaillut MantaFlow'ta Flip Fluisiin, valitsin jälkimmäisen, sillä MantaFlow käyttäytyy erittäin arvaamattomalla tavalla resoluutiosta riippuen.

Ajattelin, että vesi saavuttaisi altaan pinnan 50 ruudulla + tarvitset 10 sekuntia itse animaatiota nopeudella 60 fps, mikä johtaa 650 ruudun simulaatioon 150 miljoonan vokselin resoluutiolla. Tämä Ryzen 3700x -simulaatio kesti 5 päivää.

Lisäksi kävi ilmi, että sekoitin kaatuu renderöinnissa, jos FlipFluidsin geometria on liian korkea monikulmio. En todellakaan halunnut tehdä simulaatiota uudelleen pienemmällä resoluutiolla ja odottaa uudelleen useita päiviä. Vietin pari päivää etsiessäni ratkaisua ongelmaan ja aloin jopa miettimään paluuta MantaFlow'hun.

Konfiguroin kohtauksen uudelleen Cyclesistä Octane Renderiin, mutta ongelma jatkui, joten päätin palata Cyclesiin.

Blender käsittelee yleensä monia polygoneja erittäin hyvin, ongelma on FlipFluids-geometriassa. Lisäosien kehittäjät myöntävät ongelman GitHubissa ja kirjoittavat sen olevan Blenderin puolella, koska se ei toimi hyvin Pythonissa tehdyn HighPoly-geometrian tai vastaavan kanssa.

Päätin yrittää viedä geometrian Alembiciin, jotta voin tuoda sen takaisin, joten sen kanssa ei pitäisi olla ongelmia. Yritin viedä eri tavoilla, mutta se päättyi aina tehosekoittimen kaatumiseen. Yksi vienti kesti jopa yli päivän.

Sitten eräältä amerikkalaiselta foorumilta löysin ratkaisun, jossa sanottiin, että geometriassa ennen vientiä pitää vain vaihtaa modifioijat ja laittaa Smooth-muunnin alas, minkä jälkeen FlipFluids-geometria vietiin nopeasti Alembiciin. Se toimi. Vienin geometrian Alembiciin, piilotin alkuperäisen FlipFluids-geometrian renderöinnista ja näkymästä, mutta jätin kuplat ja vaahdon ja toin Alembic-geometrian.

Olin iloisesti yllättynyt siitä, että Alembic-geometria säilytti nopeustiedot ja MotionBlur vedessä toimi oikein eikä kohtaus enää kaatunut. Tarkemmin sanottuna se ei lähtenyt heti, vaan vähän myöhemmin.

Käynnistin renderoinnin, se kaatui vasta seuraavana päivänä, noin sadan kuvan jälkeen. Se on normaalia, voit elää, käynnistin juuri renderoinnin uudelleen siitä, mihin se pysähtyi.

Suihkun kosketuskohdassa veden pintaan neste näyttää tummalta. Ei ollenkaan "sininen laguuni". Ongelmana on PathTracing-tekniikan rajoitukset. Tässä paikassa on valtava määrä heijastuksia ja taittumia veden pinnasta ja kuplia, ja renderöija laskee enintään 12 heijastusta ja piirtää sitten mustuuden. Voit toki asettaa ei 12, vaan 128, 1024 jne., mutta sitten odotamme kuukausia renderöintitulosta. Siksi lisäsin turkoosia itsehohtoa kupliin ja 10 kertaa vähemmän samaa itsehohtoa itse veteen. Jamb on poissa, renderöintiaika ei ole muuttunut. Piirrän alusta alkaen. Samalla päätin aloittaa enkä kehyksestä 50, vaan kehyksestä 100, jossa tärinää näkyy jo veden pinnalla. Lisäsin myös kirkkautta valonlähteisiin ja hieman sumua veteen.

Jonkin ajan testaamisen jälkeen huomasin, että Blender 3.5:ssä kohtaus käyttäytyy paljon vakaammin kuin versiossa 3.6, joten päätin jatkaa työskentelyä sen parissa. Mix-kortin materiaalit jouduttiin konfiguroimaan uudelleen, koska versiossa 3.6 se toimii eri tavalla ja ensimmäiset kehykset on renderöitävä uudelleen, koska nyt jotkut materiaalit näyttävät hieman erilaisilta.

Toista päivää myöhemmin katsoin syntyneen animaation ensimmäisiä sekunteja ja huomasin, että kasvit eivät huojuneet tuulessa suunnitellulla tavalla, oksilla ei ollut tekstuuria ja ruoho puuttui. Ongelmana on, että tein projektin kannettavalla tietokoneella ja simuloinnin ja renderöinnin PC:llä, ja PC:llä versiolla 3.5 oli vanha versio kasvillisuuden lisäyksistä. Kasvillisuuden lisäys on asennettu uudelleen, kasvillisuus konfiguroitu uudelleen. Asensin ruohon laajennuksen uudelleen, määritin ruohon uudelleen. Asetin animaation hahmonnettavaksi uudelleen.

Löysin Batch Render Creator -ohjelman, jonka ansiosta kaatumisten määrä renderöinnin aikana väheni entisestään.

Itsehohto tästä kulmasta, lähellä tummaa halkeamaa, josta vesi virtaa ulos, ei näytä kovin hyvältä. Valitettavasti blenderillä ei ole etäisyyskartta, joka on saatavilla 3ds Maxissa ja Coronassa, joten sinun on renderöitävä versio ilman itsestään hehkuvaa versiota uudelleen ja sekoitettava ne AfterEffecsissä, jotta itsehohtoa ei esiinny ​aukko, mutta sitä on muissa paikoissa.

Muitakin ongelmia oli, esimerkiksi kameran asennossa, koska siirsin animaation alun ruudusta 50 ruutuun 100 ja jouduin myös hahmottamaan osan uudelleen. Ja minun piti puuhailla Geometry Nodesin kanssa leikkaakseni pohjan veden läheltä, koska en tehnyt simulaatiota koko altaan syvyydelle.

Vastauksena mahdollisille kriitikoille, jotka eivät ole koskaan tehneet mitään tällaista, mutta uskovat, että Houdinissa tai PhoenixFD:ssä on vähemmän ongelmia ja kaikki voidaan tehdä nopeammin, ehdotan, että teet ensin yli 150 miljoonan vokselin simulaation ja renderöit sen GPU:ssa. animoidulla kasvillisuudella ja siirtymällä, ja kirjoita sitten ylös, kuinka kauan se kesti ja mitä vivahteita ja yhteensopimattomuutta kohtasit.

Vastaa

Sähköpostiosoitettasi ei julkaista. Pakolliset kentät on merkitty *