Houdini FX: RBD Solvers, Bullet y problemas con geometría cóncava.

Article / 10 February 2019

Houdini FX: RBD Solvers, Bullet y problemas con geometría cóncava.


Aprovechando mi proyecto de fin de máster, voy a desarrollar una serie de post para explicar conceptos en Houdini FX que ayuden a entender la forma de trabajar de este programa, ya que muchas veces nos centramos en realizar los proyectos sin saber cómo funcionan algunas operaciones que nos podrían ahorrar mucho tiempo de cálculo. Daré por hecho el conocimiento del programa a nivel básico y a la hora de desplazarnos por sus diferentes “Networks”.

En este primer post hablaré de los diferentes tipos de “Solvers” y sus ventajas e inconvenientes a la hora de trabajar con ellos, de economizar tiempos y ganar calidad en nuestra fractura.

Podemos hacer uso de tres tipos diferentes de “RIGID BODY SOLVERS”:

Houdini RBD Solver: Este sistema es el solver del programa, es estable, bastante preciso y muy fácil de usar

Bullet Solver: Éste es nuestro favorito. Es Rápido, Eficiente y nos permite calcular muchísima geometría (es el más usado en los VFX).

ODE Solver: Este sistema “Open Dynamic Engine” es el más básico, casi sin uso ya que solo sirve para simular geometría básica rápidamente. (Bullet sigue siendo favorito).

Estos solvers los podremos seleccionar una vez tengamos montado nuestro DOPNET, dentro de él nos encontramos con 4 nodos de “RBD solver” que son: RBD Solver, Bullet RBD Solver, ODE Solver y rigidbodysolver. El último es el que nos interesa, ya que desde el podemos acceder a los 3 primeros nombrados.

A la hora del cálculo de colisiones con rididbodysolver y configurando nuestro Bullet podemos elegir diferentes tipos de geometría (dentro de nuestro nodo de llamada a la geometría previamente preparada) para agilizar el proceso de cálculo una vez pongamos en marcha nuestra simulación, ya que las fracturas se componen de muchos fragmentos la llamada que haremos será desde un RBDpackedobject que nos permite traernos y computarnos geometría empaquetada.

En el menú de Bullet encontraremos la representación de la geometría con la que realizaremos los cálculos, hay diferentes geometrías básicas como una esfera, un plano, un cilindro…. Pero ya que buscamos variación y cierta credibilidad en nuestra simulación el que mayor prestación nos dará es Convex Hull, ya que Concave es la más costosa de computar, el punto desfavorable es que tendremos que preparar nuestra geometría, Aquí entra el gran problema, y es que en esa preparación de la geometría tendremos que tener muy en cuenta la concavidad y la convexidad de nuestras piezas, objetos como marcos de ventanas, aros o incluso partes de un objeto que superen los 90 grados de forma cóncava no serían válidos para su cálculo preciso. El remedio a este problema es separar dichas zonas del objeto y fracturarlas por separado a la hora de preparar la geometría, de esta manera podremos simular zonas cóncavas de la manera más precisa y economizada posible. Para acabar os dejo una imagen explicativa de este problema en la que explico gráficamente como gestiona y calcula nuestra máquina un Convex Shape y un Concave Shape.


Houdini FX: Cómo retomar una simulación fallida. (Checkpoints)

General / 10 February 2019

Houdini FX: Cómo retomar una simulación fallida. (Checkpoints)


En ocasiones, tenemos que realizar simulaciones que nos pueden llevar horas o incluso días. Aunque parezca una situación similar a un render, hay un aspecto importante que lo diferencia claramente, y es que cuando realizamos éstas caches de simulación, el programa se basa en la información del frame anterior o incluso del subframe anterior (cálculos que se realizan entre frames para tener mayor precisión).

Por poner un ejemplo, en el caso de una simulación de humo, el programa tendrá en cuenta la velocidad de los vectores para su movimiento, densidad…

EXPLICACIÓN Y USO

En Houdini Fx, hay un formato el cual nos permite guardar la información de cada frame, para poder utilizar como punto de inicio en el caso de que ocurriera lo anteriormente comentado, éste es ( .sim ), a veces, podemos encontrarlo como (.sim.sc ) o ( .sim.gz )  simplemente son dos extensiones, Blosc y Gzip funcionan de la misma manera, ralentizan un poco la simulación pero nos ahorran bastante espacio en disco.

Para acceder a guardar nuestros “Checkpoints” tenemos que dirigirnos a la pestaña “cache” del nodo “dopnetwork”, habilitar “Cache Simulation”, “cache substep data” (si hacemos cálculos entre frames dentro del dopnet) y “Save checkpoints”.

