Flocking Journal:
Tim

March 12th

Jed and I got together tonight and did the sound for the movie.  Not much explanation is necessary, but I feel it is appropriate to say that this it is amazing.

March 9th

I spent some time finding and attempting to organize my code from the hierarchical structure for final submission.  Unfortunately, it's more of a mess than I thought, and I had forgotten that I'd stopped mid-implementation in light of the failed proof of concept integration with Maya, leaving somewhat disjointed code behind.

I've written a separate page for the purpose of explaining the hierarchical structure and housing the unfinished code here.

March 4th

I've created my animation for the end credits sequence, and done some work on battle scene renders for the final animation, with varying degrees of success.

March 1st

I've been working with Kevin and Chris to eliminate the medusa bug, and several other smaller scale issues.  I've put in quite a bit of time attempting to adapt Chris' code to allow new clip selection based upon character state, but such a change would require a complete rewrite of his script node, as the code is very implementation dependent.   As such, I have begun work assisting Kevin in baking animation scenes for use in the final render.

February 25 top

Kevin and Chris are otherwise occupied this weekend, so I have added death handling to the battle engine. As a result, I've had to learn Chris' code; which was no small undertaking, as it makes use of characters and clips, which are an entirely new construct to me. However, after consulting Cara a few times, I have a working understanding which I've used to "successfully" include the death animation clips. However, several bugs are still present. First, flags for animation clips are set at the start of a clip, so if I set character flags on the clip selection call that chooses death, the character who won will begin flocking movement before the death of his opponent has begun. This is problematic, as it is ridiculous looking, and cannot be called "correct" behavior by any measure. As a result, I've added some flags and logic to postpone flag setting until a later time, however, this leads to its own issue; a bug I have affectionately named the "Medusa Bug", wherein, while most of the battle carry out properly, on occasion, two opponents will approach and simply freeze in place; staring at each other perpetually immobile. However, for battles that do carry out properly, deaths and rematches are occuring perfectly. As I've been unable to pinpoint any cause for the medusa bug, I plan to verify with Chris upon his return that my assumptions regarding the working of his code are correct.

February 17

I've been working on the general behavioral control algorithm for the individual soldiers in the armies. Initial efforts into implementing this behavior focused on a Maya C++ API implementation that was worked on for the majority of last weekend. However, due to issues with coercing Maya into making use of the designed class hierarchy forced the effort to be halted in favor of a less efficient but more certain MEL based implementation. Whereas the C++ implementation would use a class hierarchy of objects, each of which could be containers for a group of instances of a child class of the parent object class, which would allow for vastly improved computation times. However, these speed bonuses are not implementable in MEL by any reasonable means, as object orientation would be a required feature, as would the concept of a pointer assignment and traversal. Secondly, the speed bonuses would not be significant at any time except during times during which soldiers are measured as members of a particular group without individual behavior, a situation which would arise in the actual animations for a grand total of 20 frames or so. After this, the groups would be split so far as to be working within individual behavior once more.

The implementation has had a few minor issues. First, it completely lacks any type of collision detection and avoidance, and as such groups of fighters tend to clump together in a large pile. Early attempts at adding this functionality have met with failure, as the computation of the complete motion paths of the rock fighters is controlled by modifying their parameters based upon those of the block fighters they're currently assigned to be "engaged" with.

However, despite the issues, this implementation does have several extensive advantages. First, once collision detection/avoidance is implemented, the module will be capable of running autonamously with minimal parameter setting for any scene construction that we'd wish to build. An arbitrary number of "modes of operation" allows us to easily define new behaviors in nearly any way we so choose, as well as control the frequency with which they occur. However, this all hinges upon successful control of collision issues, the simplest solution to which thus far has been an algorithm with a O(n^3).

The code for the behavioral control sample clip is available here.
A playblast of the resulting animation is available here.

UNDATED JOURNAL ENTRY

Communication between Kevin and I has been rather light despite the meetings we’ve had, and after going over the work he’d managed to complete with a pure boids implementation, and considering the issues that were arising with the C++ API, as well as the amount of time remaining in the quarter, I concluded that, at least for the moment, the better course of action would be to work on a system that more directly integrated with what he’d already accomplished for the purposes of having a complete, running system, with an option to go back to the C++ API should time permit. As a result, I began work on a general behavioral control algorithm in MEL which would, while being significantly less efficient, would at least provide reasonable behavior in case of a massive failure of the C++ option. The MEL script eventually derived was designed to be both a proof of concept and a basic outline to which new behavior could easily be added. This was accomplished by adding an integer attribute to each soldier which provides for a “mode of operation”, allowing multiple types of behaviors to be implemented and easily switched between by simply setting the flag to the proper value. The temporary result provided for two armies of cones that could successfully match for battles, chose a “winner”, and allowed the victor to move on to another opponent, or continue on his predefined path. It is hoped that with collision avoidance and integration with Kevin’s flocking code, we can implement a fully autonomous system.

