Rob Verweij

Avoid using the sourcing input for force redirection. The sourcing step in FLIP is primarily designed for injecting new particles or adding a one-time initial velocity volume at birth, not for steering active simulation particles.

There are a couple of available options:
As you mentioned use a pop curve force. This might be best if you're aiming for a guided flow.

If you just want particles to completely avoid a specific area / volume (like an invisible boulder or a dead zone), don't use forces at all. Use a Static Object or standard collision volume, and make sure it is invisible at render time.

​If you want particles to actively 'run' away from a specific area, a POP Attract (with negative force which basically turns your pop attract into a "POP Repel") with a bounding box/spherical mask might just be it. I think that would be incredibly efficient.

When I experiment on a specific thing I usually tend to drop it all in one save file/project directory.

Currently I'm studying/experimenting with SOP flips. I have a SOP Flip fundamentals save file with experiments and stuff I found in the documentation. You can basically pick any approach you like though. There's no written rule as to how to approach studying/experimenting with anything within Houdini. Tbh i do have s project dir I called "Liquid FX" in which I will save several personal and specific SOP Flip experiments.

Hey everyone,

Wanted to share a recent lookdev experiment focusing on multi-fluid property propagation within the modern Houdini 21 SOP-based FLIP pipeline. The goal was to merge two independent, stylized emitter streams early in the setup while keeping a razor-sharp attribute boundary during violent fluid churning, splashing, and shearing.

The Setup Architecture
I focused on simplicity and I wanted to handle the logic natively within a single execution stream:

Early Point Grouping & Merging
Stream A (Red) and Stream B (Black) are generated as independent polygonal geometry blocks before entering a single merge node.


The H21 Multi-Wire Trunk
The points feed directly into custom velocity and divergence attribute wrangles before being piped into the FLIP sim. From there, the data flows seamlessly down through the native multi-pass pipeline (flipcontainer ➔ flipboundary ➔ flipcollide ➔ flipsolver).

Solver Configuration
To prevent the attributes from washing out or diluting into a uniform gray soup as the fluids sheared, I disabled Particle Narrow Band and Reseeding

Meshing & Solaris Lookdev
The fluid particles were cached out through a fluidcompress loop and converted back to a unified geometry surface via particlefluidsurface.

In Solaris, the setup utilizes a single master MaterialX Standard Surface shader (fluid_mix_surface) rather than complex multi-material blending nodes.

The Trap: Using a standard mtlxgeompropvalue node targeted at Cd will return blank values in LOPs because sopimport automatically translates point data to native USD primvars.

The Fix: Setting the geometry property reader explicitly to target displayColor instantly grabs the incoming vertex colors.

The data stream feeds directly into an mtlxrampcolor node, mapping the absolute mathematical point values directly to the final colors: translucent Deep Rich Crimson Red and Amber Honey.

Rendered completely in Karma XPU. Let me know what you think of it!