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

[NeilC]

Well, the problem with this code is that it's only applicable to models where both bodies have exactly the same mass. For bodies with differing masses, the interface should be the plane passing through the L1 lagrange point perpendicular to the line joining the center of the two bodies. So the if would become more complicated.

Differing masses isn't all. If this subsystem were to be implemented and made usable by modders (who love to push limits and do arbitrary things), it would need to deal with general cases so you can feed in any configuration and get sane results. Such as:

- more than 2 bodies. An algorithm that works with n bodies is needed, not an if statement for 2.

- bodies that don't share a common plane of revolution - think Ragnar anchorage, which orbits the barycenter of Helios Gamma/Delta rather than either star. There's no reason it needs to do so in the same plane that H G/D orbit their barycenter, and it's possible Ragnar's SOI could intersect one or both of H G/D over the course of their orbits.

I'm having trouble thinking of a way to extend this model to general cases that would be less complicated than just doing n-body physics.

[CaptainKipard]

- more than 2 bodies. An algorithm that works with n bodies is needed, not an if statement for 2.

With the exception of a single hypothetical 3-body system that's never even been seen by astronomers, every stellar or planetary arrangement will be easily approximated using the fragmented sphere piecewise function. That's because all star systems, even ones composed of 4 or more stars, have a binary hierarchy.

- bodies that don't share a common plane of revolution - think Ragnar anchorage, which orbits the barycenter of Helios Gamma/Delta rather than either star. There's no reason it needs to do so in the same plane that H G/D orbit their barycenter, and it's possible Ragnar's SOI could intersect one or both of H G/D over the course of their orbits.

Well in theory Ragnar *could* do that but no one is going to create rails that low for it. In reality Ragnar would have to be in a very high orbit around Helios GD in order to be stable enough to last the billions of years i takes for life to evolve and star traveling around the system. The map circling around the internet doesn't seem quite right to me.

[NeilC]

With the exception of a single hypothetical 3-body system that's never even been seen by astronomers, every stellar or planetary arrangement will be easily approximated using the fragmented sphere piecewise function. That's because all star systems, even ones composed of 4 or more stars, have a binary hierarchy.

Well in theory Ragnar *could* do that but no one is going to create rails that low for it. In reality Ragnar would have to be in a very high orbit around Helios GD in order to be stable enough to last the billions of years i takes for life to evolve and star traveling around the system. The map circling around the internet doesn't seem quite right to me.

I don't argue that in reality trinary star systems would be highly unstable and as a result have not been observed. But we would not necessarily be able to observe gas giants in distant orbit around the barycenter of a binary star. The Helios GD + Ragnar system is an example of such.

