Last edited 14nov11 by email@example.com
Orndroids: a look at flock movements
I intend to find a way to model and display the movements of a flock of bird- or fish-like simulations in three dimensions. I have done this by creating three Rules that all Orndroids(Orns for short) follow. The rules are as follows:
Rule One: A Tribe of Orns will always congregate towards their central point as defined from thir current positions.
Rule Two: Orns will avoid each other by moving away if they get too close to each other.
Rule Three: All members of a Tribe will match each other's velocities eventually.
By following these Rules, the Orns are able to move in a flock like manner. I have even placed them into Tribes, which only interact with each other by avoiding each other.
My ultimate goal is to migrate my code over to PyOGL and into The Cube.
This project is a revival of the original Boids project by Craig Reynolds. I originally had the plan to do this when I was trying to decide on a project for this course while talking with my brother. He suggested doing Boids which, from his description, intruiged me. I looked into it, and it was a very interesting project, so I decided to do more with it, and the results are what are shown below. This was no simple task, however, as most of the sites associated with the original Boids project were either dead or full of links to dead sites, making finding a starting point a slightly difficult task. Luckily I struck virtual gold when I found a site containing the original pseudocode write-up of Boids by Reynolds. Using this pseudocode I thusly was able to divine my current functions, but with very rough equations that have since been smoothed somewhat to produce a relatively fluid-like motion for the Tribes.
The program is run by simply running the program. The amounts of Orns and Tribes can be changed by altering the appropriate variables, aptly named numB and numTribes respectively, to be whatever is desired, compiling the script, and running the program again.The Orns can also be "reset" or scattered mid-flight by clicking the left mouse button, thus now making it able to much more easily observe the initial coalescence of the Orns, which can be interesting to watch.
Here you can see the orndroids shortly after initializing and still in their starting clump.
The orange sphere in the center of all of these pictures is merely a placeholder
to show where the origin is in reference to the Orn's
The yellow arrows present in most pictures are the Orn's individual velocity vectors to better see where exactly the Tribe is moving.
It also makes them look slightly more birdlike, with a "beak" and everything.
Here the Orn's have began separating into their Tribes. In this example, there were only two Tribes, but I've done some simulations with up to ten Tribes.
Here are more pictures of the Orn's.
In the first("Here"), the five Tribes are indicated by the yellow lines that I have drawn in. The other two pictures are differing numbers of Tribes in various states of motion.
I have fixed a previous problem where a Tribe would only obey rule 2 for members within its own group; it would simply ignore the others. I hadn't noticed this issue until I changed the program to display in 2D instead of 3D. The fix for this was a small piece of code that would do an extra check for the positions of the other Orns.
This works because it is the code for rule 2 but on a smaller scale. Where rule 2's code would only move if the positions were within a decently sized radius, the new function checked within a much smaller radius and moved them away much more severely, as if you were walking down a hallway, looked up, and saw a person right in front of you. You wouldn't slowly move out of the way, if you did that you and the other person would collide. Instead, you would move quickly and, for example, jump out of the way, thus putting much more distance between you and the person.
In this way, the Orns "watch" each other much more closely. Now that the code has been implemented, the Tribes no longer pass through each other without noticing, as they did before; instead, they react to each other and will possibly separate in order to pass through another group.
Before now, the program would always evenly distribute the number of Orns amongst the number of Tribes.
For instance, one possible outcome would be:
As can be seen, the distribution remains even, so much so to the point that it will flat out not implement Orns if they will break the symmetry. What I did was make the program go one at a time, and each time it would increment an array containing the sizes of each Tribe. Once the number of Orns implemented equals the number of Orns to be, the program moves onto the next phase, which is runiing the movements.
||Number of Orns|||Number of Tribes|||Orns per Tribe|
Taking the previous example, the new distribution would be:
This time, the program put the extra Orn in Tribe 1, breaking the symmetry but allowing full implementation of the full number of Orns rather than ignoring those that would break symmetry.
||Number of Orns|||Number of Tribes|||Orns in Tribe 1|||Orns in Tribe 2|||Orns in Tribe 3|
I have worked towards making my code more object oriented by thus far creating an Orn class. One of the problems so far is that I am having issues with getting the class defined Orns to update either the positions or their velocity arrows. Other than that, it seems that object oriented Orns would be a very distinct possibility.
I have implemented a velocity limiter so that the Orns won't eventually speed up until they go insanely fast to the point of being untrackable.
Using mouse inputs, I have implemented a resetting feature that enables the user to randomize the Orns' positions, effectively recreating the starting conditions of the program where the Orns have to regroup into their collective Tribes.