Rocket/Space Game (Was "Rigid body rotations")

A spot for all things TestTube
A Random Player
Posts: 523
Joined: Mon Jun 03, 2013 4:54 pm

Re: Rigid body rotations

Post by A Random Player »

testtubegames wrote:
A Random Player wrote:Ok, major change of plans - switching to patched conics. At 65536x warp, the game is extremely laggy, with only 3 celestial bodies (and no ships), and the earth still moves slower than the second hand on a clock. Patched conics will make warp require significantly less calculations, but with more complicated ones. Paths will also be much faster, and won't require a numerical simulation everytime you want to view one. The main problem is converting from position/velocity vectors to Keplerian elements and back. The internet isn't very helpful, especially in 2 dimensions. I can find a and e (and thus p, Pe, and Ap), but not ω or M_0 (or ν) :( Any help?
Patched conics? Warp? I'm a bit confused - sounds like you're talking about your gravity simulator there... but obviously it's more than that. What's causing the lag? Does it have to do with a prediction line (which needs to cast everything in the world forward in time)?
Yep, still my gravity simulator. There are some problems I've realized.
I use a leapfrog-ish n-body sim, adding some things like bouncing off ground - implementation is ridiculously easy. However, this means that every timestep must be calculated. It's not very hard for a small bit of warp (loop the physics calculations), I've even temporarily bound my right-control, comma, and recently my period to do so (16x, 256x, and 65536x)*. However, past 16x or so, the simulation starts to get laggy: 4096 is ~5 FPS, 65536 is ~.5 FPS. While this doesn't seem bad (you don't need to warp that much in most games), the system I currently have set up has a lunar orbital period of 117800 s (~1.3 days), and an Earth orbital period of 7720000 s (~89.3 days). And lag is bad. And imagine more planets or ships - This is with 3 celestial bodies and a tiny 4 part ship.
So I've decided to try to copy a bit from KSP, and switch to a patched conics rather than n body (ironically, precisely the opposite of KSP right now). I'm pretty sure about what to do - just not how to do it. I'm trying to find out how to compute the Keplerian orbital elements from a position and velocity vector, and back. Keplerian elements don't change over time, so you can compute position and velocity without computing the intermediate steps. And (I'm pretty sure that) one needs to convert the elements to position and velocity in order to apply a thrust or a non-gravity change in velocity.

*That is, warp without changing the timestep, which reduces accuracy.

Bleh, forgot to reply to a part. If you see this, I'm still writing. Finished.
Trails, updating once per frame? Heh, right now that's the dream for a super computer. My current trail drawing requires the user to manually input the tracked object, numerical integration step, and amount of time for integration, then click a button. Or a button for clear all. Incredible hindsight not to have a list of trails, I instead keep a list of all points, and whether or not they're connected to the next point. It's not laggy unless I click (1000 integrator steps gives ~1 second delay in generation), or when I draw ~5000 points/lines.
This will all change when the fire nation attacks I switch to patched conics.
$1 = 100¢ = (10¢)^2 = ($0.10)^2 = $0.01 = 1¢ [1]
Always check your units or you will have no money!
User avatar
testtubegames
Site Admin
Posts: 1148
Joined: Mon Nov 19, 2012 7:54 pm

Re: Rigid body rotations

Post by testtubegames »

Ah, okay, gotcha.

I tried using conics, in fact, with the gravity simulator. The only time you get a significant error in the sim is when two objects are extremely close. So I figured, hey, why not just ignore everything else, and use conics. That way you're sure to conserve energy, and get a reasonable outcome.

I had the same tough time tracking down the answer to your specific question (current pos & vel into next po & vel). And I never did get it working perfectly, so eventually I threw my hands up and moved on. (But that was long ago, who knows, maybe it's worth going back to) Sounds like I made it about as far as you -- getting the eccentricity, and alpha, and all the rest of the figures. I hit the same wall. Looking back at the code, it seems I just started fudging it after that point ("well, I know the tangential velocity, so I can figure that theta will change roughly that quickly.....")

And no surprise, it didn't work out.

If you do find a good resource, let me know!

As a further note, a completely different approach would be to decrease the refresh rate of your simulator when you're warping. (I imagine you've thought of that, though) With 1.3 days for a complete lunar orbit, you certainly don't need 30 fps calculations to keep the moon from falling out of the sky.
A Random Player
Posts: 523
Joined: Mon Jun 03, 2013 4:54 pm

Re: Rigid body rotations

Post by A Random Player »

testtubegames wrote:Ah, okay, gotcha.

I tried using conics, in fact, with the gravity simulator. The only time you get a significant error in the sim is when two objects are extremely close. So I figured, hey, why not just ignore everything else, and use conics. That way you're sure to conserve energy, and get a reasonable outcome.
You mean extremely far, right? SOIs are inaccurate with multiple significant gravitation influences, and are even more accurate than n-body when things get really close (assuming point masses, of course).
I had the same tough time tracking down the answer to your specific question (current pos & vel into next po & vel). And I never did get it working perfectly, so eventually I threw my hands up and moved on. (But that was long ago, who knows, maybe it's worth going back to) Sounds like I made it about as far as you -- getting the eccentricity, and alpha, and all the rest of the figures. I hit the same wall. Looking back at the code, it seems I just started fudging it after that point ("well, I know the tangential velocity, so I can figure that theta will change roughly that quickly.....")
You got all the figures? That's probably just what I need! (I only have a and e) Could you share? :)
And no surprise, it didn't work out.

If you do find a good resource, let me know!

As a further note, a completely different approach would be to decrease the refresh rate of your simulator when you're warping. (I imagine you've thought of that, though) With 1.3 days for a complete lunar orbit, you certainly don't need 30 fps calculations to keep the moon from falling out of the sky.
Well, yeah, that's the lag that's caused. Apparently the timer that fires every frame just goes "I don't care what you say, I'm not done till I'm done". It's still good to be consistent with the simulation and not change the timestep.
(Physics-ish joke-ish: The moon wouldn't fall out of the sky, with a too high timestep it would either shoot tangentally in an escape, or fall right through the earth... which I guess it what you meant. But it would still fall back into the sky :P)
$1 = 100¢ = (10¢)^2 = ($0.10)^2 = $0.01 = 1¢ [1]
Always check your units or you will have no money!
User avatar
testtubegames
Site Admin
Posts: 1148
Joined: Mon Nov 19, 2012 7:54 pm

Re: Rigid body rotations

Post by testtubegames »

A Random Player wrote:You mean extremely far, right? SOIs are inaccurate with multiple significant gravitation influences, and are even more accurate than n-body when things get really close (assuming point masses, of course).
Yeah, I think that was a wee miscommunication. The simulator runs by iterating over all forces, then changing velocities and positions. So, yeah, in the n-body way. This means, when two objects get really close, huge errors can come into play. I was hoping to fix that by using conics when two objects got really close (so some version of SOI). But I was never able to get it working properly. It would have helped tremendously with the accuracy, though.
A Random Player wrote:You got all the figures? That's probably just what I need! (I only have a and e) Could you share? :)[\quote]
Okay, let me see (I'll write what I've got):

For a radial force:

f(r) = -k/r^2

The equation of the path, with r as a function of theta is:

r(theta) = apha/(1+epsilon*cos(theta))

where

alpha = (m*l^2)/k

and

epsilon = sqrt(1+2*m*Etot*(l/k)^2)

with l being the angular momentum per unit mass.

The perigee and apogee are at:

r0 = alpha/(1+epsilon)
r1 = alpha/(1-epsilon)

That's what I grabbed from my old physics book, at least. I was never able to get this method to work well enough for me (it was, I'll say a while back, so I forget exactly what the problem was). So best of luck there.

As for the changing timesteps - I wouldn't be too stringent about that, myself. (The irony being that I *am* stringent about it in my simulator... hrm... but you're doing something different of course). When it comes to these slow orbits you've got, nothing should appreciably change if you double, triple, or even x10 the timestep. But, to be fair, that's only going to buy you so much. So I think the SOI approach would be helpful here, too.
A Random Player
Posts: 523
Joined: Mon Jun 03, 2013 4:54 pm