I agree that as long as you put the planet at a realistic distance from the barycenter (you've seen what people do with mods, right? ), you could model it as a separate body in orbit around the barycenter object, and the SOIs would never intersect. But you still need to answer the question: "I'm in the Helios GD system, and my position is <x>. Which SOI am I in?" There you have an implementation problem: if your SOI-region algorithm can only handle 2 objects, you must restrict the special barycenter object such that only 2 things can be in orbit. If the barycenter object is allowed to have 3 children, but the SOI algorithm for that object can only handle 2 arguments... how do you ever enter Ragnar's SOI?

EDIT: as I think about it, this argument holds for anything in "normal" orbit around a binary star implemented using the proposed barycenter object. How do you distinguish between "preferred" objects that get specially-shaped SOIs and "normal" objects?

Edited July 11, 2013 by NeilC

[Fel]

I really have no idea why you're making a 3d contour when you don't really have "3d data" (This is just a 2d analysis).

I haven't setup a vector field yet, but I think these make a fair bit more sense than the ones you're using. (As it is, I'm just comparing the strength of the gravitational field at point, a vector field will indicate the direction of the field, and hence indicate even larger problems). [i also put cut limits which created the boxes, it may look a bit bad, but it adds more contours to the more important data)

Simulated

Reality

Difference

Percent Error

And yay, Vector fields!

Reality

Simulation

Difference

http://i.imgur.com/S4gUYWr.png

A nightmare!

Edited July 12, 2013 by Fel

[chaos_forge]

I really have no idea why you're making a 3d contour when you don't really have "3d data" (This is just a 2d analysis).

Well, I was doing the same thing you were doing, but using the z-coordinate to show the 1d result of the 2 function. The pictures you have are just 2d contour graphs of the same thing.

[vexx32]

This idea needs a considerable amount of tweaking, but I could potentially see it as a working approximation of an n-body solution... It'd be interesting if someone could make a simple gravity simulation using a model similar to this just to help find potential problems.

[CouchLizzard]

Hm... thinking on the 'more than 2 bodies' problem, the simple if/else hemisphere system could pretty easily be extended to 'closest from a list' instead of 'closest of two'. Basically, it becomes a Voronoi diagram for SOI's. To solve the problem of different masses, I'm pretty sure simply weighting the distances by mass of the bodies could give reasonably accurate results (at the very least, from a gameplay standpoint). No need to calculate the dividing plane, since it's implied by the simple distance*mass function.

[Fel]

Well, I was doing the same thing you were doing, but using the z-coordinate to show the 1d result of the 2 function. The pictures you have are just 2d contour graphs of the same thing.

Aye, just that 2d contour graphs are more appropriate for the data set; especially since you have poles at infinity and piecewise data... and are more concerned about the actual DATA than "how it looks." (Although I didn't clip two of the graphs properly).

What motivates changing to this system?

I hate this argument. The truth is "Nothing motivates changing the system" because all motivation is subjective.

As one person's subjective motivation is not another's subjective motivation, the "request" is void and "end of discussion."

My 2 cent's.

[CaptainKipard]

I'm sorry NeilC I'm not entire sure what you're trying to get at, except:

There you have an implementation problem: if your SOI-region algorithm can only handle 2 objects, you must restrict the special barycenter object such that only 2 things can be in orbit. If the barycenter object is allowed to have 3 children, but the SOI algorithm for that object can only handle 2 arguments... how do you ever enter Ragnar's SOI?

EDIT: as I think about it, this argument holds for anything in "normal" orbit around a binary star implemented using the proposed barycenter object. How do you distinguish between "preferred" objects that get specially-shaped SOIs and "normal" objects?

I think You've misunderstood the purpose of this idea. It's to devise a way of subdividing VOIs to accommodate accurate behaviour relatively close to a binary system so that the physics engine can still take into account only two objects: your ship and the object that you're in the VOI of. Outside of that the current method can be used. It's not that a barycenter can only have 2 children. It's only that a barycenter VOI can have two child-VOIs. Each VOI can still have objects orbiting with their own regular SOIs as they are implemented right now. As for how you distinguish, a good way of deciding whether to use binary VOIs or current nested SOIs is the calculate whether a real barycenter would be inside or outside the bigger object.

Maybe this image will help. **NOT TO SCALE**

All the stars have Hemispheres of influence. AB and GD barycenters also have hemispheres. Finally the barycenter of both AB and GD barycenters (yes, barycenter of barycenters) has a sphere. Beyond that is interstellar space. BUT! Ragnar still has a regular nested SOI inside the GD VOI.

Edit: I've made a spelling error in the image. It should be Ragnar.

Edit 2: Actually I don't think I'm explaining this right. Don't think of the hemispheres as children, because I think they should be on the same hierarchical level as the barycenter VOI because it's a piecewise function whereas regular SOIs are actually in a nested hierarchy where the object you're close to takes precedence.

I really have no idea why you're making a 3d contour....

It allows you to easily see the magnitude of discontinuities.

Edited July 12, 2013 by Cpt. Kipard

[chaos_forge]

Differing masses isn't all. If this subsystem were to be implemented and made usable by modders (who love to push limits and do arbitrary things), it would need to deal with general cases so you can feed in any configuration and get sane results. Such as:

- more than 2 bodies. An algorithm that works with n bodies is needed, not an if statement for 2.

- bodies that don't share a common plane of revolution - think Ragnar anchorage, which orbits the barycenter of Helios Gamma/Delta rather than either star. There's no reason it needs to do so in the same plane that H G/D orbit their barycenter, and it's possible Ragnar's SOI could intersect one or both of H G/D over the course of their orbits.

I'm having trouble thinking of a way to extend this model to general cases that would be less complicated than just doing n-body physics.

I'm gonna have to agree with Cpt. Kipard on this. It's not unreasonable to assume that any n-body system appearing in nature can be sub-divided into single or binary objects in stable orbit around other single/binary objects.

As far as the SOI's we can just use the system that's already in place: planetary SOI's take precedence over star SOI's, and moon SOI's take precedence over planetary SOI's

But you still need to answer the question: "I'm in the Helios GD system, and my position is <x>. Which SOI am I in?"

Well, the SOI's are simply a piecewise function in 3d, as long as your boundaries between regions are well-defined, you should have no problem.

as I think about it, this argument holds for anything in "normal" orbit around a binary star implemented using the proposed barycenter object. How do you distinguish between "preferred" objects that get specially-shaped SOIs and "normal" objects?

The way I see it, it would work like this: all three objects would be in orbit around the barycenter, and the SOI logic would have to be changed so it has an extra "type" variable, so if the SOI is defined as "type 1" (the default), it would be spherical, while the two stars would have SOI's designated as "type 2", which would be hemispheres or whatever.

EDIT: actually, VOI's (Volumes of Influence) does make a lot more sense in this situation. Good idea.

EDIT2:

Hm... thinking on the 'more than 2 bodies' problem, the simple if/else hemisphere system could pretty easily be extended to 'closest from a list' instead of 'closest of two'. Basically, it becomes a Voronoi diagram for SOI's. To solve the problem of different masses, I'm pretty sure simply weighting the distances by mass of the bodies could give reasonably accurate results (at the very least, from a gameplay standpoint). No need to calculate the dividing plane, since it's implied by the simple distance*mass function.

Actually, this wouldn't be necessary. It's not unreasonable to assume that any n-body system appearing in nature can be sub-divided into single or binary objects in stable orbit around other single/binary objects. A Voronoi diagram is not needed. See Cpt. Kipard's post above for an idea of how VOI's for multiple objects would work.

Edited July 12, 2013 by chaos_forge

[NeilC]

I hate this argument. The truth is "Nothing motivates changing the system" because all motivation is subjective.

As one person's subjective motivation is not another's subjective motivation, the "request" is void and "end of discussion."

My 2 cent's.

It wasn't an argument. It was a question. Not all features are subjective. The motivation for implementing docking is that it lets you dock. The motivation for implementing staging is that it lets you build rockets that work. The motivation for implementing barycenters is more realistic binary systems.

My opinion is that realism oriented features are less important than gameplay oriented features in a game featuring tiny green men and planets denser than lead. You can disagree if you like, but it's a bit silly to claim that everything's relative and all features are of equal importance. Some require lots of dev work for little gameplay gain. That's not subjective.

[asmi]

Looking at all of this, I have to say that implementing real n-body would be much easier. You only need second Newton's law plus some numeric magic to make it work with timewarp...

[Fel]

Okay, did some calculations here....

Starting with offset being (-1,0) and (1,0) for planets

  M1 *  (X - 1)                M2 * (X + 1) 
--------------------   +  ------------------------= gx (x component of the gravity vector)
(X - 1)^2 + Y^2          (X + 1)^2 + Y^2

*** Now technically, I think it is suppose to be

  M1 *  (X - 1)                        M2 * (X + 1)
--------------------           +  ------------------------            = gx (normalized x component)
((X - 1)^2 + Y^2)^3/2          ((X + 1)^2 + Y^2)^3/2

But that is annoying to work with. (And there is only so much the CAS on my HP will do before it becomes a bigger headache than it is worth).

Now, turning this into polar coordinates (X^2 + Y^2 = R, r * cos(theta) = x)

(M1 - M2) * (R^2 + 1) + 2 * R * cos(theta) * (M1 + M2)
------------------------------------------------------- = gx (x component of gravity)
(M1 + M2) * (R^2 + 1) + 2 * R * cos(theta) * (M1 - M2)

integral over 0 to 2*pi

M1 + M2    4 * M1 * M2
-------- - ------------- * INV(SQRT( (M1 + M2)^2 - (2 * R * (M1 - M2) / (R^2 + 1))^2)) = x offset
M1 - M2      M1 - M2

And that (well, almost right due to laziness not wanting to do elaborate integration), should calculate the offset to the x component. ("Effective Gravitational Center") at a given distance from the center.

Edited July 12, 2013 by Fel

[Fel]

It wasn't an argument. It was a question. Not all features are subjective. The motivation for implementing docking is that it lets you dock. The motivation for implementing staging is that it lets you build rockets that work. The motivation for implementing barycenters is more realistic binary systems.

My opinion is that realism oriented features are less important than gameplay oriented features in a game featuring tiny green men and planets denser than lead. You can disagree if you like, but it's a bit silly to claim that everything's relative and all features are of equal importance. Some require lots of dev work for little gameplay gain. That's not subjective.

*dramatic sigh*

"Good gameplay" is subjective to the person playing the game. There is no getting around it, this IS a subjective argument.

As it stands, the suggested implementation requires less "devtime" than adding flags did; the most major change is not implementing the barycenter (KSP already does this), it is reshaping the SOI's. Though you could argue that adding in a binary object into the current universe is "devtime consuming" opening the planetary API to the public, and allowing others to use said tools to add said planets in said fashion alleviates said "devtime." And Frostkien certainly made note about how the "Features" SQUAD chose to employ were "Lots of Dev Work for Little Gameplay Gain."

The features being implemented are based on what the people want, and what SQUAD "feels has a nice fit in the game." If SQUAD decided to throw all away and work on adding bathrooms to their rockets; you'll likely have to put in potties for your kerbals.

Eitherway, as I said; KSP really already does this. Take kerbin, the mun's SOI overlaps Kerbin's SOI but both exist in harmony. The only thing happening with the "equal mass" binary system is two objects with very large SOI's are "orbiting" an "invisible planet." Leaving one planet's SOI either pulls you into the "barycenter / gravitation center"'s SOI or the other planet's SOI... exactly like what KSP already does.

[chaos_forge]

Looking at all of this, I have to say that implementing real n-body would be much easier. You only need second Newton's law plus some numeric magic to make it work with timewarp...

No. The N-body problem is VERY difficult. As in it hasn't been solved for more than a few trivial cases. As in it's still (more than 300 years after Newton's Principia) a subject of ongoing research in physics. No amount of "numeric magic" is going to make the N-body problem work.

My opinion is that realism oriented features are less important than gameplay oriented features in a game featuring tiny green men and planets denser than lead. You can disagree if you like, but it's a bit silly to claim that everything's relative and all features are of equal importance. Some require lots of dev work for little gameplay gain. That's not subjective.

To this statement, I could argue that this is a gameplay feature because it allows us to have systems that would otherwise be impossible, but honestly the main reason I'd like to see this in KSP is because I think it'd be awesome. And also we're trying to come up with a system that would require as little dev time as possible to implement.

ANYWAYS

Progress update on differing masses: I've gotten the mathematica code to work, and I'm getting some solid results, so expect a post about that either late today or early tomorrow (unless I get interrupted/distracted by something else)

Edited July 12, 2013 by chaos_forge

[asmi]

No. The N-body problem is VERY difficult. As in it hasn't been solved for more than a few trivial cases. As in it's still (more than 300 years after Newton's Principia) a subject of ongoing research in physics. No amount of "numeric magic" is going to make the N-body problem work.

You couldn't be more wrong. Ever heard of Orbiter? It implements n-body physics and work just fine with time acceleration, and even on ancient computers. The fact that in can not be solved analytically doesn't mean that in can't be solved at all. Numeric integration methods work perfectly fine in this case.

[tntristan12]

You couldn't be more wrong. Ever heard of Orbiter? It implements n-body physics and work just fine with time acceleration, and even on ancient computers. The fact that in can not be solved analytically doesn't mean that in can't be solved at all. Numeric integration methods work perfectly fine in this case.

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.

[Kragrathea]

Ah! Hello Kerbals. I found the first post in this thread most fascinating, but I am afraid almost every post since has flown straight over my head. But no worries. I have forwarded on to the boffins and they will give me a summary...

But It may interest you to know that we at Kragrathea have some expertize in this area! We use a similar technique as a method for simulating all the "important" bits of a barycenter. We call it a Manilo... where is that bloody video... Oh yes... Enjoy.

Edited July 13, 2013 by Kragrathea

[NeilC]

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.

[NeilC]

Binary systems can be created without changing anything about the current game. This proposal would not add binary systems, it would increase the realism of spacecraft behaviour while it's between the binary bodies. Again, I'm not claiming that's a bad thing. Just that it doesn't add much to gameplay. I agree that it's both "cool" and "awesome", and I'm only staying in this discussion to help steer it towards "practical".

Fel, there's no point in arguing with you further. I think invoking that frostiken thread is pretty much the Godwin's law of the ksp forums. In the same post you argue that ksp devs are wasting time with low-value features and also that there's no such thing as low value features. I really can't respond to that.

Chaos-forge, I look forward to seeing what you come up with for the unequal mass soi equations! What are your thoughts on 3 body systems like Ragnar anchorage?

[tntristan12]

Ah! Hello Kerbals. I found the first post in this thread most fascinating, but I am afraid almost every post since has flown straight over my head. But no worries. I have forwarded on to the boffins and they will give me a summary...

But It may interest you to know that we at Kragrathea have some expertize in this area! We use a similar technique as a method for simulating all the "important" bits of a barycenter. We call it a Manilo... where is that bloody video... Oh yes... Enjoy.

That is two stars orbiting a planet which is not only unrealistic but as discussed in this very thread simulates very unphysical behavior off the centerline between them.

[Sean Mirrsen]

Except for cases when sudden time acceleration sends your spacecraft out of the solar system or throws moons out of orbit.

The first still happens in extreme cases in KSP, and the latter does not apply as all of KSP's stellar bodies are on rails.

Also, orbiter doesn't simulate physics to individual parts within a ship.

Neither does KSP when the numeric integration would be at work. At any significant time warp, everything is reduced to a parametrized point.

Sure, it works on a basic level but it is far from perfect and does not work for casual play like what KSP does.

On the contrary, it is perfect for casual play (nothing is more exciting than having real physics in accessible form), and would not require anything more complex than has already been done by other games, while adding a great amount of possibilities to both the world and the gameplay.

[chaos_forge]

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?

But It may interest you to know that we at Kragrathea have some expertize in this area! We use a similar technique as a method for simulating all the "important" bits of a barycenter. We call it a Manilo... where is that bloody video... Oh yes... Enjoy.

Wow that looks interesting, is it a mod or something the devs have done?

[Mr Shifty]

Wow that looks interesting, is it a mod or something the devs have done?

It's a mod in progress. Check out this post (and that whole thread) for more detail.

[chaos_forge]

Cool, thanks for pointing me to that

EDIT:

Chaos-forge, I look forward to seeing what you come up with for the unequal mass soi equations! What are your thoughts on 3 body systems like Ragnar anchorage?

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.

Edited July 13, 2013 by chaos_forge