Jump to content

  • Log In with Google      Sign In   
  • Create Account

FREE SOFTWARE GIVEAWAY

We have 4 x Pro Licences (valued at $59 each) for 2d modular animation software Spriter to give away in this Thursday's GDNet Direct email newsletter.


Read more in this forum topic or make sure you're signed up (from the right-hand sidebar on the homepage) and read Thursday's newsletter to get in the running!






And a video

Posted by NickUdell, in Pigment, Quick Bits, Media 08 May 2012 · 585 views

pigment video orbit physics gravity
This is a quick video I made of the spheres moving about and gravitating with each other.

I think in my next journal article (not tonight I'm afraid, I'm bogged down with tons of real-life work) I'll go into how I'm calculating them all. For the impatient I'm essentially using Barnes-Hut with my own implementation of an Octree. Each item performs pairwise gravity calculations which each other item in the octree node (each node has a capacity of items, I've set it to 3 currently) and then performs pairwise gravity calculations with the surrounding nodes themselves. The nodes accumulate the total mass of their children, so as to be a rough estimate for the amalgamation of gravitational forces in that region. This means that, roughly speaking, each item gravitates with every other item.

And lo and behold, the video:

http://www.youtube.com/watch?v=iq-xkibv_s0&feature=youtu.be

Bear in mind, I've artificially forced the spheres to be much closer together than they would be in real life (space, if you might know if you recall your Adams, is big. Really big), this is so that their motion is noticeable.

I'll talk about some of the issues present in the video (such as motion stuttering, a couple of LOD meshes with inverted normals and a bit of flickering here and there) in the next journal entry too, rest assured - I am aware of them.




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.
"

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



Yea I had that happening as well, I tried various hacks to fix it like bouncing colliding objects off each other,

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.


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

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!

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.
PARTNERS