Just in case it might be of use to anybody.
http://draconiansolo.wordpress.com/2010/01/01/flocking-system/
it's messy but i think it can be useful.

Recently, I finally got my head around comparing angles and did a little prototype that produces flocking behavior through simple Braitneberg type interactions. Its not nearly as sophisticated as fdevant's but it might have potential for anyone looking to explore.

As of this post its my most recent sketch at R6753.com. The top left picture or direct link to the applet.

Hi! This reminds me about something I was trying to do, but couldn't get to work. In my case I had a flock chasing a single point (defined by a motion detection system in a video stream). My problem occurred when the angle came close to 0, where I would have either a value of close to zero, or a value close to 2PI. This made my flock behave erratic, or just turn away from the point, instead of chasing it(!). Was this a problem that happened to you as well, or did you not get that problem? I see you use ATAN2, which is what I was using as well ... Am I making sense?

I'm glad you people find this useful.
I promise i will make a cleaner version for you to use, and who knows, maybe eventually a processing library.
Meanwhile i'm having a little trouble [laziness] with space partitioning... gonna code quad/oct trees eventually.

Mmmh, the way i dealt with 0 distance was to make any steering vectors equal to 0 when distance was less than 1. that way, they just kept their inertia while they went back to reasonable distances.

Rick wrote on Jan 4^th, 2010, 8:10am:

Negative angles and those close to zero need to be seen as similar or close to ones that are nearly a full circle like 357 if you're using degrees. The same thing happens for angles that are greater than a full turn like 370 in degrees.

To work with them you can add a full circle if the angle is less than (or equal to) zero and subtract a full circle if the angle is greater than (or equal to) a full turn (360). Angles like -5 become 355 and 370 would become 10. See the remap() function at the end of my code. I'm using radians there.

I had run into similar problems to those knutEinar was having and it took me a while to figure the whole thing out.

But using your method, is exactly where and when I get my problem, because then the two angles, say 10 and 355, which is only 15 degrees apart, will look like they are 245 degrees apart. So how do I fix this A bunch of if/elses

If you use radians instead of degrees and use atan2() to solve them, you'll probably not get those problems anymore.

fdevant wrote on Jan 6^th, 2010, 12:40pm:


I did use radians and atan2, but still could not figure it out. I have it working now, but I had to use a bunch of if/elses as I suspected. Not sure if I can do it any other way.

Here is the code I used. I know it can be simplifid, I just wanted to type everything out, to make it clearer to myself

void checkAngles(){
 v2ang += TWO_PI;
 v2ang %= TWO_PI;
 //
 fill(0, 102, 153);
 textFont(font,20);
 text("v2ang = "+v2ang, 15, 30);
   text("v1ang = "+v1ang, 15, 50);

 if (v2ang > v1ang){
   // ok, this means that v1ang is closer to 0 degrees, than v2ang, but it does not say anything about which quadrant they are ...
   // then ...
   if( v2ang - v1ang > PI){
     // if the difference is more than PI, i.e. a half circle, then the angle is obtuse,
     // and the fastest way to get closer to the other angle is to increase it ...
     v2ang += TWO_PI/200;
   }
   else {
     v2ang -= TWO_PI/200;
   }
 }
 else if (v2ang < v1ang){
   // this means that v1ang is closer to TWO_PI than v2ang is ...
   // subtract the smaller from the bigger ...
   if( v1ang - v2ang > PI){
     // again: if the difference is more than PI, i.e. a half circle, then the angle is obtuse,
     // and the fastest way to get closer to the other angle is to increase it ...
     v2ang -= TWO_PI/200;
   }
   else {
     v2ang += TWO_PI/200;
   }
 }
}