Particles along curves, make particles explicitly follow/choose a curve.

[bloodhawk]

Hey guys,

Kinda Intermediate at Houdini and a recent full time convert from the 3DSMAX/TP world.

I have been working on a tool, where the user can easily plug-in curves and generate art direct able particle flow along the input curves.
Its about 90% done, and it works great with curves that are not too close to each other or don't intersect each other at too many points. How ever in certain scenarios. like multiple inward spiral curves intersecting each other, since the POPVOP system is based on Particle Cloud Search :

- PC Open to look for particles close to the curve points.
- Use those points and push them along the length of the curve using the curve tangents.

, the particles get attracted towards either curve based on the search radius and no. of search points. This is definitely understandable, on why its happening. But is there any way to lock/tie the particles to specific curves only?

The Radius and No. of Points parameters give it a lot of control for most scenarios, but the one mentioned above. Obviously there are a lot more parameters that i have added for dictating the flow behaviour.

But the main solution that i can think of is to have the “found” particle only follow the curve and be affected by the parameters along that curve ONLY.
Maybe have a POPVOP decide groups for the curves/particles?

 

TLDR; Need to make the particles only flow along the curve it chooses/gets attracted to at the beginning.

I have never worked with groups in POPNET, so im pretty much lost.

Unfortunately because of my limited knowledge at Houdini i haven't been able to figure out how to achieve this. Would really appreciate some help on this.

 

Edited August 5, 2016 by bloodhawk
TYPO

[dayvbrown]

Hmmm bit of a tricky one, my first thought was "do they actually need to be simmed particles?"

 

If not then you can use a whole bunch of easy sops tricks to deal with this. As always that talented trouble maker Matt Estela has a wiki page on exactly this http://www.tokeru.com/cgwiki/?title=Houdini#Slide_points_along_edges

You could easily add to and expand these setups to give you those nice shapes by adding in some noises for variations in P along length and speed etc. Might not be the completely ideal situation being out of Dop land but could give you some ideas to try, and can be used nice and quickly in sops.

 

I've used this technique in the past whilst using a basic popnet to birth the points so I have easy access to things like id, age\life. Using this setup ("static" popnet plugged into a few vops) should give you a whole bunch of control.

 

