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.

[s]Bleh, forgot to reply to a part. If you see this, I'm still writing.[/s] 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 [s]the fire nation attacks[/s] I switch to patched conics.