Hi, I want particle(s) to moving along a curve but always be on the curve without any offset. I have a setup where a curve have tangent vectors on its normals using sortSOP and pointSOP and inside the popnetwork I am using as source of particles the first point of the curve/path and with a VOP POP I am getting the normals from the curve using pcopen and pcfilter, normalize and passing this to the velocity of the particles. The particles are moving along the curve but sometimes there is an offset as in this example hip I have attached.

How to make it follow perfectly the curve?

instead of using particles i'd use a carve sop and a copy sop,
each copy itteration = 1 particle. that way it will always be on the curve

Seb

instead of using particles i'd use a carve sop and a copy sop,
each copy itteration = 1 particle. that way it will always be on the curve

Thanks for the reply Seb, but I cant do that because I am using later another attribute to multiply the speed of the moving based on the surface where the path/curve is attached with raySOP. I tried to do this effect in sops, including the carve approach but it can be procedural this way, I have to keyframe the speed because it is depending on $F in order to keep moving.

I think it has to be a simulation and particles seems the right way to go. This thread is actually related to my previous one: http://www.sidefx.com/index.php?option=com_forum&Itemid=172&page=viewtopic&t=28850 [sidefx.com] where you can find another attached hip which is using the carveSOP.

another thing, not sure if suitable, … if you resample the curve with an sufficient enough resolution, you could use a simple point on line ‘vex/vop’ node to correct the particle to be on the ‘curve’

Seb

If you want your particles to stick to the path you should be modifying P instead of v, since v is added to P at the end of each step.

Here's one way of doing it with VOPs and a Solver SOP where the rate of travel is scaled against an arbitrary attribute (Cd). Note that there is interpolation happening, so cranking up the speed will result in deviations from the path. If it's a problem, just kill the interpolation and crank up the point count on the path.

thanks for all the replies but I fixed it! Actually I got two way to fix the problem, the first is 80% fix, the second 100% but I think it worth to mention both for future reference.

The first solution I found, while I was observing the Details View, is that you could use a Mix between Goal Vector (Point Cloud Position-Current Position) and Tangent Vector from curve's normals. The bias of the Mix will be controlled by the length of the Goal Vector which goes through a Fit Range and the only parameter you have to set manually is the Source Max of the Fit Range with the max distance from the goal that you want the current particle to have until start mixing the Tangent Vector with the Goal Vector. This method will fix most of the problem but is not perfect in areas where the path curve changes rapidly direction.

The other solution is much simpler and 100% accurate. In theory you could use just the Goal Vector (Point Cloud Position-Current Position) as your velocity but soon you will realize that the particle moves from the emitting point to the first point of the path curve and stays there, that's because the Point Cloud Open while looking for the closest point in relation to the current position, it will always giving you the position of the first point of the curve. One solution is to create an attribute, which I named “goal”, for each point of the curve at the SOP level before the POPs where each point holds the position of the next point. Then inside you VOP POP, instead subtracting the P vector of the point cloud with the P vector of the particle, you will subtract the Goal vector from the point cloud.

In both method I use a normalize (to keep a constant speed) and an overall multiplier before I pass the Goal Vector to the velocity output. After the overall mult you can use other multiplier driven by an attribute in order to have a variation in your speed.

cheers,
Christos

P.S. in the second method the Goal vector attribute for the last point will not work because there is no next point but you can easily use a Two Way Switch where you can force goal vector for the last point to be 0,0,0.

csp
thanks for all the replies but I fixed it! Actually I got two way to fix the problem, the first is 80% fix, the second 100% but I think it worth to mention both for future reference.

The first solution I found, while I was observing the Details View, is that you could use a Mix between Goal Vector (Point Cloud Position-Current Position) and Tangent Vector from curve's normals. The bias of the Mix will be controlled by the length of the Goal Vector which goes through a Fit Range and the only parameter you have to set manually is the Source Max of the Fit Range with the max distance from the goal that you want the current particle to have until start mixing the Tangent Vector with the Goal Vector. This method will fix most of the problem but is not perfect in areas where the path curve changes rapidly direction.

The other solution is much simpler and 100% accurate. In theory you could use just the Goal Vector (Point Cloud Position-Current Position) as your velocity but soon you will realize that the particle moves from the emitting point to the first point of the path curve and stays there, that's because the Point Cloud Open while looking for the closest point in relation to the current position, it will always giving you the position of the first point of the curve. One solution is to create an attribute, which I named "goal", for each point of the curve at the SOP level before the POPs where each point holds the position of the next point. Then inside you VOP POP, instead subtracting the P vector of the point cloud with the P vector of the particle, you will subtract the Goal vector from the point cloud.

In both method I use a normalize (to keep a constant speed) and an overall multiplier before I pass the Goal Vector to the velocity output. After the overall mult you can use other multiplier driven by an attribute in order to have a variation in your speed.

cheers,
Christos

P.S. in the second method the Goal vector attribute for the last point will not work because there is no next point but you can easily use a Two Way Switch where you can force goal vector for the last point to be 0,0,0.

can you post the hip file ? i want to do the same thing