Barycenters and non-spherical Volumes of Influence (an idea for binary planets/stars)

[asmi]

Except for cases when sudden time acceleration sends your spacecraft out of the solar system or throws moons out of orbit. Also, orbiter doesn't simulate physics to individual parts within a ship. Sure, it works on a basic level but it is far from perfect and does not work for casual play like what KSP does.

So, from "it's hard" statement you went to "it's not casual'?

[asmi]

First of all, can we please stop talking about the feasibility of implementing N-body physics? The devs have said time and time again that they are not implementing N-body physics, it's on the do-not-suggest list, and I don't want this thread getting shut down. I shouldn't have gotten drawn into the argument, and I apologize for that, but can we please drop this or take it somewhere else?

This point it - proper n-body is easier and better than what's being proposed here.

[Mr Shifty]

This point it - proper n-body is easier and better than what's being proposed here.

True only if by easier you mean that it would require a rewrite of the game engine from the ground up. What's being proposed here would require minor modifications to what already exists.

[NeilC]

I don't see much of a problem with implementing that. As long as you had your Ragnar-analogue far away enough from the barycenter that neither its orbit nor its SOI intersected the VOI's of the two stars (which is more realistic anyways) it should work fine.

The devil's in the details. Orbits in ksp are defined by a reference to orbiting body and a bunch of orbital parameters. It's a one parent- to many-child tree structure that's used the same way by all craft, moons, planets, or potential new stars. Soi changes are either down this tree when you get within a threshold distance of something else also orbiting the same parent (from kerbin to mun) or up this tree when you get further than the parent's soi (from kerbin to kerbol).

This means that while you're in the kerbin system, you're only doing SOI checks on other things orbiting kerbin and on leaving kerbin. there's no need to do soi checks on jool. It's more than one tree node away and can be safely ignored.

To implement your system requires a cross-tree transition (H alpha to H beta, directly) which is potentially problematic. You'd need to consider two "tree hops", from H alpha to barycenter to H beta. Same as kerbin to kerbol to jool, which we don't want to consider.

there's also no difference between Ragnar and the two stars in the tree structure - they both orbit the barycenter. How do you single out the stars for special treatment?

[tntristan12]

So, from "it's hard" statement you went to "it's not casual'?

It's not hard. It's impossible. You cannot reconcile n body physics with on rails simulating. There is no analytical solution for n body physics that allows you to predict where the craft will be.

Numerical simulations are far too unstable to be used reliably at high time accelerations for extended periods of time. You want to see this in action? Load up orbiter and get into LEO, then wratchet up time acceleration to max. Good things do not happen. That's fine for orbiter which relies on its users to behave sensibly and not push things to the limit, but KSP is a game... Not a simulation. It needs to be solid, accessable, and fast. Orbiter doesn't. That's what I meant.

Edited July 13, 2013 by tntristan12

[chaos_forge]

This point it - proper n-body is easier and better than what's being proposed here.

No, the point is, the devs have said that N-body is never ever getting implemented, so whether its better or not is irrelevant. To continue arguing about N-body will at best derail the intelligent, reasonable, and fruitful discussion that we are having, and at worst get this thread shut down for violation of the do-not-suggest list. If you think my idea sucks, say so, but don't bring up N-body.

To everyone else, all I ask is that you ignore any posts relating to implementing full N-body. Don't feed the troll(s).

The devil's in the details. Orbits in ksp are defined by a reference to orbiting body and a bunch of orbital parameters. It's a one parent- to many-child tree structure that's used the same way by all craft, moons, planets, or potential new stars. Soi changes are either down this tree when you get within a threshold distance of something else also orbiting the same parent (from kerbin to mun) or up this tree when you get further than the parent's soi (from kerbin to kerbol).

This means that while you're in the kerbin system, you're only doing SOI checks on other things orbiting kerbin and on leaving kerbin. there's no need to do soi checks on jool. It's more than one tree node away and can be safely ignored.

To implement your system requires a cross-tree transition (H alpha to H beta, directly) which is potentially problematic. You'd need to consider two "tree hops", from H alpha to barycenter to H beta. Same as kerbin to kerbol to jool, which we don't want to consider.

there's also no difference between Ragnar and the two stars in the tree structure - they both orbit the barycenter. How do you single out the stars for special treatment?

Yeah, I see what you're saying there. I actually hadn't considered that, but I wonder if it would be possible to have some sort of infinitesimal separation between the H alpha and H beta VOI's, so a ship would still *technically* pass though the barycenter SOI when transitioning. Another possibility would be to implement the barycenter as a special object with two required children that have the special logic applied to them, and then could have zero or more optional normally-behaved children. The problem with that, of course, is that it would require more modifications to the code.

