Flocking Journal
Posts: March10 March7 March4 March4 March2 Feb27 Feb22 Feb21 Feb16 Feb15 Feb9 Feb8 Feb7 Feb4 Feb3 Jan26 Jan23 Jan16
March 10 top
I finished my credits sequence. I'd like to add faces of me where I'm older than 11, but hopefully that won't be too involved. Ideally I'd like to have at least 5 different faces. I'm going to try to spend a bunch of time documenting all of my work and posting my code. I heard that we don't need the code to be too clean. THANK GOD. My code looks terrible. Seriously, its probably better that you just understand it works. creditscene
March 7 top
I built a very large battle scene with three different bakes. The first pass was simply a ton of dudes (130) fighting. After that I attached obstacle spheres to them and put about 50 rock guys on one side that flocked up to the battle. I repeated the process with 50 paper guys, making for a 230 guys. Needless to say that it takes a while to save and load. The idea is that we can pick smaller fights and all the area around them will be filled with guys. The scene is saved in: D_03/scenes/0603006_LargeBattleBake_KJ_05.mb a sample render is here. I also added a ton of guys to the catapult scene. A render of that is here. The next thing to do is document all of my work and add the rag doll explosions to the battle scene.
March 4 top
Ok, I lied. If you notice in the large battle scene when two guys prepare to fight they snap together. This looks bad enough that it should be fixed. Hopefully this can be done with one line of code. Too bad the large battle render will have to be re-baked.
March 4 top
Well, I know the code was supposed to be finished by the beginning of last week, but what's two weeks really? The flocking code is DONE. Any future problems will be fixed in the key framing stage. A majority of today was spent on setting up the scripts for the scenes. Right now the flocking / battle behavior is in 3 basic scenes. 1. The first battle scene when the armies approach each other. 2. The scenes where the rock guys are moving through the catapults. 3. Random battle chaos scenes.
The first battle scene was done last night. Cara added the toon shaders and duplicated some of the guys and it looks fantastic. The catapult scenes took a lot more work, because in the refining process for the battles, we broke the crap out of our general flocking code. I seperated out the obstacle / flocking code from the battle code to avoid this problem in the future. Finally to build the chaotic battle scenes, we figured we would have one general battle scene and just pick pieces of it that we want to film for individual scenes. This large scene would also be featured in some of the catapult shots. In order to get a good random distribution I implemented a quick poisson distribution which makes setting up the scene much much easier. A render of the large battle can be found here.
March 2 top
Mostly minor changes at this point. The biggest change made in the past day was in the movement procedure. Instead of doing all of the rotations in world space, I used the calculated values to determine whether the rotation was to turn right or left in object space, and then did the rotation in object space. This greatly reduces the twitchy behavior I was seeing around some of the obstacles. Me and Chris worked some more on the combat system. Chris is currently working on adding walk cycles. Once those are in we'll have better renders.
February 27 top
Tim and Chris got our code to work with each other over the weekend. This introduced a few minor problems that we just didn't think of. The obstacle spheres that we draw around the fights have to go away once they're dead. The problem with this is that the death is determined by Chris's combat system. The only way we know if a guy is dead is by their "in battle" state. So I added a check for when a guy is dead, and then removed the obstacle in the case of block guys, and placed the obstacle on top of the rock guy when they died. For some reason, the rock guys don't stay dead. Me and Chris are going to get together tomorrow to try to sort it all out.
February 22 top
"Finished" work on the combat behaviors. Occasionally guys will do really wrong things, but at this point we can just fix those problems after the keyframing. I did a test of 160 guys and it took about 10 minutes to bake 3 seconds of animation, which is reasonable. When integrating with Cara's scenes I noticed that the guys moved too fast, but that was easily fixed now that all the variables are easily changed. I'm pretty much just waiting for Chris to finish the combat system so that we can plug it in.
February 21 top
When trying to implement the battle system we noticed that our behavioral model was going to need to include unaligned collision detection. Implementation took longer than expected, and it pushed back the flocking completion timetable. Here is a sample of the unaligned collision avoidance. However, implementing the unaligned collsion avoidance in conjunction with the obstacle avoidance proved to be much harder. The problem is that the current algorithm I used assigned eqaul weights to both the normal flocking behavior and the obstacle avoidance. This meant that if a dude was facing an obstacle he would be pushed straight through it because of the influence of his peers. This was corrected by giving obstacle avoidance more importance. For example, if the obstacle avoidance procedure tells a dude to stop, he will ignore the velocity influence of the flocking algorithm. Likewise, if a dude is radically steering away from an obstacle, he will give much less weight to the flocking influences. This may cause occasional collisions around obstacles, but they will be at slow enough speeds that the seperation force will be more than enough to push the dudes away. Here is an example of the unaligned collsion avoidance behavior with the obstacle avoidance behavior in place. When in doubt, the units will slow down to a crawl, which is important behavior. When there is a lot of combat, the soldiers shouldn't madly dash about looking for a way around, but instead should wait their turn.
I've also been working on the combat aspects. The approach algorithm written before has been put into place with a relatively straightforward matching system. Each soldier looks for the nearest enemy around him that is not currently involved in the combat process. If he finds one, it is added to his attributes as his enemy, as well as he is set to a state that tells other enemies that he is already taken. One major problem we've had to solve is the fact that the unaligned collision avoidance algorithm works on the assumption that both parties in the collision will actively try to avoid each other. If one is involved in combat he will not be able to do this, so we're using the obstacle avoidance system to keep guys from walking through battles. The first naive approach to this was that when two soldiers arrived at each other a bounding sphere would be drawn around them. This instanteneous obstacle caused ridiculous behavior by the soldiers caught in them. Our current system draws a sphere of radius zero between the two approaching men, and then scale it up as they get closer. This allows soldier to get out of the way in advance, without the large obstacle appearing in the middle of the battlefield. quicktime
February 16 top
I've been working on how to improve the speed of simulation. It was taking upwards of 10 minutes to simulate 4 seconds of actual animation. What I've done is simulate using loRes models (it doesn't get much more loRes than a cone) and then applying the key frames to the fully animated characters. Me and Tim are going to meet at 7 to try to combine our code into a full behavioral control structure.
February 15 top
Found the reason why the soldiers were turning and running in the opposite direction. It came down to two reasons.
- When guys got too close to the obstacles the point they would oreint towards to avoid the obstacle would be drawn behind them, making them turn around.
To fix this, the distance from sphere the "point at" location was changed to be in proportion to the absolute distance between the object and the obstacle. This way it will not veer dramatically off course.
- The position the units appear on screen isn't exactly where the unit exists in space. For some reason the IK root is translated 2.6 units in the X direction. Until I hear from Cara I just subtract this value off from the position in my calculations.
I was also able to finally get the rendering working. I was having problems where my scripts would work, I could see them when I playblasted them, but when I tried to render the units would just walk in place. Cara suggested that I try "baking in" the key frames. Now I just have to run the simulation, bake the key frames, and then render the scene using only the key frames. This is easily accomplished using edit->keyes->bake simulation. Using this, I came up with my first render.
February 9 top
Began playing with using the soldier models as opposed to simple cones. This presented challenges because the cones are much smaller and move slower than the soldiers. Here are some playblast renders. overheadview camera perspective walking60
the updated mel scripts are here.
There are still significant issues. Occasionally the soldiers will turn around and end up traveling the complete opposite direction. Plus there are overlaps, and its very slow. At least the basic functionality is down.
February 8 top
Implemented a simple approach system so that when two opposing units are near each other they will converge and slow down, so as to begin fighting. Flash movie At first the two units would try to reach the point where the other unit currently is. This did not work at all, because they would get very close, but end up skimming by each other. I fixed this by predicting where the opponent will be in the next frame, based on their speed and current direction.
February 7 top
Added collision avoidance behavior to the flocking model. A blayblast clip is available here. Mel Script. There are a few issues with the implementation. First of all, occasionally the cones will approach the sphere tangentially and then abruptly turn away. I hope this can be fixed by increasing the distance objects aim away from obstacles. Another problem is that flocks will split in order to avoid the sphere, but they do not join up again on the other side. This could be fixed by adding a desired direction that they want to maintain. Such as the direction that the battle is. The basic approach to the collision avoidance behavior is shooting rays from the objects and seeing if they intersect the spheres. The ray is bound to a distance of 8 units in front of the object. Actually, I got better results by shooting two rays, one on either side of the object (at a distance of one unit). This solved a problem where if the cone was aimed at a point just past the surface of the sphere, it would partially collide with it. The next step will be fixing up the behaviors to handle our actual troops.
February 4 (technically) top
Couple of additions to the flocking model. Now the cones keep space between them using seperation as opposed to collision avoidance. Also the lead cones are no longer affected by the cones around them. This led to a problem where the lead cones would want to turn back and face the cones that were following them. A sample render is here. The mel script is here.
February 3 top
Added group centering to the flocking behvavior. This clip shows the cones all running in the same direction after a few seconds. There is still no collision aviodance in the implementation, but I'm pretty happy with the limited behavior shown.
Tim designed a class hierarchy to handle the mass groups of soldiers into armies and battalions. This is a good solution to the problem that we faced with flocking behavior not being a good simulation of soldiers. The module is here.
January 26 top
I made a test render of the camera work for the scene where the two armies clash.
Januray 23 top
Me and Tim talked and we decided to prototype just in Visual Basic to get a look at what certain algorithms can do. It will be easier to find an algorithmn that works and then transfer it to MEL than to work entirely in MEL, which we don't know very well.
An idea to find soldiers in the same area as the current soldier is to use a binary space partitioning system, which I think is a great idea.
The group will meet again friday to finalize our presentation, and present our ideas for the algorithms we'd like to use. I will also try to set up a shot in maya of the beginning of the battle.
January 16 top
Flocking Work
paper on boids
Some of the fundamentals of flocking behavior are layed out in this article. Here are the key points that related to the project.
Conditions for flocking behavior:
1. Collision Avoidance
2. Velocity Matching
3. Flock Centering
The important part of the article is that all of these should be handled locally. IE each individual soldier should only make descisions based on the soldiers immediately surrounding him. Each of these can be given a weight and the velocity for the next step will be calculated through some averaging function of these elements. Additional parameters that can be added to this specific project include:
1. Hierarchical system of Lietenants and Sergants to break the soldiers into smaller, more managable groups
2. Attack nearby enemy soldiers
3. Some general direction the soldiers will want to head in, so that they "flock" to the battle.
Collision avoidance will be handled seperately, but in order for the troops to move realistically they should be aware of objects in their paths. This way they can adjust their course before encountering obstacles.