Category: hou-effects

Archived post by lewis.taylor.

yeah

so normally I will set my density to the highest fidelity I need, and unless there is some insanely detailed velocity requirement will up the Vel scale

@hanhanxue VDB point advect will still suffer from not being able to 100% push them into the smaller eddies, so I think it’s best to just own it all in the pyro sim. I took Matt’s file and just added these vortex nodes. It’s a bit heavy handed here, but vortex confinement and vortex boost along with nice substeps will give you control to make these swirls. You can click the initialize option on the SOP pyro to drop down a volumes sharpen setup. This will sharpen density _just_ a bit more, saving you some precious sim time.

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

Archived post by lwwwwwws

shit i have done to help fill in gaps between points like that: – copy the points a few times and offset each copy a different random amount along v if a pop sim, or if it’s procedural distortion keep N up to date through the distortion and move them at right angles to it to avoid making the shapes fluffier – transform to NDC, flatten in Z and calculate density by finding average distance of closest 10 points or whatever so you have a screen-space measure of how “piled up” the points are getting and can avoid adding too many in dense areas – render velocity or screen space tangent vector AOVs, dilate or infill them in comp, then vector motion blur which will follow the shapes and avoid blurring across them – vector blur in comp just based on image gradient – should be easy in cops now to do slope blur which blurs along contours instead of across, usually makes things look “silky”… it’s what you do for hair retouching in shampoo ads

Archived post by lewis.taylor.

it can be sped up

regarding creating density, here’s a little trick I use with all my sourcing. It makes the emission more natural, and reduces having bad looking sourcing visible.

mult your density with a remapped normalized age. This starts it out from zero, ramps up, and fades down

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

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