Re: Rigid body rotations

Post by A Random Player »

testtubegames wrote:
A Random Player wrote:You mean extremely far, right? SOIs are inaccurate with multiple significant gravitation influences, and are even more accurate than n-body when things get really close (assuming point masses, of course).
Yeah, I think that was a wee miscommunication. The simulator runs by iterating over all forces, then changing velocities and positions. So, yeah, in the n-body way. This means, when two objects get really close, huge errors can come into play. I was hoping to fix that by using conics when two objects got really close (so some version of SOI). But I was never able to get it working properly. It would have helped tremendously with the accuracy, though.
A Random Player wrote:You got all the figures? That's probably just what I need! (I only have a and e) Could you share? :)
Okay, let me see (I'll write what I've got):

[maths]

That's what I grabbed from my old physics book, at least. I was never able to get this method to work well enough for me (it was, I'll say a while back, so I forget exactly what the problem was). So best of luck there.

As for the changing timesteps - I wouldn't be too stringent about that, myself. (The irony being that I *am* stringent about it in my simulator... hrm... but you're doing something different of course). When it comes to these slow orbits you've got, nothing should appreciably change if you double, triple, or even x10 the timestep. But, to be fair, that's only going to buy you so much. So I think the SOI approach would be helpful here, too.
Hmm.. That's basically what I have as well. I was hoping you'd have the angle of perigee or time at perigee. Guess I have to keep looking :D
comment on my cruithne goes the asteroids, someone?
$1 = 100¢ = (10¢)^2 = ($0.10)^2 = $0.01 = 1¢ [1]
Always check your units or you will have no money!
User avatar
robly18
Posts: 413
Joined: Tue Jun 04, 2013 2:03 pm

