El objetivo es realizar 10 segundos de simulación de fluidos muy detallada para un primer plano a 60 fotogramas por segundo.

Después de pasar aproximadamente un día experimentando y comparando MantaFlow con Flip Fluis, elegí este último, ya que MantaFlow se comporta de manera muy impredecible, dependiendo de la resolución.

Calculé que el agua llegaría a la superficie de la piscina en 50 fotogramas + se necesitan 10 segundos de la animación a 60 fps, lo que da como resultado una simulación de 650 fotogramas con una resolución de 150 millones de vóxeles. Esta simulación en Ryzen 3700x tomó 5 días.

Además, resultó que el mezclador falla durante el renderizado si la geometría en FlipFluids es demasiado poligonal. Realmente no quería volver a hacer la simulación con una resolución más baja y esperar varios días nuevamente. Pasé un par de días buscando una solución al problema e incluso comencé a pensar en volver a MantaFlow.

Volví a configurar la escena de Cycles a Octane Render, el problema persistía, así que decidí volver a Cycles.

Blender, en general, maneja muy bien una gran cantidad de polígonos, el problema está en la geometría de FlipFluids. Los desarrolladores del complemento admiten el problema en su GitHub y escriben que está en el lado de Blender, ya que no funciona bien con la geometría HighPoly hecha en Python o algo así.

Decidí intentar exportar la geometría a Alembic para luego poder importarla nuevamente, por lo que no debería haber ningún problema con ella. Intenté exportar de diferentes maneras, pero siempre terminaba con la licuadora fallando. Una exportación tardó incluso más de un día.

Luego, en un foro estadounidense encontré una solución donde se decía que en la geometría antes de exportar solo necesitas intercambiar los modificadores y bajar el modificador Smooth, después de lo cual la geometría FlipFluids se exportó rápidamente a Alembic. Funcionó. Exporté la geometría a Alembic, oculté la geometría FlipFluids original del renderizado y la ventana gráfica, pero dejé las burbujas y la espuma, e importé la geometría de Alembic.

Me sorprendió gratamente que la geometría del Alambique retuviera la información de velocidad y MotionBlur en el agua funcionara correctamente y la escena ya no fallara. Más precisamente, no despegó inmediatamente, sino un poco más tarde.

Inicié el render y se bloqueó recién al día siguiente, después de unos cien fotogramas. Es normal, puedes vivir, simplemente reinicié el render desde donde se detuvo.

En el punto de contacto del chorro con la superficie del agua, el líquido tiene un aspecto oscuro. No es una “laguna azul” en absoluto. El problema son las limitaciones de la tecnología PathTracing. En este lugar hay una gran cantidad de reflejos y refracciones de la superficie del agua y burbujas, y el renderizador cuenta un máximo de 12 reflejos y luego dibuja la oscuridad. Por supuesto, puede configurar no 12, sino 128, 1024, etc., pero luego esperaremos meses para obtener el resultado del renderizado. Por lo tanto, agregué brillo propio turquesa a las burbujas y 10 veces menos del mismo brillo propio al agua. La jamba desapareció, el tiempo de renderizado no ha cambiado. Renderizo desde el principio. Al mismo tiempo, decidí comenzar no desde el cuadro 50, sino desde el cuadro 100, donde las vibraciones ya son visibles en la superficie del agua. También agregué brillo a las fuentes de luz y un poco de niebla al agua.

Después de un tiempo de pruebas, noté que en Blender 3.5 la escena se comporta mucho más estable que en la versión 3.6, así que decidí seguir trabajando en ella. Los materiales con la tarjeta Mix tuvieron que reconfigurarse, porque en la versión 3.6 funciona de manera diferente, y los primeros fotogramas tendrán que volver a renderizarse, porque ahora algunos materiales se ven un poco diferentes.

Otro día después, miré los primeros segundos de la animación resultante y noté que las plantas no se balanceaban con el viento como había planeado, no había textura en las ramas y la hierba había desaparecido. El problema es que hice el proyecto en una computadora portátil y la simulación y el renderizado en una PC, y en la PC en la versión 3.5 había una versión antigua de los complementos de vegetación. Reinstalé el complemento de vegetación, reconfigure la vegetación. Reinstalé el complemento para césped, reconfigure el césped. Configuré la animación para que se renderice nuevamente.

Descubrí el programa Batch Render Creator, gracias a él, la cantidad de fallas durante el renderizado disminuyó aún más.

El brillo propio desde este ángulo, cerca de la grieta oscura por donde sale el agua, no se ve muy bien. Desafortunadamente, blender no tiene un mapa de Distancia, el cual está disponible en 3ds Max y Corona, por lo que tendrás que renderizar la versión sin autobrillo nuevamente y mezclarlos en AfterEffects para que no haya autobrillo en el área de La brecha, pero la hay en otros lugares.

También hubo otros problemas, por ejemplo con la posición de la cámara, porque cambié el inicio de la animación del fotograma 50 al fotograma 100, y también tuve que volver a renderizar parte de ella. Y tuve que jugar con Geometry Nodes para cortar el fondo cerca del agua, ya que no hice la simulación para toda la profundidad de la piscina.

En respuesta a posibles críticos que nunca han hecho algo así, pero creen que en Houdini o PhoenixFD hay menos problemas y que todo se puede hacer más rápido, les sugiero que primero hagan una simulación de más de 150 millones de vóxeles y la rendericen en la GPU. con vegetación animada y desplazamientos, y luego anota cuánto tiempo te llevó y qué matices e incompatibilidades encontraste.