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

[tntristan12]

Just out of curiosity, how does the horn brain model work under general (i.e. non-circular) binary orbits?

[chaos_forge]

Wait . . . we completely forgot about elliptical orbits!

Let the brainstorming commence!

Having the VOI's change sizes would probably be a bad idea, so I'd say you could use the average size of the VOI or something like that. I wonder how KSP handles SOI's and highly elliptical orbits . . .

[CaptainKipard]

I don't think we need to worry about eccentric orbits of stars since those probably wouldn't allow for very stable heliocentric planetary orbits (barycentric orbits would still be fine though if high enough). I mean planets are less likely to develop around stars like that. The devs wouldn't even need to create stellar systems with elliptical star orbits.

More interesting is planetary and moon eccentricity since those aren't of the question. I think the barycenter should remain exactly the same but the VOIs inside should scale dynamically. This seems the most realistic to me. It wont be much of a problem since:

a) Regular SOIs should be used for planets and maybe someday things like highly eccentric comets.

Currently the most eccentric orbit is that of Gilly at 0.55, the next is Eeloo at 0.26. Both of those orbit bodies far more massive then they are so regular SOIs should still be used right?

This is just off the top of my head. I'm in a bit of a hurry right now. I'll think about it later.

[InfinityArch]

Hmmm, any data on whether Eeloo's SOI changes as it approaches the apo/periapsis of its orbit? I would think not if SOI is a fixed constant, but if it's calculated dynamically...

[chaos_forge]

The KSP wiki only has one number for SOI radius, which makes me think that the SOI's don't change sizes dynamically. Dynamically changing VOI's would probably be too complicated to program; I don't really like the idea. And anyways, Wikipedia's page on SOI's gives a formula for SOI radius that depends on the semimajor axis, which is already a sort of average distance. The planets around a binary star should just have the current/normal SOI's: that's easiest, makes sense, and also matches what KSP currently does.

What's really bugging me are the VOI's of the two stars . . . I don't know how you could have eccentric orbits without making the VOI's change size. I mean, we could limit the system to binary pairs with low/zero eccentricity, but the physicist in me is screaming "that's not the most general case!" . . .

[NeilC]

What's really bugging me are the VOI's of the two stars . . . I don't know how you could have eccentric orbits without making the VOI's change size. I mean, we could limit the system to binary pairs with low/zero eccentricity, but the physicist in me is screaming "that's not the most general case!" . . .

And the programmer in me is screaming "there's no easy way to enforce circular orbits without adding another subsystem to check for that! Mods that add arbitrary binary systems will break this system if it doesn't deal with the general case!"

Good work guys, keep thinking it through! I'm enjoying reading this thread, and I hope most here don't find my input annoying. I'm just coming at it from the implementation side more than the idea side, so I tend to highlight potential problems more than math-based solutions. It's intended as constructive criticism, sorry if it doesn't come through that way.

[Captain Sierra]

Implementation: an absolute f***ing nightmare.

If it does get implemented: Insanely cool.

From what I know, some of what Squad does is already limited by Unity and this would be tricky because you'd have to have basically a nonexistent mass creating an SoI rather than the actual comic objects themselves. I don't know much about how they are doing the kerbol system in unity but I highly doubt that would be easy. It will be awesome though when I can do gravitational slingshots through the barycenter off to the edge of the solar system.

[Horn Brain]

And the programmer in me is screaming "there's no easy way to enforce circular orbits without adding another subsystem to check for that! Mods that add arbitrary binary systems will break this system if it doesn't deal with the general case!"

Good work guys, keep thinking it through! I'm enjoying reading this thread, and I hope most here don't find my input annoying. I'm just coming at it from the implementation side more than the idea side, so I tend to highlight potential problems more than math-based solutions. It's intended as constructive criticism, sorry if it doesn't come through that way.

The easy way to enforce circular/low-eccentricity orbits is to just not make binary pairs with high eccentricity. From a programming perspective, it's as simple as limiting the range of the random number that gives the eccentricity to less than 0.2 (or something like that) when the mass ratio is lower than a certain amount (say 20), which is when you would be using my system instead of the current system. Since KSP uses orbital elements to calculate on-rails bodies' trajectories, presumably the procedural generation process would be selecting random numbers for the mass ratio, primary mass, eccentricity, SMA, etc. This makes it trivial.

