Not sure what you mean with "angular momentum".
You'd have to experiment in current Darwinbots, and then play around in the new version I have. Basically, current Darwinbots doesn't behave realistically with ties. The bots just sort of wiggle alot. You just
can't get them to rotate about their center of gravity.
The only things I calculate are tie (spring) forces: ie: -kx - bv, voluntary forces (like when the bots move), gravity, drag, friction, collisions, etc. All incredibly simple equations. (-kx - bv is by far the most complex) But it seems that some complex laws, like the conservation of angular momentum, arise naturally from these simpler rules, which is a good sign that I have a
very good physics engine (albeit simple since it's only dealing with spheres).
The great thing about using forces and vectors is that it's N-dimensional. Vectors work just as well in 3D as in 2D. I can show you the code if you like, it took a while to really get it all working, but it's just
so simple.
Switching to assembly is not an option, because all calculations are done using real numbers.
You don't have to switch everything to assembly, but C language derivatives allow in-line assemby, which means you can really optimize the oft-called functions (sqr especially) in assembly for speed quite easily (well, assuming you know assembly).
Slowdown seems to come mostly from the collision detection
And that's where a quad tree is going to save you cycles and cycles, which leads us to...
You have talked about a quadtree... what is that? Do you only divide the flat space into small squares, and sort every cell into one square? Or is it some more complex dynamic thing (I once thought about dividing the room dynamically, with the grid density proportional to the cell density, to make large space simulations possible).
A quad tree is basically taking the entire simulation universe and dividing it into grids, and then operating from those grids. For collision detection, you only need to check spheres that are in the same or adjacent grids, since grids further than that can't collide with each other.
An oct tree is the 3D equivelant. A Kd-tree divides the space more reasonably based on distributions of objects (that is, highly clumped areas get more grids than empty areas).
Search for quad tree, oct tree, and kd trees on google or wikipedia or gamedev.net. You should be able to find what I'm talking about.
The question is how to calculate the substances dispersion in such a world? The system needs to be aware of the fact that substances cannot disperse through cells. Brute force approach would be to model substances as little particles moving around randomly, and colliding with cells. It would be a *lot* of particles, perhaps 100·cellcount. Collision detection for them is just impossible. :(
Yes, this is more or less where I'm stuck too. Here's my thoughts on the idea:
The world is defined in a grid, and you just store the concentrations of substances in each grid. The smaller each grid, the more exact you simulation will be, but also the slower.
Every N cycles (every cycle is very slow, but you may need to do it that way) you calculate diffusion.
Now this is where it gets tricky, since you want to move substances inside multicells with them, and substances outside around them. So the answer is to have a seperate grid for enclosed spaces (how you find at run time what an enclosed space is I have no idea). Enclosed spaces can then be moved around by the critters. Something like this:
each number represents a concentration in that grid square, with (number) being the enclosed space:
(0) 5 6 8 4 4 5
enclosed space moves:
(0) 6 8 4 4 5
and again (note that the grid it was over is unchanged)
5 (0) 8 4 4 5
You can then program some interfaces between the enclosed space and the grid it's on if you want to simulate leakage or something along those lines. The trick is just to keep enclosed spaces and the rest of the game universe seperated logically. Then most everything else falls into place.
