nice, ive done something like this before but I didn't think of the critical step of subdividing the world like you've done, so I had every "star" gravity testing against all others with predictable performance results...oh and I was doing it in 2D - amazing how an extra dimension cuts down on all the pesky collisions.

Yeah the collisions are still happening in this (well, what's currently happening is the bodies are entering each other and then, when their centres are essentially 0 from each other the gravity pulls them at a ridiculous speed so they fling off in mad directions). I have collision testing on all objects already written, but there's a bug or two still in the way I deal with the collisions currently.

The joy of this is that it actually scales really well. Because of the incredibly slow motion in general I can get away with running this update maybe once every 30 seconds or so. If I've given it its own thread, then that gives me up to 30 seconds to process all of the objects. Combine that with the octree implementation and I could theoretically have millions of stars in here (and I hope to, once I've sorted out LODing and efficient octree-based frustum culling)

EDIT: The other thing to bear in mind is that every now and then you'll have to rebuild the entire octree from scratch. This is because as each item in the tree moves, the culling / calculations become less and less accurate (essentially the chance of an item moving into the space "owned" by another octree node increases the more they move). But if you only have to update their positions / gravity every 30 seconds you probably won't need to update the tree anything less than every half hour or so. And updating the tree is actually a really quick operation, amazingly. I've added 100,000 items to the tree and it's taken less than a second on my hardware (I've never gotten around to actually timing it because it's been so fast so far, and from the start I've separated the universe updates from the rendering loop). When it comes to optimizing later, I'll look into it a bit more, but right now it's really not crucial.

"
[left]when their centres are essentially 0 from each other the gravity pulls them at a ridiculous speed so they fling off in mad directions"[/left]


[left]Yea I had that happening as well, I tried various hacks to fix it like bouncing colliding objects off each other,[/left]
[left]capping max velocity and even adding a short-distance repulsion force, but none of it looked right. Finally I settled on a clumping behaviour where two colliding masses combined into a single larger mass, with momentum conserved.[/left]

I guess the question is what would happen if a moon sized object slammed into a planet in real life? I guess a lot of it would "stick" together but there would be a lot of debris flying off in various directions.

The problem I had was my low limit for particles I couldn't support lots of minor debris.

In the "universe" I made I found [left]everything eventually either collapsed in on itself or expanded away to infinity. A bit like the universe I guess, except I never saw any cool structures like orbiting planets/stars/moon heirarchies emerge, let alone galaxies. I assumed that was because I was doing it in 2D, plus I didn't have enough particles. Either that or I disproved modern cosmology![/left]

Your problem with no galaxies or stable orbits forming might have been due to a lack of rotation? I'm not sure my engine will be able to handle adding in some of the more complicated physics associated with rotations and the like. Another reason could be because newtonian gravitation doesn't really work well in the long term, which is why the use of spacetime curves to simulate gravity are considered the gold standard. Unfortunately, spacetime is a little harder to simulate when you have to deliver it at a constant time.

I haven't gotten around to particle effects yet. I have a place for them in the framework and will eventually use them, but currently they're an unwritten placeholder.