[Horn Brain]

The KSP wiki only has one number for SOI radius, which makes me think that the SOI's don't change sizes dynamically. Dynamically changing VOI's would probably be too complicated to program; I don't really like the idea. And anyways, Wikipedia's page on SOI's gives a formula for SOI radius that depends on the semimajor axis, which is already a sort of average distance. The planets around a binary star should just have the current/normal SOI's: that's easiest, makes sense, and also matches what KSP currently does.

What's really bugging me are the VOI's of the two stars . . . I don't know how you could have eccentric orbits without making the VOI's change size. I mean, we could limit the system to binary pairs with low/zero eccentricity, but the physicist in me is screaming "that's not the most general case!" . . .

You can't do highly elliptic binaries with this method without dynamic VoI calculations. The inner/outer region boundary would pulsate in radius, with the VoI's inside scaling with that radius (they won't change shape, just size). That would be just using the distance from each body and my rule to determine which VoI you're in, and using the current distance between the bodies (times some potentially mass-ratio dependent factor) to set the inner/outer boundary radius.

This would be highly confusing if you didn't know what you were doing, obviously.

As far as having a dynamic VoI, I don't think that it would be much of a pain to code up, honestly. The current system already has to check the distance between your craft and any bodies in the same SoI at each point (or many points, rather) along your orbit to determine if you get an encounter with that body, using this system would just mean taking those distances and plugging them into my rule to see if there is a transition. One measly extra calculation.

There would be weird behavior if you were going very slowly across the VoI boundary when the inner/outer radius was changing rapidly (when the bodies were closest together), but it would only be if you were going very slow and isn't any different than what happens if you're moving very slowly across SoI's in the current system.

[NeilC]

The easy way to enforce circular/low-eccentricity orbits is to just not make binary pairs with high eccentricity.<...> procedural generation process would be selecting random numbers for the mass ratio, primary mass, eccentricity, SMA, etc. This makes it trivial.

What procedural generation are you talking about? There is no system like that in KSP, and to my knowledge none is planned. Instead there is a static universe with predefined orbital parameters - everyone sees the same Kerbol. I think we're discussing this binary VOI system with the intent of opening it up to modders, who would then be able to create their own systems and set their parameters to whatever they please - BSG, here we come. I don't believe there is any system in place that could be leveraged to check whether eccentricities are valid; it would have to be written from scratch. This in itself would be fairly trivial, I agree, since all you would have to do is check any binary bodies in the universe once on loading the mod and refuse to load any binary systems that have high eccentricities or large mass ratios. This is simple, but pretty limiting. Modders don't like limits and the next logical step from "better binary bodies" is "even better binary bodies". KSP devs like to write robust and extensible code that can be leveraged by modders in unexpected ways - like airships and cranes. If it's possible to deal with the general case of elliptical orbits, that would be more likely to be implemented than a system restricted to two bodies with a certain acceptable range of mass ratios and orbital parameters.

You can't do highly elliptic binaries with this method without dynamic VoI calculations. <...>

As far as having a dynamic VoI, I don't think that it would be much of a pain to code up, honestly. <...> One measly extra calculation. <...>

That's pretty hand-wavey.... We're not sure how deeply the constant-radius-sphere assumption is embedded in the orbital mechanics solver. Moving from spherical SOIs to rule-based VOIs is a significant change, and having to recalculate them every timestep is a bigger one. One measley calculation can affect performance if you have to do it often enough - though I agree it doesn't look too bad in terms of crunch required. There's just a lot more to it than that.

What about using the suggestion above: take the semi-major axis as an average and use a constant VOI system? How bad does the error get as eccentricity increases? At what point do the VOIs start to overlap (which would break things)? You guys love plots, let's see some pretty pictures!

[Horn Brain]

What procedural generation are you talking about? There is no system like that in KSP, and to my knowledge none is planned.

--etc.--

You were saying arbitrary binaries can't be implemented without checking eccentricity, and I assumed he meant procedural generation, didn't notice you were talking about mods. That's interesting, but the modders will have to obey some rules. Even in the current system, you can already imagine a planet that has a moon that crashes into it over and over just by setting the eccentricity high enough. Certainly the current model doesn't handle THAT scenario, and yet that isn't "checked for". What you're asking of my model is to enforce common sense in everyone that uses it. I wish I had that power.

As for the hand wavey-ness of my implementation, how exactly do you think the spherical SoI assumption could be hard-coded into the program? The simplest way to do it would be to just check the distance between a craft and any body that it could potentially be in the SoI of at several future times and see if it comes closer than r_SoI. In my model, you do the same thing, except there are a few extra if statements if you are within r_SoI of a barycenter object. Done. The cost of getting the distance from one point to another in 3d space (square three differences, add, and take square root) is far more than the cost of checking my rule (multiply pre-calculated mass ratio^(2/5) by one distance), so it would be a trivial performance drain. I don't think we should even worry about this, because neither of us knows what the code is actually doing. That's for any of the devs that read this to decide whether implementing this would be a nightmare or an if statement.

I don't think dynamic VoIs are necessary; you can just choose to have circular orbits for the handful of bodies that use this logic, anyway. My point is only that they are simpler to implement than fixing the VoI sizes by using the average position of each body (based on the SMA), which would require calculating distances to new, special points in space, rather than just to the bodies themselves.

Edited July 25, 2013 by Horn Brain
changed "him" to "you" when I noticed you were the one I was replying to before. :-)