Some other dops-ey thoughts were about randomly assigning particles to groups (modulus id's limited to some parameter for no. of groups) and assigning those groups to primnumbers perhaps.

Cheers.

Edited August 4, 2016 by dayvbrown

[fuat]

when You scatter points on geometry, you get an integer attribute called "sourceprim" (in the scatter SOP, see the Output Attributes Tab), which tells on which prim your points are scattered from/on. so later on in POPs, when doing your pointcloud lookup, you could use this sourceprim attribute to limit your loop up search. like "if primID equals 7, dont use this curve".

or, as you suggested yourself, doin it by primgroups. that is maybe the much easier way.

but bit are just a guess, dont have ot build in front of me.

hth

fuat

 

[bloodhawk]

8 hours ago, dayvbrown said:

Hmmm bit of a tricky one, my first thought was "do they actually need to be simmed particles?"

 

If not then you can use a whole bunch of easy sops tricks to deal with this. As always that talented trouble maker Matt Estela has a wiki page on exactly this http://www.tokeru.com/cgwiki/?title=Houdini#Slide_points_along_edges

You could easily add to and expand these setups to give you those nice shapes by adding in some noises for variations in P along length and speed etc. Might not be the completely ideal situation being out of Dop land but could give you some ideas to try, and can be used nice and quickly in sops.

 

I've used this technique in the past whilst using a basic popnet to birth the points so I have easy access to things like id, age\life. Using this setup ("static" popnet plugged into a few vops) should give you a whole bunch of control.

 

Some other dops-ey thoughts were about randomly assigning particles to groups (modulus id's limited to some parameter for no. of groups) and assigning those groups to primnumbers perhaps.

Cheers.

Unfortunately, it needs to be a simulation. I actually started working on this with a lot of help from Matt's page, amazing resource for so many of us new comers to Houdini.

The Modulus way sounds interesting, im just not able to understand how to implement it because of my limited knowledge.

Thank you for the reply

48 minutes ago, fuat said:

when You scatter points on geometry, you get an integer attribute called "sourceprim" (in the scatter SOP, see the Output Attributes Tab), which tells on which prim your points are scattered from/on. so later on in POPs, when doing your pointcloud lookup, you could use this sourceprim attribute to limit your loop up search. like "if primID equals 7, dont use this curve".

or, as you suggested yourself, doin it by primgroups. that is maybe the much easier way.

but bit are just a guess, dont have ot build in front of me.

hth

fuat

 

 

I actually went that way with the latest version, since i already had the sourceprim attribute, i created a curve_id attribute (someone actually suggested this) based on the primnum of the curves. 

I get stuck after that, since im not able to implement those conditions. Im sure its something easy that im missing, but due my still somewhat limited knowledge of loops / conditions and comparing attributes using pcopen in VOPs im left scratching my head on how implement it.

It took me a whole day to figure how to use the curve tangents to push the particles along. 

Thank you for the reply!

[mestela]

This isn't quite right, but might give you some ideas.

The core thing is the same as directly pushing points along curves, but left in a more pop context, so you can mix in forces and whatnot. The procedural way sets P directly, either with an attrib interpolate, or by reading P on a given curve at a certain uv:

v@myuv.x += 0.01;
i@mycurve = 0; //   can set this when the particle is created so that each particle only goes to 0 (the first curve) or 1 (the second curve)
@P = primuv(1,'P',@mycurve, @myuv);

To use this with pops, you don't set P, you can calculate the vector that aims from the current particle position to that target, and add that to v:

v@myuv.x += 0.01;
vector target = primuv(1,'P',@mycurve,@myuv) - @P;
@v += target;
 

The attached setup is very twitchy; make the particles move too fast, and they no longer stick to the curve. There's a Clever Way to make the force be proportional to the particle speed, so they can travel as fast as they want and stay on track, but its more than my brain can handle at 2:30am.

 

-matt

Simple_Setup_v01.hipnc

[bloodhawk]

1 hour ago, mestela said:

This isn't quite right, but might give you some ideas.

The core thing is the same as directly pushing points along curves, but left in a more pop context, so you can mix in forces and whatnot. The procedural way sets P directly, either with an attrib interpolate, or by reading P on a given curve at a certain uv:

v@myuv.x += 0.01;
i@mycurve = 0; //   can set this when the particle is created so that each particle only goes to 0 (the first curve) or 1 (the second curve)
@P = primuv(1,'P',@mycurve, @myuv);

To use this with pops, you don't set P, you can calculate the vector that aims from the current particle position to that target, and add that to v:

v@myuv.x += 0.01;
vector target = primuv(1,'P',@mycurve,@myuv) - @P;
@v += target;
 

The attached setup is very twitchy; make the particles move too fast, and they no longer stick to the curve. There's a Clever Way to make the force be proportional to the particle speed, so they can travel as fast as they want and stay on track, but its more than my brain can handle at 2:30am.

 

-matt

Simple_Setup_v01.hipnc

Wow that helps a lot!!

This just strengthens my friends suggestion to work with wrangles instead of VOP's.

Im still trying to wrap my head around certain parts of the wrangle, but this is a great start for me!

Ill reply again here with a few questions later on today!

Thank you so much Matt! You da mayne.

Edited August 4, 2016 by bloodhawk

[mestela]

Nuthin wrong with vops, I use them all the time. Just happens in some cases it's faster to write a few lines of vex then to wire up several nodes.

[bloodhawk]

True but, if you look at the rest of my VOP network, that isnt in this file, there is nothing in there other than Turbulence that cannot be done with a few lines of code in VEX. At least that's what i have been told haha.

Edited August 4, 2016 by bloodhawk

[Farmfield]

12 hours ago, mestela said:

Nuthin wrong with vops, I use them all the time. Just happens in some cases it's faster to write a few lines of vex then to wire up several nodes.

I especially like your completely redundant use of a VOP to normalize N followed by creating an attribute that you never use. Like I'm confused enough just being awake.  

Really cool solution, Matt. There was a couple of redundancies that confused me at first, before realizing there were some leftovers from setting this up, but what actually did confused the shit out of me was the attribute transfer. I really didn't get it until I realized you did that to reverse the vector. But seeing you're so fond of them, I would have thought you'd do that with @N *= -1; in a wrangle SOP.

So now I learned a 4th way of doing particles along a curve, all with their specific pro's and con's. I friggin love Houdini.

Edited August 5, 2016 by Farmfield

[eetu]

One time when the particles really needed to rigidly follow curves, I just used Carve SOP to extract points from the curves. Simplistic, but easy & fast

(and easy to get some motion blur tail while at it)

Edited August 5, 2016 by eetu

[Farmfield]

Alla sätt är bra utom dom dåliga.

^ Swedish insult aimed at anyone reading it.

[bloodhawk]

Matt's solution worked really well, and i modified it a bit after using a point cloud to search for points and figure out a way to make them follow the curve even if the speed is way too high. (with help from our a very experienced FX lead)

Now the only problem left to tackle is to figure out is when the same curve intersects itself. This is a scenario where the point cloud method falls apart sometimes.

Edited August 5, 2016 by bloodhawk

[Farmfield]

A self crossing would be short, so if you sample 1-2 frames ahead and 1-2 back, you can average it in one direction, at least if it's not at a too shallow angle.

Edit: And I'm talking about velocity if that was unclear, hehe...

Edited August 5, 2016 by Farmfield

[bloodhawk]

2 hours ago, Farmfield said:

A self crossing would be short, so if you sample 1-2 frames ahead and 1-2 back, you can average it in one direction, at least if it's not at a too shallow angle.

Edit: And I'm talking about velocity if that was unclear, hehe...

Yes sir, figured at much , after a bit of confusing looks.

But sometimes the angles do get a bit crazy.

[mestela]

Yeah, thinking out loud you might need to do something like store the previous @uv position, then use nearpoints() to get the closest maybe 3 points of the curve, iterate through each to find the corresponding @uv of each, compare to the particles previous @uv, and use the one which is closest. 

 

-matt