Checkpoint File = En este apartado, elegiremos la ruta de guardado con su extensión (.sim), y muy importante que a la hora de usar el padding sea ( $SF ), ya que necesita hacer uso de esos subframes para continuar la simulación (tenga o no substeps internos).

Checkpoint Trail Length = Controla el número de frames que guardará Houdini, y si es superior a este número automáticamente borra los anteriores para economizar espacio.

Chekpoint interval = Cada cuántos frames queremos generar un archivo ( .sim ).


Ahora proseguiremos ejecutando nuestra caché con normalidad y en el caso de que fallase, únicamente tenemos que introducir el último archivo generado ( .sim ) en el apartado de Initial State. ( no tocar el parámetro Start Frame )


debemos asegurarnos que al volver a realizar la caché lo hacemos desde el frame que nos marque el ( .sim ) introducido, como muestro a continuación.


  

Reducción de ruido en render

General / 10 February 2019

Reducción de ruido en render


En este pequeño artículo escribiré sobre como evitar el ruido a la hora de renderizar nuestro proyecto, para ello lo más importante será identificar de dónde proviene.

Las causas más comunes son:

Profundidad de campo (Depth of Field)

Desenfoque de movimiento (Motion Blur)

Luz Difusa (Diffuse)

Especular (Specular)

Sombras (Shadow)

Especular indirecta (Indirect Specular)

SSS (Subsurface scattering)

Volúmenes (Atmospheric Volume)

Hay que tener en cuenta que la aparición de este ruido en nuestras imágenes de render pueden provenir de un insuficiente muestreo (Sampling), pero si incrementamos estos valores se pueden disparar los tiempos de render.

Para agilizar el proceso es muy útil renderizar los diferentes AOVs. Esto nos permitirá identificar claramente de donde proviene el ruido.

 

RUIDO VISIBLE EN:

“SAMPLES” a ajustar

Alpha channel

Camera (AA) samples

Indirect Diffuse

Diffuse Samples

Direct Specular (specular noise)

Light samples

Direct Diffuse (shadow noise)

Light samples

Indirect Specular

Specular samples

Transmission

Transmission samples

SSS(direct and indirect)

SSS(direct and indirect) samples

Volume

Volume samples (también puede provenir de las luces)

 

Una breve explicación de los parámetros principales de Arnold:

Camera (AA) = Trabaja como multiplicador del resto de parámetros y controla el número de rayos por píxel que son lanzados desde la cámara. Por ejemplo, un valor de 4 significa 4×4=16 pixel samples. Normalmente para una imagen de una calidad media sería un valor de 4, una imagen con buena calidad 8. (estos son los valores entre los que nos deberíamos mover para economizar nuestro tiempo de render). Debemos tener en cuenta con lo mencionado anteriormente sobre su funcionamiento como multiplicador que si aumentamos este valor por ejemplo a 6 y en otro parámetro, pongamos transmission = 6, significa que 62 x 62 estaríamos hablando de 1296 rayos por píxel a la hora de calcular la transmisión. Esto hace que sea importante controlar este valor ya que se nos puede disparar el tiempo de render.

 

Diffuse = Aumentaremos este parámetro cuando tengamos ruido en nuestra luz indirecta (como anteriormente mencioné, es importante sacar los diferentes AOVs para no perder tiempo en determinar dónde se genera el ruido en nuestra escena) este ruido se produce en el AOV = indirect diffuse.

 

Specular= Refiriéndonos a ello de una manera físicamente correcta, es la luz generada mediante la reflexión de la luz en una superficie especular, donde estos rayos incidentes se reflejan con un ángulo igual al de incidencia. A veces puede causar confusión si modificamos éste parámetro y no notamos resultados. En caso de no notar mejoría en el ruido reduciremos el número de Samples y de Ray depth de “Specular” a cero, si este ruido desaparece entonces es debido a las reflexiones especulares.

 

Transmission = Reduce el ruido producido por la Refracción de la luz. Decir que es de las propiedades más “caras” a la hora de renderizar y dónde más puede aumentar el tiempo de render.

 

SSS (Subsurface Scatter) = Esta propiedad nos da una dimensión mas realista de los objetos, sobre todo aquellos que son translúcidos. Es la penetración de la luz dentro de ellos y la manera en como se difumina interiormente antes de salir de nuevo del objeto. Al igual que la transmisión es un valor muy sensible para el tiempo de render.

 

Volume Indirect = Este parámetro calcula la luz indirecta en los volúmenes de nuestra escena, es decir, el rebote interno de la luz dentro de nuestro humo, fuego, nubes… Otro de los parámetros más costosos en render.

Una vez haya desaparecido el ruido de nuestra escena, solo nos queda subir un parámetro más… La paciencia!!