[NeilC]

<...>What you're asking of my model is to enforce common sense in everyone that uses it. I wish I had that power.<...>

As for the hand wavey-ness of my implementation, how exactly do you think the spherical SoI assumption could be hard-coded into the program? <...>I don't think we should even worry about this, because neither of us knows what the code is actually doing. That's for any of the devs that read this to decide whether implementing this would be a nightmare or an if statement.<...>My point is only that they are simpler to implement than fixing the VoI sizes by using the average position of each body (based on the SMA), which would require calculating distances to new, special points in space, rather than just to the bodies themselves.

Point taken about common sense. I think it's a little less intuitive to know you shouldn't put e>0.2 on a binary compared to knowing you shouldn't put peri<=r1+r2 on an orbiting planet... but you're right it would be trivial to "train" modders with documentation and by disallowing high-eccentricity binaries.

I wrote out some pseudocode earlier in this thread describing how I think it's hard-coded. Basically it would use a single value for r_SOI that never changes. the only shape that fits this 3D->1D reduction is a sphere - they haven't implemented the concept of shapes and decided to use a sphere, the sphere is hard-coded by using a 1D parameterization of SOI. I know I don't have source access and can't confirm this 100%, but it's a fairly simple operation and I think it's a very reasonable assumption. Programmers are lazy, and good programmers even lazier - the simplest implementation is usually the best.

I agree that your rule with constant r_SOI for your bodies is just a more-complicated if statement. That's why I liked your suggestion so much! It doesn't require implementing the concept of a shape, just more distance checks (with the order of checks now being important, since the larger mass has a non-spherical VOI and must be the default rather than having a checkable VOI).

My hand-waveyness reference was specifically for dynamic VOIs being "not that hard to code up" - here, I agree with you about not knowing enough about the codebase to make that assumption. What I do know from my own experience is that if you've architected a program based on the assumption that some things are constant, it can be a real pain to tear up that assumption. Things break in ways you wouldn't expect.

I think we agree that dynamic VOIs are probably too complicated to implement to be worthwhile.

Edited July 25, 2013 by NeilC
realized an example didn't make sense.

[chaos_forge]

I just realized that dynamic VOI's are already encoded into the boundary condition we're using: r1/r2 = (m1/m2)^(2/5)

As the distance between objects 1 and 2 changes, so do r1 and r2.

