Is there a way to constrain particles to a surface while they are movi

[magneto]

Hi,

 

Is there a way to constrain particles to a surface so they can never move away from it but only on its surface regardless of the forces applied?

 

I am using the new particles. I tried the old Creep POP but that also didn't work and seems very limited.

 

 

 

Thanks

[rafaelfs]

You could use the old volume sample/gradient trick, no?

 

cheers

[magneto]

Thanks Rafael, I didn't think of using that. I will give it a try. My geometry is a grid though. So if I add thickness to it, then the particles won't be just on the grid but around the other side too, right? I will still try this in a closed surface to see how well it works.

[narbuckl]

Ray Sop, point cloud lookup, transform position data to uv space, creep sop (UV based), lattice warp, SDF gradient as mentioned before but you would need to make something with volume.

 

 

[Aliencorpse]

Blows me away that houdini doesn't ship with a bary bind.

[tjeeds]

If you're using DOPs the easiest way is to use the Minimum Position VOP

surface_particles.hip

[magneto]

Thanks guys, all great ideas

 

@narbuckl:

 

Ray SOP seem to work great. For the point cloud method, you would need a high point count to get the points on polygons, right?

 

UV idea is also interesting. Creep would be limited to NURBS I think. Is Lattice Warp, Lattice SOP > Deform by Points?

 

I need to check out the SDF method.

 

@tjeeds:

 

Minimum Position VOP is great. I never used it before. Though even after doing some adjustments, the particles quickly end up at a few specific positions even when I move them wildly with forces. Do you know if there is a way around that? I did add a Mountain to the grid to see them moving on the surface of a deformed grid.

 

There is also edge artifact this method shares with the Ray SOP which I will make a new thread because it happens in other VOP/SOPs.

 

Thanks again all

[narbuckl]

Hey Magneto,

 

I wanted to make an example of how I would use an SDF to keep points sticking to a surface, I tried to make this example workable for whatever your situation may be. Have a looksie, hope it helps. For more accuracy increase the uniform div of the SDF.

 

 

-N

sdfStickToSurface.hip

[magneto]

Thanks narbuckl, I tried sdf on a sphere and got some particles sort of going above the sphere at certain regions. Not sure why.

 

I looked at your file, and it looks great. I replaced it with a grid that has thickness but the particles only spawned on the top surface, but it still seems to show some artifacts. If you play it, you can see some particles in the center of the grid act as if stuck on 2 lines? Also some of the particles escape the surface.

 

Not sure if it's a trivial thing to change but so far Ray SOP worked the best. It also supports open surfaces like a grid so that's a good advantage too. Though I didn't try it with a very complex shape like a statue.

 

Actually that would make a good case to compare different methods

sdfStickToSurface2.hip

[narbuckl]

Hey Magneto,

 

 

I grabbed your scene, decided to use vdb's instead for the SDF's, and just upped the substeps to 2 on the dop. Looks like it works smoothly to me. The ray sop is fine for simple surfaces but when you get a lot of concave/convex surfaces it will have popping issues unless you iterate over it on each frame to get a new ray relative to the newest point position.

 

-N

 

Edit: Just wanted to add, the particles only spawned on the top because only the top part of the geo was plugged into the first input of the dop which is what I used to source the points. You can emit from wherever, what I did was create an attribute that records when the particle has touched the SDF and from that moment on the particle will not leave the surface.

sdfStickToSurface3.hip

Edited January 27, 2014 by narbuckl

[tjeeds]

Minimum Position VOP is great. I never used it before. Though even after doing some adjustments, the particles quickly end up at a few specific positions even when I move them wildly with forces. Do you know if there is a way around that? I did add a Mountain to the grid to see them moving on the surface of a deformed grid.

 

There is also edge artifact this method shares with the Ray SOP which I will make a new thread because it happens in other VOP/SOPs.

 

I had noticed particles gathering at the edges of deformed geo, though I haven't seen this in the past. When you are talking about particles ending up at a few specific positions are you possibly seeing sink points in the noise field? If you animate the offset or use a non-divergent noise such as Curl Noise this should go away.

 

Also the Minimum Position is just a convenience function for XYZ Distance combined with a Primitive Attribute that gets P from prim/uv. If you need other attribs besides P you can just got that route. Keep in mind that these are great for polygons and very slow for NURBS.

[magneto]

Thanks alot nabuckl, it works great I was using the Minimum Position of Ray SOP but the particles were getting concentrated on certain sections.

 

