Follow Pop-trigger Event Upon Reaching The Leader?

[Vormav]

Hey. I'm working on a simple crowd simulation, largely based around the Follow POP. The only problem is, I can't figure out a reliable way to decide that a particle has reached its goal (leader). The follow pop doesn't set any events itself, nor does it place any points in groups based on whether or not they've reached the leader, and it also doesn't even seem to set a "stopped" attribute when the "stop at leader" option is used.

First thing I thought of was to the 'stopped' attribute. But since the follow pop never seems to set that (unless I'm completely screwing something up), that's obviously out. Second, I could just test to see if all velocity channels are zero, and if so assume that they've reached the leader. Not a very good assumption, since any number of events along the way to a goal could also cause this event to occur (the same could also be said of the 'stopped' attribute). But that's what I'm doing right now anyway, through a group POP, and it at least works.

It seems to me that the only truly reliable way to test this would be to set all of the leaders as a separate particle attribute, and test the positions of each particle's leaders against their points through VOPs. And really, that's not exactly the biggest challenge. It could probably be done with as few as 5 VOP nodes (2 import attributes, 2 parameters, and a distance vop). That's just fine and great. But since I can foresee myself needing to do this many many times in the future (unless there's a better way of flocking points to goals that I should be looking into), I just want to make sure that I'm not missing any built-in ways for handling this (it just seems like one of the things that would definitely be in there). Creating a separate node to run the test is a redundant process, since my follow pop is obviously already doing it. Not really a waste of resources that's worth crying home about, but just want to check.

[sibarrick]

Pops aren't really my area, but could you use the proximity pop to test if the distance is less than a threshold, and create an event based on that?

[Vormav]

Pops aren't really my area, but could you use the proximity pop to test if the distance is less than a threshold, and create an event based on that?

26238[/snapback]

It's a good idea, but I've never had much luck with the Proximity POP. The problem I've had with it is that it's kind of hard to isolate the different groups with it: Set the source group to one group (say, the leader group), and it only checks the proximity of points in that group. Don't set any source group, and one of the particles might decide that it's near one of the leaders because it picks up another non-leader particle within the proximity radius. Even if I did have it so that the groups could be separated, so that leaders would only see how many flocked particles are within their radius, there's a chance that the particle that's passing by within their proximity radius was never directed for that specific goal at all - it could have just passed near by that leader on the way to another one behind it.

And as long as I'm on POPs, might as well try to squeeze another question in there that I stumbled upon: I noticed that after defining a radial force and a radius for SOP points, and then pointing to these with an Attractor POP, the particles are still affected by the radial force even when they're waaay out of the range of the point radii. I guess this is confusing me, because I was under the impression that the radial force only has an effect within the range of the radius...no?

[sibarrick]

Ah I see. Well if you do end up writing your own pop I would consider using point clouds to speed this up. I've never used them in a pop context but if they are available they are 100's of times quicker for doing proximity searches. Be aware though that there were issues using them in vops, I tend to always write point cloud code by hand because I could never get it working with vops. Hopefully its been fixed, but just a heads up.

[Vormav]

Ah I see. Well if you do end up writing your own pop I would consider using point clouds to speed this up. I've never used them in a pop context but if they are available they are 100's of times quicker for doing proximity searches. Be aware though that there were issues using them in vops, I tend to always write point cloud code by hand because I could never get it working with vops. Hopefully its been fixed, but just a heads up.

26247[/snapback]

Right, thanks for the tip. I've never actually been too clear on the proper usage of point clouds, but this is probably a pretty good time to learn.

[Mamoru]

A quick test shows that the follow POP seems to change the pstate attribute to 768 on the particles that stop. Being an expert in bitfields, as I'm sure we all are, I'll observe that 768=512+256. Further, having access to the HDK, as I'm sure we all do, I'll refer to GEO_PrimParticle.h and identify these two flags as $SUPPPOS and $SUPPVEL.

Certainly not at all obvious, intuitive, or documented, but there you have it. Do with this ill gotten knowledge what you will.

[Vormav]

A quick test shows that the follow POP seems to change the pstate attribute to 768 on the particles that stop.