Physics gravity conundrum

Instead of using xy measurements based on distance, the force applied is equal to the DISTANCE FORMULA of the objects, so if they are far away they will to to move back together more quickly... this is the opposite of what would happen in a real world experiment, but for applied mechanics in a game situation, it seems to work quite well.

I will keep playing with it before I upload... the way your example works is probably way better than mine, so I may work with your example and include the merging and seperation of objects based on a player shooting at them.

~Sol

The force applied is derived from 640 - distance, so if an object is 500 pixels away, the force would be 140, and if an object was 20 pixels away, it would be 620. So it is set up to where the force is correct, just only for certain distances, because if it's over 640 pixels away it's repelled.

could just set it to where if the result is less than 0, set to 0.

but the odd behavior i noticed in link's, is how putting a heavy mass and light mass next to eachother will result in them moving out of the screen instead of the green simply coming to rest next to the gray.

also, orbiting objects almost always manage to slingshot farther away, rather than coming closer and closer.

but the odd behavior i noticed in link's, is how putting a heavy mass and light mass next to eachother will result in them moving out of the screen instead of the green simply coming to rest next to the gray.

also, orbiting objects almost always manage to slingshot farther away, rather than coming closer and closer.

Yeah, it doesn't seem to be very stable. Still, getting pretty close though as each object actually does have it's own pull.

> but the odd behavior i noticed in link's, is how putting a heavy mass and light mass next to eachother will result in them moving out of the screen instead of the green simply coming to rest next to the gray.

>

> also, orbiting objects almost always manage to slingshot farther away, rather than coming closer and closer.

>

Yeah, it doesn't seem to be very stable. Still, getting pretty close though as each object actually does have it's own pull.

I didn't notice that before, but there doesn't seem to be a way I can fix it. Since the pull of an object is multiplied by it's mass, lighter objects will be pulled in faster than heavier objects and end up pushing the pulling object.

are we supposed to report instances where i can replicate a crash in our game? while attempting the gravity conundrum, i did something that always crashes instantly with the error "out of memory" when triggered in the .exe.

I didn't notice that before, but there doesn't seem to be a way I can fix it. Since the pull of an object is multiplied by it's mass, lighter objects will be pulled in faster than heavier objects and end up pushing the pulling object.

Yeah a few quirks I found about your example compared to mine:

-Objects move towards each other correctly, where mine is nowhere near the "right way".

-In your example, when a lighter mass object hits the heavier mass object, it seems to act as an outboard motor on a boat, and push the heavier object along. With mine, the lighter objects will bump the heavier object and cause it to shift slightly but then it will stabilize.

-Also in your example, objects of the same mass will attract PERFECTLY to each other, and behave exactly like deadeye was requesting... however if left in a massive bundle they start to spin around faster and faster until they "fling" themselves off and it becomes a big mess.

You are DEFINITELY on the right track... we just need to suss out where it is going wrong. I think a combination of your ideas and my ideas may get it working correctly.

There needs to be a correlation between distance (using the distance formula), mass (which is calculated in your example), and friction (which I think your example doesn't seem to be using?).

Having not really thought about this too well---

Perhaps a solution for force applied towards an object could be something along the lines of;

+For each instance

: sqrt((ObjectA.X-ObjectB.X)^2+(ObjectA.Y-ObjectB.Y)^2)-(ObjectA.Mass-ObjectB.Mass)

Therefore, objects with a higher mass than another, will not move towards the smaller object, rather it will attract the smaller massed objects. This will also mean that if a smaller object is too far away from another larger one, it will not be influenced by the mass as it would if the larger object were of higher mass.

I don't think I made a lot of sense there lol... I dunno... I know what I'm trying to say, perhaps I should try to make something with it instead of confusing everyone! <3

~Sol

http://upload.dfyb.net/uploaded/gravity_edit2.cap

here's a modified version of link's. it consolodates the differences in distance into a single action (i also enlarged the window).

Hmm, I just realized that Set force is a very innaccurate way of doing this simulation... Add force yields much better results. For instance, under Set force, a large body of objects will move towards a single object at the same rate that the single object moves towards the large body.

In reality, the large body has more cumulative pull, so they would be drawing the single object faster than the single object would be drawing in the large body. In other words, the single object would be moving much more.

This can be corrected by changing Set force to Add force.

I've also stabilized the simulation somewhat by setting Linear and Angular dampening to 50% and elasticity to 0%. It's till possible to go into a "death spiral" but it's much less likely and takes lots more objects to do it.

But the major problem is that when there are a lot of objects in the center of the screen, and you place one at the edge, the Add force makes it move way too fast towards the group.

I've also removed the 100ms timer, the nested loop actually doesn't cause as much of a performance lag as I thought it would.

Anyway, here's my tinkering with it: http://www.fileshack.us/get_file.php?id ... y+mess.cap

In reality, the large body has more cumulative pull, so they would be drawing the single object faster than the single object would be drawing in the large body. In other words, the single object would be moving much more.

This can be corrected by changing Set force to Add force.

This is pretty much what I was trying to get at... I will check out what you have managed to do once I get on my Construct PC. I hate this slow junk computer I have here at work... I really should upgrade this heap of crap.

I understand the laws and methods of physics better than I understand the maths behind it.

~Sol

Welp, I found a post where the creator of the original game explained how he made the asteroids...

[quote:38lkelbu]Each asteroid affects each other, which is an O(n^2). This should be really slow for 1000 asteroids. Should be 1,000,000 gravity calculations. So... I use a coarse grid and calculate the mass contained in each grid segment. Gravity is calculated accurately for near by asteroids and the grid is used for distant asteroids.

I don't know what that means

Welp, I found a post where the creator of the original game explained how he made the asteroids...

[quote:3nuys7g6]Each asteroid affects each other, which is an O(n^2). This should be really slow for 1000 asteroids. Should be 1,000,000 gravity calculations. So... I use a coarse grid and calculate the mass contained in each grid segment. Gravity is calculated accurately for near by asteroids and the grid is used for distant asteroids.

I don't know what that means

I am not sure myself, but I'll try to explain anyway ... First it initializes an array, a grid which has wide segments, like 1000 pixels or something like that. Then it calculates the amount of the mass in each segment... it kind of "rounds" the "gravitational map", or "scales down the resolution", if you get it that way. Then it starts to loop through each asteroid and calculating the forces affecting them. If there were... let's say about 10 asteroids on each segment, it calculates the forces of asteroids on its own segment and the neighbour segments, the forces of, say, 90 asteroids. Then it calculates the more distant ones, but it doesn't calculate asteroids, it calculates the combined gravitational forces of segments. If there is 1000 asteroids, like in your quote, and there is 10 asteroids per segment, then there would be totally 100 segments, so, there would be a 10 x 10 segment grid. So, the forces affecting a single asteroid would be forces of 89 asteroids and 100 - 9 (9 is the amount of neighbour segments whose forces are calculated accurately) = 91 segments, so there would be only 180 forces to calculate per asteroid, instead of 999. So, it's over five times faster.

And I think it can be optimised further. For example, the forces of the distant segments are the same for every asteroid in a segment, so these forces need to be calculated only once per ten asteroids, assuming we have that ten asteroids in a segment... so, averagely 89 + 9.1 = 98.1 force calculations per an asteroid. That's already TEN times faster !

Of course, updating the mass grid takes some calculating, but it's not necessary to do every tick, since the positions of the asteroids don't change that fast.

I think this wouldn't be too hard to implement with Construct... But of course, cannot say surely yet. I would try to make this myself unless I had so little time :I

This is SO complicated. But... isn't this method going to affects accuracy very badly? Main problem is to keep gravitational map with good resolution.

I'm looking forward to seeing implementation.

LOL this topic is just killing everyone's brain. GG deadeye... GG

~Sol

This is SO complicated. But... isn't this method going to affects accuracy very badly? Main problem is to keep gravitational map with good resolution.

I'm looking forward to seeing implementation.

Well if I understand it correctly then it's only slightly inaccurate over large distances, like faraway things just move in the general direction they're supposed to, but it gets more accurate up close where it counts.

But yeah I think a 1000px wide grid size is probably way too big to be accurate enough, could probably get away with 100px pretty easily. Hell a 100x grid could conceivably hold nine of those 32x sprites in each cell anyway, having any coarser resolution would be kinda overdoing it for a small demo.

LOL this topic is just killing everyone's brain.

Yeah, that's the fun of it It's a puzzle, man.

Yeah, that's the fun of it It's a puzzle, man.

I know mate

Just pickin' on ya.

Hopefully we can work this out as a group, even if none of us ever use it for anything... it helps keep the "juices" flowing.

~Sol