UNDATED JOURNAL ENTRY

I've put in some work lately on attempting to get the C++ API to work, and have hit several walls. At first I had Visual C++ 6.0 installed, and was unable to get the Maya Plugin Wizard to work with it in any capacity. After fighting it for a while, I broke down and went to the SOC lab to pick up Visual Studio 2005, which, after installation, had a plugin directory structure that seemed to take the Maya Plugin Wizard installation, but attempting to create a new project with it was a failure. I finally returned for .NET 2003, which, upon installation, successfully recognized the plugin wizard and created projects. I spent the majority of the weekend working on implementing the behavioral control class hierarchy in such a way as to successfully manage the armies. After successfully completing a plugin compile and creating several test applications from the handbook, I attempted to integrate the behavioral control code with the C++ API, but met with some resistance. At the end of the weekend, the code had still not yet been successfully integrated.

UNDATED JOURNAL ENTRY

I've put in quite a bit more work on determining an optimal solution to the behavioral constraints we're seeking for the final flocking behavior and I've come up with a solution which will both allow us full behavioral control and get us great computational efficiency on a per-frame basis. This is accomplished through a class hierarchy relying on a single parent class of Objects. The highest level of data is a linked list of pointers to objects that is parsed each frame for each object, and each object's position is updated based upon a stored vector of direction and a scalar velocity. The great part of this algorithm is that the child classes of the object class will not only consist of the objects themselves, but of container objects which will allow fast updating of larger numbers of objects as well. For example, at the start of the battle, one army is located on one side of the screen, and the other is on the other. At the highest level, what is represented in the linked list is not separate pointers to each individual soldier, but to the armies themselves, so each army's behavior will be enacted. The army will update the position of all its own internal objects (which in turn update their own internal objects) until all objects are moved in the frame. Since the behavior for the army controls the behavior for the lower levels, complex behavior computation for the lower levels do not need to be computed. As the armies close in, the distance between them decreases, and a distance function monitors this. When it becomes less than a certain delta, the army breaks up (i.e, the pointers it contains to its own internal objects are now set in the high level linked list. Now, instead of pointing 2 armies, for example, the high level list is pointing at 10 batallions). These batallions function in much the same way as armies with automatic updating. In our planned implementation, the next lowest level will be the soldiers themselves. As 2 batallions approach, the distance between them decreases. At the point it becomes less than a certain delta, the internals are touched to check for soldiers to break off. Soldiers at the "front" are easy to determine, as each soldier will contain an array to 4 object pointers that correspond to the soldiers on any of the 4 sides of them (they are in rank and file by default when not working by themselves). As such, front souldiers are any soldiers who have a null pointer in the [0] array position. These soldiers are then broken off and added to the upper level linked list to function as individual objects with individual behaviors. Enemies are then paired and allowed to battle (as implemented by Chris). When they finish, it is easy to add a soldier lacking a clear goal to a floating batallion by simply attaching a pointer to him to the batallion object and updating one of the already present soldiers that is at the back (null pointer in position [4]). In addition to the class hierarchy efficiency increase, behavioral control is easily implemented. This algorithm would require the use of the Maya C++ API, as MEL provides no object oriented constructs which would allow for this type of implementation.

UNDATED JOURNAL ENTRY

Kevin has begun implementing some simple boid behavior, and has shared the results. I've added some improvements to his test setup by writing a script for random placement of the cones within a square grid, and implementing a pseudo-infinite plane by wrapping one end to the other. I've been doing some experimentation with overall scripts for generating scenes, and have made some use of Kevin's discoveries in regards to expressions and script nodes. However, my major focus remains on attempting to provide for behavioral modifications to the traditional boid behavior.

UNDATED JOURNAL ENTRY

I've been working lately on ways to modify the boid flocking behavior to exhibit behavior one would expect from a humanoid army. Thus far, most of the work has been conceptual in nature, and implementation has not been forthcoming, due to both the MEL learning curve and the inability to get the C++ API to successfully work in even simple compilings.