Category: hou-effects

Archived post by WhileRomeBurns

@danmoreno i tried it out, it works okay. to make life painful i did it in one dop and using sparse. i recommend 2 dops for simplicity

find_densitymask on the left looks for the intersection of the rising smoke and the sphere and handles the dissipation inside the sphere. transfer_density on the right side reaches into the other dop object and uses the densitymask as an emission source. because it has collisions on, the smoke stays inside.

warning: this one-dop-sparse setup has all sorts of dumb shit to keep the second solver active and tracking the other one

Attachments in this post:
http://fx-td.com/houdiniandchill/wp-content/uploads/discord/20204005/18/20/smokefill.mp4
http://fx-td.com/houdiniandchill/wp-content/uploads/discord/20204005/18/20/smokeFill.hiplc

Archived post by WhileRomeBurns

the other thing houdini does is accumulate air resistance and target velocity if you have 2 or more wind forces. the function to do that yourself: “`void addWindForce(vector targetv2; float airresist2; vector _targetv; float _airresist) {
float airresist_sum = _airresist + airresist2; _targetv = (_targetv * _airresist + targetv2 * airresist2) / airresist_sum; _airresist = airresist_sum; }“`

Archived post by WhileRomeBurns

if you want to use `targetv`, `airresist`, `drag` you could do the math yourself and store them in custom attributes like `@c_targetv` so bullet doesn’t pick um up and make nans

it’ll be something like this:

“`float imass = 1.0 / @mass;
@c_airresist = @c_airresist * @c_drag; if (@c_airresist > 0) {
    // the relative ang vel     v@v -= v@c_targetv;
    // quadratic drag     v@v *= 1.0 / ( (@c_airresist * imass * @TimeInc * length(v@v)) + 1.0 );
    // restore frame     v@v += v@c_targetv; }“`

i don’t see how that could produce a nan unless c_airresist was negative or mass was zero

which you can add checks for if you like

just skip zero-mass dudes

Archived post by CiaranM

It’s a SOP Solver, so just do your group masking the SOP way 🙂 Specifically, set the group mask on your wrangle nodes to @name=boxes* or @name=spheres*. You really only need a single SOP solver (with Data Name and Group back to default) with as much wrangling per-group as you like inside of it. I really like to keep it simple and keep all of my packed geometry coming from a single SOP source into a single RBD Packed Object. Do as much as you can with SOP-type workflows, avoiding DOP anachronisms at all costs.

Archived post by TOADSTORM

fluids are a shitload easier to solve when you can assume that they’re incompressible. with that assumption in mind, what you don’t want is fluid velocities that are pushing into each other or away from each other, because this would result in fluid densities increasing in some areas and decreasing in others… i.e. compression.
the non-divergent projection iteratively goes over your velocity field and finds ways to redirect those velocities so that they’re not going to result in an increase in pressure. this redirection manifests itself as swirly behavior, which is typically what you want with fluids.

you could see this pretty quickly in action with a 2D pyro sim… make a little ball of gas and apply a uniform outward force from the center. without the non-divergent projection step, the gas would simply expand. with it, it instead starts to swirl around itself in an effort to not increase or decrease pressure.

i’m probably leaving out details that one of you actual smart people can fill in, but that’s my understanding of the process