# Warped Space

31 replies to this topic

### #1 KC LC

KC LC

• Retired Staff
• 5309 posts

Posted 13 April 2009 - 10:48 PM

OK, everyone has seen orbital simulations. But have you ever seen a simulation of an orbiting body rolling around a curved surface? I've had this for a while thinking I'd make a game with it. I won't do that, but it's pretty cool so I figured I'd post it here.

Surface Calculation
- The 3D surface is an inverse R-squared function - i.e., the form of the gravitational field around a massive body.

- The surface is created with a triangle mesh, using either a rectangular grid or a radial pattern. You can switch between rectangular and radial grids using buttons in the upper right.

Orbital Calculation
- The "rolling ball" follows an orbital trajectory calculated using the inverse R-squared force. The orbit is not pre-calculated. The position is updated in real-time by integrating the equations-of-motion.

- The orbital path is shown in traditional top-down view in the orthographic window.

Easter Egg
- Of course. And it's VERY cool.

Space Warp 1.2 MB zip file containing a GM 7 executable.
• 0

### #2 PickleMan

PickleMan

Programmer

• New Member
• 995 posts
• Version:Unknown

Posted 13 April 2009 - 10:51 PM

Woah...Cool.

I love the Easter Egg. I made something like it before...

Edited by PickleMan, 13 April 2009 - 10:52 PM.

• 0

### #3 Yourself

Yourself

The Ultimate Pronoun

• Retired Staff
• 7341 posts
• Version:Unknown

Posted 13 April 2009 - 11:29 PM

The "rolling ball" follows an orbital trajectory calculated using the inverse R-squared force.

