This is my own thing. I'd been thinking about it for almost a year before the ARLS project started. The system I'm working on now still conforms pretty well to that original algorithm I came up with. I did kind of hijack mr_rob's thread, though, and I've felt a little guilty about that for a couple of weeks now. Apologies, mr_rob! In addition to hating the bugs on blender.org, that's one of the other reasons I moved my thread to elYsiun.
On another note - I got quad tree searching working for the FollowTerrain section. My at-work tests show that it's 17x faster than the raw searching method (74 Actors, 5000 vert terrain. Raw: 38.7 secs.; Quadtree: 2.2 secs.). And that's hitting the database over a network on PIIIs. I'm guessing that on my home machine where it all runs on the same box (AMD XP1800) that the terrain searching will now be next to negligible. I'll try my 800 actor sim again tonight and see how it goes.
Heh. This is already done, but it doesn't quite function the way you're thinking.
Each Actor has a Command and Control level. Upon initialization, each Actor is chained to the nearest unit that is one level above it in the command structure (you can assign units manually as well, for finer control). Each Actor receives its orders from it's immediate commander in the chain. You can have multiple levels in the structure. Thus, you can issue an instruction to the entire army by giving the order to the single top-level commander (or commanders). You can also give orders to any Actor anywhere in the chain, which will propogate down the chain.
The problem with FollowTerrain is the it is not responsible (much) for the intelligent motions of the Actors. Its job is to keep all Actors planted on the Ground mesh object, so no one flies or sinks. You give it your Actor's x and y coordinates, and it returns the proper z value to place it on the Ground. Therefore, it needs to be evaluated for Actor individually, as they are each at a different location with respect to the Ground mesh, and at each frame, so you don't get people cruising through hilltops or gliding over valleys due to IPO Curve smoothing.
Thanks for the input, though - I'm glad other people are interest in this besides myself.
The camera was stuck to one of the red team Actors, on assault against a defending Blue team. BTW, I will not be posting future updates on blender.org. I'll put them right in this thread.
Everone else can bail here, but if you're interested in the progress report and to do list, read on...
1. Did a complete rewrite of the code. It is now significantly faster. It was calculating a full frame of motion for over 140 actors in less than one second on my Athlon XP1800 .5GB RAM machine.
2. Fixed a bug in the Python API source, allowing the generation of smooth IPO curves from Python. The calculated motion frames can now be used as keyframes, every 3, 6, 12 or whatever real frames. So it only took one second to calc the motions for 12 full frames. I might try a 1000 actor sim this weekend. We'll see how it scales.
3. Code rewrite made it easy to add new kinds of orders, so I added three new types: StrictMarch and StrictDefend, which are like their normal versions, but actors will ignore enemies unless directly attacked. Also added RegroupMain and RegroupCommander, which cause forces to regroup to a central location or their heirarchicial commander, respectively.
4. Rewrote the code for barrier avoidance. It still needs work, but it's much more efficient and intelligent now.
5. The big one: DIRECTIONAL AWARENESS. Actors are now directional creatures. Before, they evaluated everything on a global basis. Now, they make their decisions based on what they see in front of them, with user-definable fields of vision and turning speeds. In the video, you can see them "looking around" for enemies to attack. Actors also "hear" in a limited radius, so they are aware of crap that's going on behind them, just not so much as the stuff in front of their face. Came up with solutions to some nasty over-rotation problems, so if you've been working on a script and your rotations get out of control once they go over 360, pm me and I'll give you my solution.
TO DO LIST:
1. Testing on each of the Orders, to make sure they do what they're supposed to, and that Actors ignore them when they're supposed to. For documentation sake, I'll make a little video of each Order type in action.
2. DB creation code. All you will have to do is have mySQL installed and Blender will create the appropriate databases and tables for you, if they don't already exist.
3. Decide how to handle verticle orientation and include movement constraints for slopes on terrain.
Once that's done, then the whole package is 1/3 finished. Another 1/3 is the script set that will link NLA info with Action logs generated by THIS part of the script, creating the character animation to go along with the keyed motion. The other 1/3 of the project is GUI and documentation. Anyone who likes this and has done a GUI before, please contact me. I need your help.