Akışkan simülasyonuyla ilgili sorunlar ve neden pahalı?

Hedef, saniyede 60 kare hızında yakın çekim için 10 saniyelik son derece ayrıntılı bir akışkan simülasyonu yapmaktır.

MantaFlow'u Flip Fluis ile deneyerek ve karşılaştırarak yaklaşık bir gün geçirdikten sonra ikincisini seçtim çünkü MantaFlow, çözünürlüğe bağlı olarak çok öngörülemez şekilde davranıyor.

Suyun havuz yüzeyine 50 karede ulaşacağını düşündüm + 60 fps'de animasyonun 10 saniyesine ihtiyacınız var, bu da 150 milyon voksel çözünürlükte 650 karelik bir simülasyonla sonuçlanıyor. Ryzen 3700x üzerindeki bu simülasyon 5 gün sürdü.

Dahası, FlipFluids'teki geometri çok yüksek poligonal olduğunda blenderin render sırasında çöktüğü ortaya çıktı. Simülasyonu daha düşük bir çözünürlükte tekrar yapıp birkaç gün daha beklemek istemedim. Birkaç günümü soruna çözüm arayarak geçirdim ve hatta MantaFlow'a dönmeyi düşünmeye başladım.

Sahneyi Cycles'tan Octane Render'a yeniden yapılandırdım, sorun devam etti, bu yüzden Cycles'a dönmeye karar verdim.

Blender genel olarak çok sayıda çokgeni çok iyi işler; sorun FlipFluids geometrisindedir. Eklenti geliştiricileri sorunu GitHub'larında kabul ediyorlar ve Python'da yapılan HighPoly geometrisi veya buna benzer bir şeyle iyi çalışmadığından sorunun Blender tarafında olduğunu yazıyorlar.

Geometriyi Alembic'e aktarmayı denemeye karar verdim, böylece daha sonra geri aktarabilirim, böylece herhangi bir sorun yaşanmaz. Farklı şekillerde dışa aktarmayı denedim ama her zaman blenderin çökmesiyle sonuçlandı. Hatta bir ihracat bir günden fazla sürdü.

Daha sonra bir Amerikan forumunda, geometride dışa aktarmadan önce değiştiricileri değiştirmeniz ve Smooth değiştiriciyi bırakmanız gerektiğinin söylendiği bir çözüm buldum, ardından FlipFluids geometrisi hızlı bir şekilde Alembic'e aktarıldı. İşe yaradı. Geometriyi Alembic'e aktardım, orijinal FlipFluids geometrisini görüntüden ve görünüm alanından sakladım, ancak kabarcıkları ve köpüğü bıraktım ve Alembic geometrisini içe aktardım.

Alembic geometrisinin hız bilgisini korumasına ve su üzerindeki MotionBlur'un doğru çalışmasına ve sahnenin artık çökmemesine hoş bir şekilde şaşırdım. Daha doğrusu hemen değil, biraz sonra havalandı.

Render'ı başlattım, ancak ertesi gün yaklaşık yüz kareden sonra çöktü. Normaldir, yaşayabilirsiniz, az önce renderı kaldığı yerden yeniden başlattım.

Jetin su yüzeyi ile temas ettiği noktada sıvı koyu renkli görünür. Kesinlikle bir “mavi lagün” değil. Sorun PathTracing teknolojisinin sınırlamalarıdır. Bu yerde su yüzeyinden ve kabarcıklardan çok sayıda yansıma ve kırılma var ve oluşturucu maksimum 12 yansımayı sayıyor ve ardından siyahlığı çiziyor. Elbette 12 değil 128, 1024 vb. ayarlayabilirsiniz, ancak o zaman render sonucu için aylarca bekleyeceğiz. Bu nedenle baloncuklara turkuaz kendiliğinden ışıltıyı, suya ise aynı kendiliğinden ışıltıdan 10 kat daha azını ekledim. Pervaz gitti, render süresi değişmedi. Baştan itibaren render alıyorum. Aynı zamanda 50. çerçeveden değil, su yüzeyinde titreşimlerin zaten görülebildiği 100. çerçeveden başlamaya karar verdim. Ayrıca ışık kaynaklarına parlaklık ve suya biraz sis ekledim.

Bir süre test ettikten sonra Blender 3.5'te sahnenin 3.6 sürümüne göre çok daha kararlı davrandığını fark ettim ve üzerinde çalışmaya devam etmeye karar verdim. Mix kartına sahip malzemelerin yeniden yapılandırılması gerekiyordu çünkü sürüm 3.6'da farklı çalışıyor ve ilk karelerin yeniden oluşturulması gerekecek çünkü artık bazı malzemeler biraz farklı görünüyor.

Başka bir gün sonra ortaya çıkan animasyonun ilk saniyelerine baktığımda bitkilerin planladığım gibi rüzgarda sallanmadığını, dallarda doku olmadığını ve çimlerin eksik olduğunu fark ettim. Sorun şu ki, projeyi bir dizüstü bilgisayarda yaptım ve simülasyonu ve görüntülemeyi bir PC'de yaptım ve PC'de sürüm 3.5'te bitki örtüsü eklentilerinin eski bir sürümü vardı. Bitki örtüsü eklentisi yeniden yüklendi, bitki örtüsü yeniden yapılandırıldı. Çim eklentisi yeniden yüklendi, çim yeniden yapılandırıldı. Animasyonu tekrar oluşturulacak şekilde ayarladım.

Batch Render Creator programını keşfettim, onun sayesinde render sırasındaki çökmelerin sayısı daha da azaldı.

Bu açıdan, suyun dışarı aktığı karanlık çatlağın yakınındaki kendi kendine parlama pek iyi görünmüyor. Ne yazık ki, blender'da 3ds Max ve Corona'da bulunan bir Uzaklık haritası yok, bu nedenle kendi kendine parlamayan sürümü tekrar oluşturmanız ve bunları AfterEffecs'te karıştırmanız gerekecek, böylece kendi alanında kendi kendine parlama olmaz. boşluk ama başka yerlerde de var.

Başka sorunlar da vardı, örneğin kamera konumuyla ilgili, çünkü animasyonun başlangıcını 50. kareden 100. kareye kaydırdım ve bir kısmını yeniden oluşturmak zorunda kaldım. Ve simülasyonu havuzun tüm derinliği için yapmadığım için, suya yakın tabanı kesmek için Geometri Düğümleri ile uğraşmak zorunda kaldım.

Hiç böyle bir şey yapmayan ancak Houdini veya PhoenixFD'de daha az sorun olduğuna ve her şeyin daha hızlı yapılabileceğine inanan potansiyel eleştirmenlere yanıt olarak, öncelikle 150+ milyon voksel simülasyonu yapmanızı ve bunu GPU'da işlemenizi öneririm. animasyonlu bitki örtüsü ve yer değiştirme ile ve ardından bunun ne kadar sürdüğünü ve hangi nüanslar ve uyumsuzluklarla karşılaştığınızı yazın.

Bir cevap yazın

E-posta hesabınız yayımlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir