Physics gravity conundrum

For questions about using Classic.

Post » Sun Sep 21, 2008 2:38 am

[quote="linkman2004":2x4awo21]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. :?[/quote:2x4awo21]

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;
[color=#FF0000:2x4awo21]+For each instance[/color:2x4awo21]
[color=#4000FF:2x4awo21] : sqrt((ObjectA.X-ObjectB.X)^2+(ObjectA.Y-ObjectB.Y)^2)-(ObjectA.Mass-ObjectB.Mass)[/color:2x4awo21]

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
Tired of crappy file hosts that are crappy? Get DROPBOX - https://db.tt/uwjysXJF
Moderator
B
45
S
17
G
37
Posts: 2,853
Reputation: 25,966

Post » Sun Sep 21, 2008 10:55 am

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).
B
2
S
2
G
4
Posts: 254
Reputation: 1,958

Post » Sun Sep 21, 2008 5:38 pm

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
Moderator
B
5
S
2
G
6
Posts: 4,348
Reputation: 10,971

Post » Sun Sep 21, 2008 11:45 pm

[quote="deadeye":1efzemoy]
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.[/quote:1efzemoy]

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
Tired of crappy file hosts that are crappy? Get DROPBOX - https://db.tt/uwjysXJF
Moderator
B
45
S
17
G
37
Posts: 2,853
Reputation: 25,966

Post » Mon Sep 22, 2008 9:33 am

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.[/quote:38lkelbu]

I don't know what that means :(
Moderator
B
5
S
2
G
6
Posts: 4,348
Reputation: 10,971

Post » Mon Sep 22, 2008 10:31 am

[quote="deadeye":3nuys7g6]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.[/quote:3nuys7g6]

I don't know what that means :([/quote:3nuys7g6]

I am not sure myself, but I'll try to explain anyway :D... 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 :D!

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
B
3
S
2
G
5
Posts: 263
Reputation: 2,201

Post » Mon Sep 22, 2008 12:29 pm

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.
B
6
S
3
G
6
Posts: 219
Reputation: 3,013

Post » Mon Sep 22, 2008 12:52 pm

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

~Sol
Tired of crappy file hosts that are crappy? Get DROPBOX - https://db.tt/uwjysXJF
Moderator
B
45
S
17
G
37
Posts: 2,853
Reputation: 25,966

Post » Mon Sep 22, 2008 1:16 pm

[quote="BROO":2gmflvwy]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.[/quote:2gmflvwy]

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.

[quote="SoldjahBoy":2gmflvwy]LOL this topic is just killing everyone's brain.[/quote:2gmflvwy]

Yeah, that's the fun of it :) It's a puzzle, man.
Moderator
B
5
S
2
G
6
Posts: 4,348
Reputation: 10,971

Post » Mon Sep 22, 2008 1:57 pm

[quote="deadeye":s228z4sb]Yeah, that's the fun of it :) It's a puzzle, man.[/quote:s228z4sb]

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
Tired of crappy file hosts that are crappy? Get DROPBOX - https://db.tt/uwjysXJF
Moderator
B
45
S
17
G
37
Posts: 2,853
Reputation: 25,966

PreviousNext

Return to Help & Support using Construct Classic

Who is online

Users browsing this forum: No registered users and 1 guest