The orbit view says otherwise (looks to be almost inverse distance, but not really, something's not right). I know an inverse square force when I see it and that isn't it.
• 0

### #4 jarcon

jarcon

GMC Member

• GMC Member
• 976 posts

Posted 13 April 2009 - 11:43 PM

Woah... that's cool.
• 0

### #5 Yourself

Yourself

The Ultimate Pronoun

• Retired Staff
• 7341 posts
• Version:Unknown

Posted 13 April 2009 - 11:50 PM

Actually, if you want a ball rolling around on a surface subject to uniform gravity (and constrained to the surface; so like a magnetic ball) to mimic the motion of an object in orbit subject to a force F = A/r2, the surface should have the shape z® = sinh(A/r).
• 0

### #6 Overman

Overman

GMC Member

• Banned Users
• 884 posts

Posted 13 April 2009 - 11:56 PM

*Brain explodes*

Yo this is seriously cool, don't hesitate to make it into a game!

If you could add some interesting gameplay element this could be really huge, with graphics reminiscent of Torus Trooper.

### #7 KC LC

KC LC

• Retired Staff
• 5309 posts

Posted 14 April 2009 - 12:02 AM

The orbit view says otherwise (looks to be almost inverse distance, but not really, something's not right). I know an inverse square force when I see it and that isn't it.

No, it's inverse square. I haven't looked at 1/r forces, but I've investigated Yukawa potentials and harmonic forces. And some 1/r^3 too. Surprisingly, that's the only one that's obviously different. The other potentials can look pretty much the same -- depending on choice of time scale, distance scale, and relative masses.

Actually, if you want a ball rolling around on a surface subject to uniform gravity (and constrained to the surface; so like a magnetic ball) to mimic the motion of an object in orbit subject to a force F = A/r2, the surface should have the shape z® = sinh(A/r).

But that trajectory would be constrained by gravity AND a resisting surface. In this simulation, the only force is gravity. So the surface isn't a constraint. The orbiting body's z-value is just given by surface value. That's the only role the surface plays.
• 0

### #8 Yourself

Yourself

The Ultimate Pronoun

• Retired Staff
• 7341 posts
• Version:Unknown

Posted 14 April 2009 - 12:16 AM

No, it's inverse square.

Then what's with the insane precession? Even for moderately large time steps in the integration you don't get that kind of precession (and if you bring up the fact that real orbits do process I'm going to have to tell you that that's because Newtonian gravity is wrong and it isn't really an inverse-square law; with Newtonian gravity there is no precession at all). There also appears to be two perigees and two apogees for each full orbit, which is not a characteristic of inverse-square orbits. I can guarantee that what I'm looking at is not inverse square.

And some 1/r^3 too. Surprisingly, that's the only one that's obviously different.

Maybe to the untrained eye (seeing as r^3 forms spiral trajectories).

But that trajectory would be constrained by gravity AND a resisting surface.

What's interesting about the surface I gave is that if you looked at it from the top-down (i.e. ignored vertical displacements), the trajectories would follow an inverse-square force law. I designed the surface shape so that it would come out to be exactly the same (I think, what the surface does is translate the typical uniform downward gravity into an inverse square force acting on the ball by virtue of the slope that it's sitting on).
• 0

### #9 PickleMan

PickleMan

Programmer

• New Member
• 995 posts
• Version:Unknown

Posted 14 April 2009 - 12:19 AM

Ohh, how did you get the easter egg to work...
• 0

### #10 ninjutsu63

ninjutsu63

GMC Member

• New Member
• 1128 posts

Posted 14 April 2009 - 12:24 AM

Great job again. The easter egg would make a great screensaver
• 0

### #11 KC LC

KC LC

• Retired Staff
• 5309 posts

Posted 14 April 2009 - 12:30 AM

Then what's with the insane precession?

That's because I chose initial conditions quite different from the normal v = sqrt(G*m/R). It was too boring to see the ball rolling in a circle. So I gave the orbiting body a little "thump" before I turned it loose under the 1/r^2 force.

Maybe to the untrained eye (seeing as r^3 forms spiral trajectories).

That's exactly what I meant when I said it was "obviously different". But those are neat too, because the central force won't always capture the orbiting body. The satellite may pop back out and keep orbiting. They're fun to play with, but it's hard to find the right combination of parameters to make the orbit last for very long.

What's interesting about the surface I gave is that if you looked at it from the top-down (i.e. ignored vertical displacements), the trajectories would follow an inverse-square force law.

That's not obvious to me. I'll have a look.
• 0

### #12 Yourself

Yourself

The Ultimate Pronoun

• Retired Staff
• 7341 posts
• Version:Unknown

Posted 14 April 2009 - 12:39 AM

That's because I chose initial conditions quite different from the normal v = sqrt(G*m/R).

It doesn't matter what initial conditions you choose, inverse square orbits do not precess. They form closed trajectories and you always come back to where you started (provided you're not on an escape trajectory).
• 0

### #13 KC LC

KC LC

• Retired Staff
• 5309 posts

Posted 14 April 2009 - 12:56 AM

It doesn't matter what initial conditions you choose, inverse square orbits do not precess.

That's true. But the perihelion WILL precess if there's any disturbance on top of the central inverse-square force -- like with Mercury's orbit for example. Any tiny disturbance will cause precession.

In my calculation, those "disturbances" aren't the other planets (like with Mercury) but numerical error and large time steps. That wouldn't happen if I calculated the orbits instead of letting the force dictate the motion in real time.

But that would be boring.
• 0

### #14 Hach-Que

Hach-Que

• New Member
• 1490 posts

Posted 14 April 2009 - 01:11 AM

Nice easter egg. It'd be better if it was random and continued though
• 0

### #15 Yourself

Yourself

The Ultimate Pronoun

• Retired Staff
• 7341 posts
• Version:Unknown

Posted 14 April 2009 - 01:12 AM

That's true. But the perihelion WILL precess if there's any disturbance on top of the central inverse-square force -- like with Mercury's orbit for example.

and if you bring up the fact that real orbits do process I'm going to have to tell you that that's because Newtonian gravity is wrong and it isn't really an inverse-square law; with Newtonian gravity there is no precession at all

Mercury's precession does not happen because of gravitational perturbations. Mercury is a special case because it's so close to the sun and its orbit is sufficiently eccentric to notice the effect that general relativity has on space itself.

In my calculation, those "disturbances" aren't the other planets (like with Mercury) but numerical error and large time steps.

But that's not what I'm seeing. Large time steps would actually throw the orbiting planet out of the system before any considerable precession had occurred. The affect on the apogee of the orbit from large time steps absolutely dwarfs the effect that it has on precession. Your body isn't flying out of its system. Its apogee distance isn't changing considerably (which would be the tell-tale sign of a large time step for any kind of radial force) so I'm forced to conclude that the time step is sufficiently small and that is not the result of the precession.

But it just looks like you're gonna make me do this the hard way.

http://www.ultimatep...avity_right.gmk

To crank up the size of the time step change the value of n in the Orbiter object's create event (make it smaller to make time steps larger).
• 0

### #16 KC LC

KC LC

• Retired Staff
• 5309 posts

Posted 14 April 2009 - 01:50 AM

Mercury's precession does not happen because of gravitational perturbations. Mercury is a special case because it's so close to the sun and its orbit is sufficiently eccentric to notice the effect that general relativity has on space itself.

That's not correct. Relativistic effects make only a small contribution to Mercury's precession. It's about 5600 arcsec/century. The other planets produce a precession of about 5560 arcsec/ century, and relativistic effects add another 40 arcsec/century. So they account for the "missing" precession, but they only produce a tiny amount. Gravitational perturbations from the other planets are the main effect.
• 0

### #17 Yourself

Yourself

The Ultimate Pronoun

• Retired Staff
• 7341 posts
• Version:Unknown

Posted 14 April 2009 - 04:42 AM

Mercury's precession does not happen because of gravitational perturbations. Mercury is a special case because it's so close to the sun and its orbit is sufficiently eccentric to notice the effect that general relativity has on space itself.

That's not correct. Relativistic effects make only a small contribution to Mercury's precession. It's about 5600 arcsec/century. The other planets produce a precession of about 5560 arcsec/ century, and relativistic effects add another 40 arcsec/century. So they account for the "missing" precession, but they only produce a tiny amount. Gravitational perturbations from the other planets are the main effect.

Yes, you're right, it's not the dominant reason (but it is noticeable for Mercury). However, my other points still stand, your simulation is not inverse-square.
• 0

### #18 KC LC

KC LC

• Retired Staff
• 5309 posts

Posted 14 April 2009 - 10:16 AM

Ohh, how did you get the easter egg to work...

Simple. It's just the camera's point-of-view moving through a 3D tube. The tube follows a 3D Lissajous curve:

x = f(s)
y = g(s)
z = h(s)

...where f,g, and h are periodic (sinusoidal) functions. Then I wrap a circle around each (x,y,z) point so its plane is perpendicular to the curve's slope at that point. Finally, I connect all the circles with a triangle mesh. I also superimpose a black line mesh to make it easier to see the motion as the camera flies through.

Nice easter egg. It'd be better if it was random and continued though

It started out that way, but I wanted the user to return to the main display, so I made it a one-pass trip. The z-curve above has a small offset added to its period so the ends of the curve aren't connected. That lets the camera fly out and back to the first display.

For a screensaver, I'd make it continuous -- and/or maybe use a more complex curve like you suggested.

However, my other points still stand, your simulation is not inverse-square.

No, I'm definitely computing the force (acceleration) from mass-product * const. * 1/(r*r). Then that's integrated to update the velocity, and the velocity is integrated to update the positions.

And that exact same force/velocity/position calculation produces circular orbits if I start the orbit with a velocity of sqrt(G*m/r). So there's something else going on.
• 0

### #19 Yourself

Yourself

The Ultimate Pronoun

• Retired Staff
• 7341 posts
• Version:Unknown

Posted 14 April 2009 - 10:24 AM

No, I'm definitely computing the force (acceleration) from mass-product * const. * 1/(r*r). Then that's integrated to update the velocity, and the velocity is integrated to update the positions.

And how do you get the direction of the force? I assume you mistakenly multiplied this magnitude by the negative position vector without normalization (which would turn the inverse-square into inverse-linear since one of the r's will "cancel" the r that's hidden in the position).

Regardless, something is most definitely wrong here.

And that exact same force/velocity/position calculation produces circular orbits if I start the orbit with a velocity of sqrt(G*m/r)

For any r?
• 0

### #20 KC LC

KC LC

• Retired Staff
• 5309 posts

Posted 14 April 2009 - 10:50 AM

I assume you mistakenly multiplied this magnitude by the negative position vector without normalization

That's probably it. I'll check my code. I use the lengthdir functions to compute the sine and cos(theta) terms needed for the x and y components. And I'm probably not removing the R that comes with it.

If that's the cause, I may change the surface to a 1/r shape instead of fixing the force. Because the circular orbits aren't very interesting to watch.

Or I may just leave it as a relic. The Easter eggs always give me ideas for new projects. I'm working out a cool way to make 3D knots in GM -- plus I'm improving my jellyfish simulation from the last Easter Egg.
• 0

#### 0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users