Your method is better. If you did want a thin surface like a non-extruded polygonal grid, what method would you use? Creep is out because of NURBS, so is SDF, right? Just curious

[narbuckl]

Haha, just realized that I had the integer plugged into the color and i was only seeing the points that touched the surface, to make those points that are 'escaping' not escape just change the float on compare in the Vop Pop. If you increase it to 1 instead of zero it should grab everything.

 

-N

[narbuckl]

In regards to your other question about a paper thin surface, I would say that it depends on what you want the points to do. You could always simulate them on the static grid then deform the result when you deform the grid. That us probably the most controlled way of doing it. If you wanted the movement of the paperthin surface to affect the particles you may have to do something like set up a sop solver that looks at what they particles would be doing and transfers it back to the static result before actually deforming them to match the surface. Just my 2 cents

 

 

-Nathan

[magneto]

Thanks tjeeds. I made a thread about gathering at the edges but so far no one commented on it. Probably a mystery?

http://forums.odforce.net/topic/19323-whats-the-reason-of-the-grid-patterns-visible-in-many-vopsops/

 

As for particles ending up specific positions here is a picture that shows it better, where I show frame 1 and frame 300:

 

 

I never thought about the sink points in noise fields or heard of them before but I am using a POP Force which uses a Curl Noise if I am not wrong, so that should be out?

 

Thanks for the xyzdistance and primattrib tip. It didn't occur to me to use it that way to get P like Minimum Position VOP. Is that VOP new or an old one, because I never noticed it until you mentioned it.

 

 

 

 

Thanks narbuckl, I changed it to 1, looks better. But plugging that value into color shouldn't be a problem, right? I unplugged that too anyway. As for the open surfaces, I think they are minority but still makes it an interesting exercise as you can't use SDF< creep but another method. I will give it a try. Basically just randomly moving particles around while they can only move on the paper thin surface.

 

 

 

Thanks again guys

[anim]

while simulating you need to introduce the change in v as well not just stick it to closest P otherwise it's very likely that particles will stay in some areas

the same for SDF method

 

for paperthin geo you can use Min Dist or SDF, it doesn't really matter, SDF may be faster for sim, since it's just lookup, but you will need to build it in Volume VOP so overall it may be slower than Min Dist, but that all depends on complexity of your geometry and on the other side you can always cache sdf as well as introduce slight smoothing which may help in some cases

 

 

xyzdist() VEX function is there since 12.5.260 and it's pretty useful one, I found myself using it all the time

there is plenty of cool functions that are introduced all the time, it's worth to keep track of them even if they are not all documented, you can see many of them being used in SESI tools and libraries

[tshnrk]

clothBind and clothDeform?

[magneto]

Thanks anim, I didn't think about that. Would you directly set the particle velocity to the difference between current position and the closest position on the surface? Maybe add it using the Add Wind Force VOP?

 

Also you said it's better to modify force than velocity. Does it apply here?

 

How do you find out about the new nodes/functions though? Going through other people's files seem to help alot. Also checking built-in HDAs like you said, though I only do that once per node, and most likely never come back inspecting the same HDA later on. That's why I asked

 

@tshnrk: How do you do that? I never heard of Cloth Bind. Should probably take a look at it. Though I am not sure if it would allow wildly moving particles to be constrained to a surface like other methods mentioned here.

Edited January 28, 2014 by magneto

[anim]

Would you directly set the particle velocity to the difference between current position and the closest position on the surface?

something like that,not set but add

in wrangle syntax it would be like

@v += (v@newP-v@oldP)/@Timeinc;

where newP is the closest position on the surf and oldP is the original particle position

 

Also you said it's better to modify force than velocity. Does it apply here?

no, it's a little different, you are not changing v here to introduce force, but because you've moved the particle by yourself so you need to update the v to reflect that so you can access it in the same timestep instead of next one (as it would be if you updated force, which is still better than nothing)

 

How do you find out about the new nodes/functions though? Going through other people's files seem to help alot. Also checking built-in HDAs like you said, though I only do that once per node, and most likely never come back inspecting the same HDA later on. That's why I asked

usually by exploring SESI's code being it wrangle nodes or VEX libraries, lot's of cool stuff there

the usage is usually logical, but if not, then I leave it for later

 

Edited January 28, 2014 by anim

[magneto]

Thanks alot anim, I will try the velocity thing today. It makes alot of sense.

 

Lastly when should I be using Timeinc in my code? I didn't realized I had to here. So if I had to update force, I would use Timeinc there too? If that's the case, should you also be using it in VEXpressions to change parameter values?