That said, I still don't like the idea of dynamic VOI's because I feel like it would wreak havoc on the patched conics system. And any spherical VOI (the inner/outer barycenter boundary, the SOI's of moons/planets orbiting the objects) should definitely remain fixed in size.

Edited July 26, 2013 by chaos_forge

[Horn Brain]

And as luck would have it, we finish discussing our grand idea just before 0.21 and subsequent vacations by the dev that would be implementing this. No way Harv saw this. Sad face.

Anyway, I think we've got it worked out pretty well if we can get two bodies to orbit their barycenter properly. The one thing that remains is how do we implement this in the game? I think you would have to include a barycenter object with the mass of both bodies, then set each of the two bodies to orbit the barycenter with the ratio of their SMAs determined by the mass ratio (I think it goes a1/a2= m2/m1) with the same eccentricity. However, if that's all it was, then their periods wouldn't match up and they would be out of phase immediately (except for the case of m1=m2). This is unfortunately the pain in implementation that would make this modification so hard to do. You would have to rewrite the whole orbit determination code to handle a proper two-body problem, where objects orbit on the ends of a vector pinned at the barycenter, with the vector determined by the mechanics of the full, mutually gravitating two-body problem (the vector is the position of a satellite orbiting the barycenter which has mass m1+m2). That would be the issue. Once that was worked out, my system would be trivial to implement.

[chaos_forge]

Hmm, that's something we hadn't thought of . . . well, it really depends on how the on-rails system works. If physically impossible orbits are allowed, then it's just a case of putting in the right numbers. Otherwise, the barycenter would have to have different pulls on each body, which would be a pain to implement. Each body could still have a elliptical one-body orbit, but the parameters would have to be set up right.

[NeilC]

For a very informative tutorial about how orbits are parameterized in KSP, see this

.

I'm not sure what you mean by "physically impossible" - all orbits are modelled as perfect ellipses, which is not physically possible if you want to get really technical, but is plenty close enough for most purposes. You can edit anything's orbital parameters and put it in whatever elliptical (or hyperbolic) orbit you'd like.

All planets and all craft beyond a certain range of the active craft have orbits that are "on rails." There is no concept of "pull" from the parent body, things just follow their ellipses perfectly. I highly doubt that will be changed, it's a major feature of how KSP works and changing it would have large performance implications. It would be best to work within that constraint and stick to elliptical orbits for this idea.

As for performing additional checks to enforce eccentricity = 0 on binary objects, I don't think that would be too tough. Or to enforce whatever parameter-matching you'd like, working with the parameters described in that video.

Edited August 7, 2013 by NeilC

[Taquarinha]

It's impossible because Unity engine can't workout n-Body calculations.

[Horn Brain]

I'm not sure what you mean by "physically impossible"

I think he means can you have two bodies orbit the barycenter with different SMAs and the same period (which is impossible if the barycenter was an actual gravitating object). Methinks the game is hard-coded to use the mass of the body the planet is orbiting to setup the orbit, which would make it impossible. The only solutions I can think of would be to have two barycenter objects with different masses (one for each body to orbit) or to rework the way the code handles orbits so that you can set both the period and the SMA independently.

[Horn Brain]

It's impossible because Unity engine can't workout n-Body calculations.

There are no n-Body calculations involved in anything being discussed here.

[chaos_forge]

I think he means can you have two bodies orbit the barycenter with different SMAs and the same period (which is impossible if the barycenter was an actual gravitating object). Methinks the game is hard-coded to use the mass of the body the planet is orbiting to setup the orbit, which would make it impossible. The only solutions I can think of would be to have two barycenter objects with different masses (one for each body to orbit) or to rework the way the code handles orbits so that you can set both the period and the SMA independently.

Yeah, I don't know what would be worse: to implement barycenters as an object with two different masses, or make orbital periods for planets independent of the mass of the object it's orbiting.

[NeilC]

I think he means can you have two bodies orbit the barycenter with different SMAs and the same period (which is impossible if the barycenter was an actual gravitating object). Methinks the game is hard-coded to use the mass of the body the planet is orbiting to setup the orbit, which would make it impossible. The only solutions I can think of would be to have two barycenter objects with different masses (one for each body to orbit) or to rework the way the code handles orbits so that you can set both the period and the SMA independently.

Yes, because orbital period is defined by SMA and parent mass in the elliptical (Keplerian) model this is impossible. It's also non-physical: real-world orbits don't work like that in the typical case where distances are large and/or one mass is substantially larger than the other. In that case SMA and period are directly related, and that's the case KSP models.

Yeah, I don't know what would be worse: to implement barycenters as an object with two different masses, or make orbital periods for planets independent of the mass of the object it's orbiting.

The game only takes the mass of the parent body into account when a craft is in focus. Then it's solving physics for every part, including thrust and grav force.

While anything is "on rails", the game does not use the mass of either uses the mass of the parent object to calculate orbital period, but does not have any concept of forces. It uses only the Keplerian orbital elements to define the orbital path and the craft/planet/moon/star's position on it at any given time. That's why it's called "on rails" - no complicated physics is used. Just trace the ellipse.

This is going to be a problem for general binary systems. For example, I can imagine a stable 2-body system with M1 = 3*M2, where both bodies orbit the center of gravity 3/4 of the way between them (closest to M1). They would both be in circular orbits about the barycenter. They would both have the same period. But M1 would have an SMA 3/4 that of M2. KSP's "on rails" system would not deal with this case properly, since it cannot be approximated by a Keplerian orbit. Simulating this requires N-body calcs in the special case of n=2. Which is a non-starter and (again) is not being discussed here. I'm just pointing out the point at which the discussion would cross that line: let's not go there.

More I think about it, the more I think you'd have to limit binary systems to the special case of circular orbits with both objects at the same radius. And therefore physically they would need to have the same mass - not sure about in-game, though. Because planets are never in focus their masses might not be checked as they orbit one another, only when a craft orbits one of them. The engine might do a "consistency pass" though, and reject non-physical system definitions. Not sure, since this is still a closed system. If I know software developers, though, they're beautifully lazy (read: efficient! no offense) and have just calculated correct parameters for the Kerbol system offline and have input those without implementing a checking system.

Edit:

Interesting.... I think KSP would deal just fine with the top picture shown here for an elliptical binary system where the SMAs are the same but the orbits are 180deg out of phase. So there's at least one interesting special case! But I'm still pretty sure it wouldn't handle the second case, a Pluto/charon type orbit like I described above.

Edited August 7, 2013 by NeilC
I'm an idiot. Of course KSP uses mass to calculate orbital period.

[loknar]

If I know software developers, though, they're beautifully lazy (read: efficient! no offense) and have just calculated correct parameters for the Kerbol system offline and have input those without implementing a checking system.

As a developer I can confirm that suspicion. I'm almost sure KSP is no exception - and I hope that they don't recalculate the orbits constantly for performance reasons.

I'm all for adding more content and planets and stars in the future - but don't forget about performance - transitions between SOI are already causing a small pause in the game. My 2 cents: If you want to add 0.1% realistic physics but my FPS will drop to 3 I'm against it. /Iamoversimplifying

[chaos_forge]

-snip-

While anything is "on rails", the game does not use the mass of either uses the mass of the parent object to calculate orbital period, but does not have any concept of forces.

-snip-

Right. A way to fix this would be to make planetary orbits not use the mass of the parent object and have instead be a value that you can set.

Or, since the barycenter object would already treat its children in different ways (because of wonky VOI's), it might be possible for it to "show" different mass values to the different planets in orbit around it.

[NeilC]

Right. A way to fix this would be to make planetary orbits not use the mass of the parent object and have instead be a value that you can set.

Or, since the barycenter object would already treat its children in different ways (because of wonky VOI's), it might be possible for it to "show" different mass values to the different planets in orbit around it.

Yeah, I finally understood your "two masses" point as I was falling asleep last night - sorry, I posted before thinking it through.

IMHO, a change that makes orbital period a stored parameter just like SMA and eccentricity would be cleaner than any two-masses solution. It would be easy to make it backwards-compatible, too: just fill the parameter with the mass-based autocalc if it doesn't exist, use the specified one if it does.

[chaos_forge]

IMHO, a change that makes orbital period a stored parameter just like SMA and eccentricity would be cleaner than any two-masses solution. It would be easy to make it backwards-compatible, too: just fill the parameter with the mass-based autocalc if it doesn't exist, use the specified one if it does.

Would this also affect crafts on rails?