Re: Rigid body rotations

Post by robly18 »

Meanwhile, I sit here, not really knowing jack about such things.
I mean, I know basic orbital physics: apogee, perigee, formula for attraction between two bodies... but patched conics? Finding Ap and Pe from the velocity and position of an object at one point in time?

Well, that's something for me to try doing next time I'm bored in class. If I can figure out complex cubic roots of real numbers, I can do this one right?
Convincing people that 0.9999... = 1 since 2012
A Random Player
Posts: 523
Joined: Mon Jun 03, 2013 4:54 pm

Re: Rigid body rotations

Post by A Random Player »

Ok, for some reason I had a strange vision about this ending up like Captain Forever as well as KSP, and after a bit I've got quite a few ideas for simple parts. It'll require another large change though :( But it'd make more sense; all parts will be rectangles (or maybe shapes that fit in a grid) instead of all being circles. No time yet. :( (This is why you always plan out a project before starting it.)
$1 = 100¢ = (10¢)^2 = ($0.10)^2 = $0.01 = 1¢ [1]
Always check your units or you will have no money!
User avatar
testtubegames
Site Admin
Posts: 1148
Joined: Mon Nov 19, 2012 7:54 pm

Re: Rigid body rotations

Post by testtubegames »

A Random Player wrote:Ok, for some reason I had a strange vision about this ending up like Captain Forever as well as KSP
Never seen Captain Forever before... but that is one absorbing game! It's hard to get weapons, I will say. I keep disabling the other ships' lasers, which means I can't harvest them. Alas.
A Random Player wrote:(This is why you always plan out a project before starting it.)
Planning is good. But when it comes to games, testing and prototyping is awesome. They teach you so much, even if only "that you need to change the game." So fear not, it's not really wasted time.
User avatar
robly18
Posts: 413
Joined: Tue Jun 04, 2013 2:03 pm

Re: Rigid body rotations

Post by robly18 »

A Random Player wrote:Captain Forever
Oh boy, this.

Don't take me wrong, but I hate you for taking away my weekend now :(
Convincing people that 0.9999... = 1 since 2012
A Random Player
Posts: 523
Joined: Mon Jun 03, 2013 4:54 pm

Re: Rigid body rotations

Post by A Random Player »

NECRO TIME!!
I don't know how I managed this, but I have basically all the formulas working right now, and I can convert from M to E to theta and back again, and convert (x,y) and (xv,yv) into (a,e,omega,M0) and back in both elliptical and hyperbolic orbits. Still working on M0 and including omega though. It ended up not being that hard. Also need switching SOIs.
Really I'm starting a fresh program when I start making the game again. The old one has literally nothing in common with this one.
So current goal is a cross between ΔV, KSP, and CF. Proposed parts: Fuel tanks, batteries, solar panels, engines (with varying effieciencies), reaction wheels, rcs thrusters, pumps, wires (aka electricity pumps), and more. Now to figure out implementation of the ship structure...
Also ground is hard. So no ground. (I mean, put your hand on the ground and feel it! It's hard!)
$1 = 100¢ = (10¢)^2 = ($0.10)^2 = $0.01 = 1¢ [1]
Always check your units or you will have no money!
Post Reply