Edited July 13, 2013 by chaos_forge

[tntristan12]

Hey chaos_forge. Have you gotten any data for how your hemiSOI approximation would work for non-identical masses?

[chaos_forge]

Yeah, sorry it took me so long xD But finally after the long wait, I come bearing joyous news from the land of mathematica!

Firstly, I've determined that, for cases where the smaller mass is 1/4th or less of the larger mass, the barycenter system in its original, simpler-to-implement incarnation is good enough: (first graph=force field, second graph=error)

Basically, my criterion for calling "good enough" is whether the error you get is comparable to the error you get using KSP's current system:

And finally, the HemiSOI's in this case would look like this:

It was a bit complicated because to find the location of L1 and L2, you have to solve a quintic equation, but mathematica didn't seem to have any problems with it, so as long as the SOI's are pre-calculated and put in a config file by the devs, there shouldn't be a problem. I've also finally gotten the mathematica notebook in a easy to use state, so if anybody wants to see the graphs run through with different numbers, or even the code itself, just let me know.

Edited July 14, 2013 by chaos_forge

[Fel]

*sighs about the 3d graphs* (Just that you can barely see anything with things like "http://www.alemor.org/~mario/uploads/mathematica_barycenter_error5.jpg")

My own tests show something interesting with regards to the hemisphere errors....

Try doing vector analysis and seeing how the directional currents change based on the hemisphere model and the original model:

What I found was that there is an extremely small area when two bodies actually matter and most tend to go to the "gravitational center", in turn... the hemisphere model actually had GREATER error, direction wise.

@NeilC

You're intentionally over-complicating this in a self-serving argument to deny implementing it. It is annoying.

The proposal is for binary systems that can be expanded upon via additional barycenter objects. He is not reshaping the kerbin universe, he's just adding in new "planetary objects."

*And seriously, I just repeated your argument back at you with Frostkein... that you refuse to understand how development works is your issue and does NOT change the subjectivity of your argument.

(And actually, you're subjectively applying this so called "Godwin's law" to KSP, hence are subjectively invalidating an argument on subjectivity!)

Edited July 15, 2013 by Fel

[chaos_forge]

*sighs about the 3d graphs* (Just that you can barely see anything with things like "http://www.alemor.org/~mario/uploads/mathematica_barycenter_error5.jpg")

My own tests show something interesting with regards to the hemisphere errors....

Try doing vector analysis and seeing how the directional currents change based on the hemisphere model and the original model:

What I found was that there is an extremely small area when two bodies actually matter and most tend to go to the "gravitational center", in turn... the hemisphere model actually had GREATER error, direction wise.

Well the vector field of what I posted would just be the gradient of the function, so that's relatively easy to visualize . . . but let me get back to you on that once I figure out how to make vector graphs.

The problem with this is that we're trying to optimize two things at the same time: the magnitude and the direction of the force. So far I've been considering the error in magnitude as more important than the error in direction. The problem with the original idea was that in many cases the error in the magnitude of the force would be far too large (approaching infinity).

The way I see it there are basically three possibilities:

1) Implement the original SOI model. Problem: only works when m1/m2 > 4 (where m1 is the larger mass)

2) Implement the HemiSOI model. Problem: has greater directional error.

3) Set up a system to switch between the two models depending on m1/m2 ratio. Problem: overly complicated to implement.

In my opinion, option #2 is the best.

EDIT: Also, since most tend to go towards the gravitational center, that's why we have the outer barycenter region. Keep in mind that the VOI's of the two planets are small in comparison with the size of the overall SOI of the barycenter.

Edited July 15, 2013 by chaos_forge

[Horn Brain]

I have a way to improve the hemispherical model which is quite simple (one if statement) and which actually generalizes the selection of VoI boundaries over the whole range of mass ratios between the two objects.

Simply use the following rule when in the "inner region" to determine which VoI you are in:

Let 1 denote a quantity pertaining to the more massive body, 2 to the lower.

r is distance from spacecraft to a body (r1 or r2).

m is mass of a body.

The craft is in the VoI of the body with the greater quantity m^2/r^5.

So the rule would be: if m1^2/r1^5 > m2^2/r2^5, then the craft is in the VoI of body 1, otherwise it is in the VoI of body 2.

The form of the rule comes from the definition of SoI radius used by KSP currently: R_SOI = a (m/M)^(2/5), where R_SOI is the SoI radius, a is the semi-major axis of the secondary around the primary, m is the small mass and M is the large. If you plug in some values, you can see that for the case of m1=m2 (or m=M, equivalently), then the rule I give reduces to choosing the closer of the two bodies, and the boundary between their VoI's would be the plane equidistant between them. If you use very large mass ratios, then the SoI is a sphere centered around the secondary body with radius R_SOI. This means that in the limit of very different masses (think a planet and a star), the rule behaves the same way it currently does in KSP! The variation is smooth between the two cases (it looks like the plane curves away from the primary and translates towards the secondary until it is a small sphere completely enclosed within the "inner region"). I'm at work, but I can do some figures later.

