Category: hou-effects

Archived post by ogvfx

If the point counts are consistent with Id’s all you need to do is calculate the distance between the shapes to get the length and direction.
sops wrangle: vector targetPos = point(1,”P”,@ptnum); vector restPos = point(0,”P”,@ptnum);
v@splashP = (targetPos – restPos) * ch(“splashPMult”); v@splashV = (targetPos -restPos ) * ch(“splashVMult”);
You can create something like a splashP and splashV attribute to control in flip, pops, etc.
I did something like that on the first badguys and some other shows. zerply.com/r/29FebF6u/badguys-fx
I animated sdf’s and controlled the ocean sim to match the shapes and timing.
You’ll want to calculate a birthFrame in sops, then you can animate the force procedurally.
wrangle in dops: float tf = f@birthFrame ; float offset = f@s;
float tfOffset = tf + ch(“offset_mult”);
float timer = fit(@Frame,tf,tfOffset,1,0);
v@P += (v@splashP * timer)*ch(“amount_mult”);
v@v += (v@splashV * timer)*ch(“amount_mult”);
I did something a bit more technical on elemental using jakes optimal transport but the same idea.

Archived post by sniperjake945

TLDR: Its just a clamp on your velocity to not move something too far on any given timestep. It helps prevent instability.
**The long answer**: the cfl condition is a limit on how much something can move. Lets say you have velocity stored in volume. we’ll call that `v`. and we also know the length of our voxel, we can call that `dx`, and we know our timestep `dt`.
the cfl condition says for any value `v` we need to satisfy the inequality: “` dt * (v / dx) <= CFL_NUMBER ``` all that means is that we're normalizing velocity with respect to the length of a voxel. If our velocity * timestep would move us exactly one voxel length, then the result on the left would be 1. So if you had a default CFL of 1, then that velocity is okay and doesnt need to be limited. **To answer your question with respect to sourcing speed**: Increasing the CFL condition would allow for density and velocity in a pyro sim for example, to get moved more than one voxel at any given time step. So **yes**, it would allow for things to move faster with fewer substeps. The problem however is it will causes the sim to look generally worse, as something like pyro is using an explicit integration scheme. So mass conservation will generally suffer meaning you'll see more density loss than you otherwise would, and you might get artifacting depending on how high it's set. **Technicalities**: the actual formula is: ``` dt * sum_i(v_i / d_i) <= CFL_NUMBER ``` where `i` corresponds to each axis. in the case of 3d sims, that x,y,z. so its the sum of velocities over the length of the voxel edges. but that's not terribly important for understanding what's happening

Archived post by jesswho.

I finally replicated this issue again, and it was a floating point error issue. If my stiffness values were getting too small and the floating points were getting too long it would collapse the constraint and subsequently delete the points it was tied to. I rounded all my stiffness values to “`rint(@stiffness * 1000) / 1000“` and that seemed to solve it if anyone every runs into that issue again in vellum. I guess I just got lucky when I remade my dop and it wasn’t happening for a week lol

Archived post by sniperjake945

@aswaab dumb ass idea here but what if you splat your velocity from the particles into a volume, hit it with vdb project non divergent, have that node output the pressure field, take the gradient of that pressure field and use that as your velocity? :0
Cuz in theory gravitational fields are equivalent to the gradient of the pressure field (the irrotational component of a velocity field). I’m just curious if that would give you a less streaky result when trying to make the velocity field from your particles…

It probably won’t but it’s at least an idea <:ICANT:1079254533609357433>

But like I guess the intuition here is that because youd be getting the pressure field, that field would be relatively smooth over the full volume, where as just splatting the particle velocities will be relatively discontinuous

image 0 is the velocity field just splatted into a volume and then advecting by that volume. image 1 is doing the same only we’re advecting by the gradient of the pressure. It changes the result though so it’s probably not what you want… but it does create the clumpys!

the scaling of the pressure field is something you might have to futz with. I found my notes on it…
“`c //if staggered volume @vel_pressure *= length(v@dPdx) * length(v@dPdx) * 4;
//if non-staggered volume @vel_pressure *= length(v@dPdx) * length(v@dPdx) * 1; “`
So in the case of my examples you’d want to use the top version which is multiplied by 4. That would give you the field whos gradient can be subtracted from the velocity field in order to make it divergent free. But like your mileage may very, that will definitely change the look of the advected volume…

Attachments in this post:
http://fx-td.com/houdiniandchill/wp-content/uploads/discord/20254505/25/25/image.png

Archived post by sniperjake945

here’s a full nbody solver using this method 🙂 i havent really tuned the parms, since i only had like 40 minutes to work on this!!! the one downside is that gas particle to field in accumulate mode doesnt allow for like accumulating over larger radii so its a lil bit scuffed. but it works 🙂

the resolution of the background field is of course important, its probably a bit too low in this example but dgaf

Attachments in this post:
http://fx-td.com/houdiniandchill/wp-content/uploads/discord/20250805/24/25/nbody_poisson_solver_v0001.hip