31 replies to this topic

[KC LC]

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.

Here's the download:
Space Warp 1.2 MB zip file containing a GM 7 executable.

[PickleMan]

Woah...Cool.

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

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

[Yourself]

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.

[jarcon]

Woah... that's cool.

[Yourself]

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/r², the surface should have the shape z® = sinh(A/r).

[Overman]

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

[KC LC]

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.

[Yourself]

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

[PickleMan]

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

[ninjutsu63]

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

[KC LC]

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.

[Yourself]

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

[KC LC]

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.

[Hach-Que]

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

[Yourself]

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

[KC LC]

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.

[Yourself]

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.

[KC LC]

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.

[Yourself]

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?

[KC LC]

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.