The problem is that since this relies on the distance to the two bodies, it would only work for circular orbits, otherwise the VoI boundaries would move as the distance between the bodies changed. This could be fixed by using the average position (based on the sum of the semi-major axes of the two bodies' orbits) of each body instead of its current position (at least for low eccentricity orbits, like Ike and Duna).

Tell me what you think. I think this rule makes the hemispherical model the natural extension of the current system. Further, if you choose the "inner region" radius correctly, you could have craft in orbits that approximate L2 and L3 orbits for some binary planets with very similar masses.

Edited July 17, 2013 by Horn Brain
clarified point about potential L2 and L3 orbits, corrected error in rule

[tntristan12]

That sounds really good! It'd be nice if you could come up with some plots like the one Chaos Forge came up with so the more visual among us can see it.

[chaos_forge]

I have a way to improve the hemispherical model which is quite simple (one if statement) and which actually generalizes the selection of VoI boundaries over the whole range of mass ratios between the two objects.

I agree with tntristan12 that it's rather hard to visualize, but I think I can understand what you're trying to say. I'd be interested to know how much that if statement differs from my arbitrary choosing of the boundary to be at L1.

R_SOI = a (m/M)^(2/5), where R_SOI is the SoI radius, a is the semi-major axis of the secondary around the primary, m is the small mass and M is the large

I'd be interested in seeing how they got this formula. So far, I was using the radius of each body's hill sphere, which gives you an SOI formula of R_SOI = a*(m2 / 3m1)^(1/3)

If you plug in some values, you can see that for the case of m1=m2 (or m=M, equivalently), then the rule I give reduces to choosing the closer of the two bodies, and the boundary between their VoI's would be the plane equidistant between them. If you use very large mass ratios, then the SoI is a sphere centered around the secondary body with radius R_SOI. This means that in the limit of very different masses (think a planet and a star), the rule behaves the same way it currently does in KSP! The variation is smooth between the two cases (it looks like the plane curves away from the primary and translates towards the secondary until it is a small sphere completely enclosed within the "inner region").

If the SOI's approach KSP's current method as m1/m2 approaches infinity, how would you decide where the inner region stops and the outer region begins?

[Horn Brain]

These figures should help. Sorry I didn't have time before.

The Red area is the VoI of the large body (large cyan dot on the right).

The Blue area is the VoI of the small body (smaller red dot on the left).

The location of inner/outer boundary (outer region is the green) is arbitrarily chosen to be about 40% further from the secondary body than the L2 point. This is just what I picked. It turns out that matching the SoI currently used by KSP in the infinite mass ratio limit will always mean swallowing the L points, unfortunately. Choosing the L2 point to be on the boundary means that the VoI of the secondary does not become an island (it does not avoid the inner/outer boundary) until very high mass ratios (Kerbin/Mun wouldn't do it, and I think Duna/Ike is the only system where you might want to consider using this new model).

Hopefully this helps you guys visualize what's going on.

Javascript is disabled. View full album

[tntristan12]

Yeah that's more or less what I pictured. Looks like there is something there, but I'd really like to see an error diagram like the ones CF makes. I wonder if he could work on that. If it's good enough I wonder if a mod could be made, or even a separate program demonstrating it's viability.

Another question for you Horn: under your model how would the objects orbit? Would there need to be a separate barycenter object like what was suggested in the OP? Would it's VoI extend out beyond the VoIs of the individual planets? Or would they just orbit around the center of the whole sphere?

Also, how would this work with more than one body (such as Minmus or the Jool system)? Would there be a larger SOI outside that one which could contain other moons or planets, or would you nest this setup you have inside another one just like it, potentially simulating 3 and 4 body systems?

Edited July 16, 2013 by tntristan12

[chaos_forge]

These figures should help. Sorry I didn't have time before.

The Red area is the VoI of the large body (large cyan dot on the right).

The Blue area is the VoI of the small body (smaller red dot on the left).

The location of inner/outer boundary (outer region is the green) is arbitrarily chosen to be about 40% further from the secondary body than the L2 point. This is just what I picked. It turns out that matching the SoI currently used by KSP in the infinite mass ratio limit will always mean swallowing the L points, unfortunately. Choosing the L2 point to be on the boundary means that the VoI of the secondary does not become an island (it does not avoid the inner/outer boundary) until very high mass ratios (Kerbin/Mun wouldn't do it, and I think Duna/Ike is the only system where you might want to consider using this new model).

Hopefully this helps you guys visualize what's going on.

I just tried to do a quick-and-dirty implementation of the VOI system you showed to get some estimates on error, but I can't seem to get the same shapes you're getting. Exactly what limiting conditions (if statement) are you using?

Also: where did you get the formula for KSP's system from?

Edited July 17, 2013 by chaos_forge

[Horn Brain]

I got the formula from here: http://en.wikipedia.org/wiki/Sphere_of_influence_(astrodynamics) If you do the math it matches with the SoI's of the various bodies in KSP perfectly.

My limiting rule is NOT what I gave in the post (I've corrected it now, but r and m were switched, my mistake). It's easiest to use it in this form: the boundary is given by r1/r2 = (m1/m2)^(2/5), where rX is the distance to body X and mX is the mass of body X. My apologies.

[Horn Brain]

I don't think my rule (or any reasonable rule) is going to work for more than two bodies of similar masses in a system. You could have other (smaller) bodies in the outer region orbiting the barycenter, or you could have smaller bodies orbiting close to one or the other of the two large bodies.

[CaptainKipard]

I don't think my rule (or any reasonable rule) is going to work for more than two bodies of similar masses in a system. You could have other (smaller) bodies in the outer region orbiting the barycenter, or you could have smaller bodies orbiting close to one or the other of the two large bodies.

Yes. That's the point.

I like Brain's idea a lot more infact I was going to suggest something like that. It looks like it should reduce the huge error in the corners of the smaller VOI.

[chaos_forge]

I got the formula from here: http://en.wikipedia.org/wiki/Sphere_...astrodynamics) If you do the math it matches with the SoI's of the various bodies in KSP perfectly.

My limiting rule is NOT what I gave in the post (I've corrected it now, but r and m were switched, my mistake). It's easiest to use it in this form: the boundary is given by r1/r2 = (m1/m2)^(2/5), where rX is the distance to body X and mX is the mass of body X. My apologies.

Cool, I'll try to get some error graphs working ASAP.

But now I'm wondering what the difference between an SOI and a Hill Sphere is xD.

I like Brain's idea a lot more infact I was going to suggest something like that. It looks like it should reduce the huge error in the corners of the smaller VOI.

Yeah, I agree, this seems like a much better system. Also the fact that it reduces to the hemisphere system when the masses are equal makes a lot of sense.

EDIT: here is a quick plot and % error plot made using the corrected formula and the same mass ratio (4) as with the other plots I posted before

Edited July 17, 2013 by chaos_forge

[Person012345]

Universe sandbox is another example of a numeric n-body code that works just fine. The problem isn't technical feasibility or implementation difficulty, it's performance as n gets large. Ksp devs have taken n body off the table for performance reasons, not because it's hard to do.

Ubox has some horrific simulation problems at high time warp.

I like the ideas in this thread. I think the devs should definitely consider this as an alternative to n-body physics (since we know those won't be in).

Edited July 17, 2013 by Person012345

[MalfunctionM1Ke]

Theory is nice, but i dont know how Squad could implement this into the game plus to keep it simple enough for the "normal users".

[chaos_forge]

Theory is nice, but i dont know how Squad could implement this into the game plus to keep it simple enough for the "normal users".

How so? All of this math is in the background, all the player would see is that his ship changes VOI's at certain points.

[Horn Brain]

How so? All of this math is in the background, all the player would see is that his ship changes VOI's at certain points.

Additionally, it should be noted that none of this changes anything for any of the planets in the game (except possibly Duna and Ike, if you wanted). It will all still work exactly the same except when the player enters a binary planet system, which presumably would mean they knew what they were getting into.

To be clear: You would use the current system (primary-dominant) for all systems with mass ratios above a certain value, say 15, or 50. You would only turn on this barycenter system for planetary systems like Pluto/Charon (MR= 8.12) or some exotic double moon that the devs wanted to put in orbit around one of the new gas giants.

Edited July 17, 2013 by Horn Brain
added clarification

[Horn Brain]

Cool, I'll try to get some error graphs working ASAP.

But now I'm wondering what the difference between an SOI and a Hill Sphere is xD.

Yeah, I agree, this seems like a much better system. Also the fact that it reduces to the hemisphere system when the masses are equal makes a lot of sense.

EDIT: here is a quick plot and % error plot made using the corrected formula and the same mass ratio (4) as with the other plots I posted before

--snip--

Hard to see what the actual peak error is. Could you plot all of these as 2d contour plots with a colorbar so we can see the magnitudes more clearly? If not, maybe just upload profile views of each so we can see the peak values.