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

[Fel]

chaos_forge, I'm not one to accept 3% error when the model still can be improved; which is why I was having a bit of a fit over how badly it handles typical bodies.

I STRONGLY believe that

A) You have more experience in astrophysics than I (Or rather, I choose to believe; you said you were a physicist in training)

If you stop trying to write a formula for equal mass objects, you can correct that error by modifying the action for non-equal mass objects

(In fact, the error should be greater for equal mass because "it should"... I think... idk, I woke up abruptly a half-hour ago [and fell asleep abruptly too])

(Yes, I was thinking about how a regular body akin to kerbin and the mun, should have a "barycenter" that is ~1cm off of kerbin's center [From mental imagery]. This is most accurate when approaching from "some angles that don't strongly intersect the different soi's"....)

*** In terms of the thingy ***

http://www.alemor.org/~mario/uploads/semicircle_barycenterdiagram.jpg

Think of it as having a "sphere of influence" whose radius is not actually the central object (planet A or ; these two spheres only applies while inside the Barycenter's SOI (hence akin to your statement; the stuff is separated-ma-tron)

As it stands, you could implement this with zero issue; for a single binary system... the issue is only the error.

Okay, it's been about an hour now :S, but try settling for a 1:3 system. The "Barycenter" you want is the orbital center (where the two objects orbit each other... ness... basically where you can spin it and stuff) As I see, the further the center is from either planet, the greater the inaccuracy, so if it is closer... w/e, you get it.

*I like the idea, I think it can be improved.

Edited July 10, 2013 by Fel

[chaos_forge]

The big problem is that your piecewise function breaks off the axis. Along most of the line connecting the centers of the two gravitating bodies, your piecewise function is okay â€â€*except for a single point where it goes to minus infinity. But just off that line connecting the centers, your piecewise function gives completely bonkers results, compared to real life.

Thanks for the graphs, I don't know how to make 3D graph like that xD And yes, you've identified exactly the problem with this model, which is the infinite force as you approach the barycenter. Would it be possible to make a graph using the semi-circular SOI's that I depicted above?

Adding new zones can be done ad infinium. Consider what happens when you have so many zones that you're making an SOI transition exactly once per frame; you're close to doing a full N-body simulation, assuming your zones are set up correctly. You can get a lot of granularity by adding a zone, say, at 0.05g gravity potential intervals. The issue is you start stressing the patched conics system since you're constantly doing SOI changes.

I agree. After thinking about this, I think the most reasonable approximation would be to have semi-circular SOI's. Having many concentric SOI's for the barycenter would put too much strain on the patched conics system.

The alternative to simplify that would be to have a simple circle SOI around both bodies which is basically what we have now.

Man, I feel like a broken record, but what would you think about the semi-circular SOI thing?

Okay, it's been about an hour now :S, but try settling for a 1:3 system. The "Barycenter" you want is the orbital center (where the two objects orbit each other... ness... basically where you can spin it and stuff) As I see, the further the center is from either planet, the greater the inaccuracy, so if it is closer... w/e, you get it.

I'll try doing some calculations for non-equal masses next, but my intuitive prediction is that the greater the difference between the masses, the less error there will be.

Edited July 10, 2013 by chaos_forge

[CaptainArbitrary]

Would it be possible to make a graph using the semi-circular SOI's that I depicted above?

After spending thirty seconds on it, I can't think of a quick way to, no. See, the plots I gave you are mathematical. The first plot is just an illustration of the gravitational acceleration field emerging from two fixed sources:

The second one is a piecewise function where the acceleration is a function of one body when close to that body, the other when close to that body, and everywhere else a function of your imaginary barycenter body:

In the second case, outside the SOIs of the two bodies (defined by radii râ‚ and râ‚‚) the gravitational acceleration field is created by a single source with the mass of both bodies that lies at the center of mass of the pair. That's what you described, and the plots I posted show the results.

This would work perfectly from outside the immediate vicinity of the system. That's Gauss's law, in essence; the gravitational field created by a distribution of mass looks, from a distance, like the field created by a single point of the same total mass. That's why when we do two-body gravity math we can ignore the fact that the bodies have extent; we can pretend they're just points.

But what you're trying to do is model the region between the two bodies in a way that's simple and that can be reduced to polynomials of time ("put on rails," in KSP jargon) but that comes close enough to reality to make it worth doing. You're not going to get there with this approach. The idea of using a piecewise function is fine in principle; that's essentially what KSP already does, with patched conics. But in the patched-conic approximation, you get away with it because the boundaries between regions are relatively smooth. They're discontinuous, yes, which is why you can't differentiate across them. But they're smoothish, because you choose to put your SOI boundaries out in fairly flat space, away from steep gradients. Like so:

The flat blue area is flat space, where the acceleration scalar is exactly zero everywhere. Within predefined radii, the acceleration scalar is like normal, going like 1/r². See how there are discontinuities at the boundaries, but they're relatively smooth ones? Crossing a boundary from flat space, the acceleration scalar goes from exactly zero to something with no transition, but the something it goes to is very close to zero. So it's okay; we can work with it without too many problems. It becomes a decent approximation of how things would happen in real life, where there are no discontinuities.

But in your model, the discontinuities in the region between the bodies are enormous; the acceleration scalar jumps wildly from one value to another very different value as you move from SOI to SOI. This would create some very weird behaviors, as your orbits make sudden right turns, or even go degenerate and hyperbolic, when you cross an SOI boundary.

It really doesn't matter how you implement your idea, I'm afraid. It really just can't work. You're trying to break Gauss's law, basically, by treating a non-symmetric distribution of mass as a single point from within that distribution of mass. That can never work. It can't even be close enough.

Sorry.

[chaos_forge]

But in your model, the discontinuities in the region between the bodies are enormous; the acceleration scalar jumps wildly from one value to another very different value as you move from SOI to SOI. This would create some very weird behaviors, as your orbits make sudden right turns, or even go degenerate and hyperbolic, when you cross an SOI boundary.

Ok, I see what you're saying. So in the case of semi-circular SOI's, the acceleration function would be continuous at the interface between the two planetary SOI's, but it would still be non-differentiable (similar to the vertex of an absolute value graph). And the non-differentiability is the more important problem.

EDIT: Just out of personal interest, what graphing utility are you using? If it's gnuplot, could I see the code you're using to get the graphs?

Edited July 10, 2013 by chaos_forge

[CaptainArbitrary]

Ok, I see what you're saying. So in the case of semi-circular SOI's, the acceleration function would be continuous at the interface between the two planetary SOI's, but it would still be non-differentiable (similar to the vertex of an absolute value graph). And the non-differentiability is the more important problem.

Kind of. If the boundary were continuous it would also be differentiable across, along the line connecting the radii. But even in that case, it would not be differentiable anywhere else. And it's not the fact that there's a discontinuity there that causes issues; there must necessarily be discontinuities in a patched-conic approximation. It's the magnitude of the discontinuity that causes the problem. You're moving from a region where your trajectory goes thisaway smoothly and sensibly to a region where your trajectory suddenly makes a 90° turn, or flips back on itself, or whatever.

EDIT: Just out of personal interest, what graphing utility are you using? If it's gnuplot, could I see the code you're using to get the graphs?

Too lazy for that. I just kicked 'em out in Mathematica right quick.

[chaos_forge]

Can I see the mathematica code then? I disagree with what you're saying, but I think being able to make graphs would help me visualize what I'm trying to say. And I just got mathematica literally last week, so it'd be easier for me to just modify your code than figure out how graphing works from scratch xD

Edited July 10, 2013 by chaos_forge
Grammar

[CaptainKipard]

I'm not a mathematician. I'm just spitballing here.

This might be like making rockets with duct tape but how about hemispheres of influence with some interpolation between the hemispheres and the barycenter SOI. To decrease the the magnitude of discontinuity you could extend the interpolation far inside the hemispheres and in the opposite direction into the barycenter SOI......or is that already too complex?

[LeadMagnet]

AHHHHHH...you killed Kenny...you *$%!@

Way over my head, but love the graphics!!

[chaos_forge]

I'm not a mathematician. I'm just spitballing here.

This might be like making rockets with duct tape but how about hemispheres of influence with some interpolation between the hemispheres and the barycenter SOI. To decrease the the magnitude of discontinuity you could extend the interpolation far inside the hemispheres and in the opposite direction into the barycenter SOI......or is that already too complex?

That's probably too complex.

[CaptainArbitrary]

Can I see the mathematica code then?

I didn't keep it. It's not really "code," though. You just type in the equations and tell Mathematica to plot them for you.

[CaptainKipard]

I'd be really interested in seeing a gravity plot for the HemiSOIs. I'm sure the devs would be too.

[NeilC]

There's a lot of good analysis here directed towards implementing this model.

however, I'd like to throw my hat in the ring with a simple question: What advantage does this system have over the current method from a gameplay sense?

It would only be worth implementing for bodies with similar masses - what KSP bodies/systems do you feel would benefit from this?

It would not model Lagrange points, or even approximate them. What new gameplay abilities would it give you?

It would cause more SOI changes, lower performance, and more orbit instability as Majiir mentioned. Why is that worth it?

...

What motivates changing to this system?

[chaos_forge]

I'd be really interested in seeing a gravity plot for the HemiSOIs. I'm sure the devs would be too.

Working on it xD Give me a while, I'm still learning how to use mathematica. But hopefully I'll have another one of my uber-long posts done by today evening.

There's a lot of good analysis here directed towards implementing this model.

however, I'd like to throw my hat in the ring with a simple question: What advantage does this system have over the current method from a gameplay sense?

It would only be worth implementing for bodies with similar masses - what KSP bodies/systems do you feel would benefit from this?

It would not model Lagrange points, or even approximate them. What new gameplay abilities would it give you?

It would cause more SOI changes, lower performance, and more orbit instability as Majiir mentioned. Why is that worth it?

...

What motivates changing to this system?

I think it's only worth implementing in systems where the barycenter is outside both planets/moons (this happens almost exclusively when they have similar masses). Currently no in-game systems would be changed, but if the distance between Ike and Duna was increased a little, then you could apply this system to them. The benefit of this system is that it would allow double planets, and eventually multiple-star systems (this is a long-term suggestion of course). For the benefit of multiple-star systems, see the thread I linked to in my original post. As for whether it would cause more SOI changes, probably, but the performance/feasibility of this system is (as you can see) still in debate.

EDIT: Also, it would just be really cool, and allow us to have several types of astronomical objects that are currently impossible in KSP.

Edited July 10, 2013 by chaos_forge

[CaptainKipard]

It would cause more SOI changes, lower performance, and more orbit instability as Majiir mentioned. Why is that worth it?

It'll be fine when we have multithreading and GPU physics.

[NeilC]

Ah, though I'm a big fan of the BSG series (modern, not 1970s) I'd never seen the layout of the 12 colonies - they don't really get into FTL ranges and such, I'd always assumed they were 12 different star systems. I understand the "cool factor" now.

Would it be fair to say that the main reason for implementing this system is to allow you to make a BSG mod?

Is this something that could be done with the current system, just by making "Barycenter objects" normal planets with really high masses, tiny collision meshes, and all-black texturing?

[tntristan12]

No NeilC. They're proposing a barycenter object that is a normal planet with NO collision mesh or texturing. What you're describing is a tiny black hole.

[chaos_forge]

Is this something that could be done with the current system, just by making "Barycenter objects" normal planets with really high masses, tiny collision meshes, and all-black texturing?

Well, that's more or less what I thought in my original post, but CaptainArbitrary pointed out some problems with that method that can't be overcome, so we had to come up with a different method. And that different method is semi-circular SOI's.

To refresh everyone's memories, this is approximately what the potential field for a real two-body system of equal masses would look like:

Now the system I described in my original post would produce a potential field that looks something like this:

The main problem with this system is that the force experienced as you approach the barycenter goes to infinity, which is significantly different from the real-life behavior. However, we were able to come up with a modification to my original idea, using semicircular SOI's, that would produce approximately the following potential well:

Revised model:

This model has two significant advantages: 1) that it more closely matches the real-life potential well, and 2) that the interface between the SOI's is relatively even/flat/"nice" at every point.

However, it also has one significant disadvantage, and that is that it would require the devs to change how SOI's behave. The main problem is that this model no longer uses spheres of influence, but rather "irregularly shaped regions" of influence. Apart from that, the behavior would (as far as I can tell) be the same as in KSP's current physics system.

I've also included a plot of the percentage error for the semicircle (revised) system, because why not? The error is always below 50%, which is okay, but not great. The calculation I'm doing is: (real value - simulated value) / real value

As long as we've given up on using spheres of influence, the SOI region of the two planets could be elongated somewhat along the x-axis and contracted along the y-axis to give us even lower amounts of error.

Sorry I haven't been able to do systems with an uneven distribution of masses yet, I'll see if I can get to that tomorrow.

Edited July 11, 2013 by chaos_forge

[NeilC]

So, if the only difference is the presence of a mesh and texture, it should be pretty easy to implement. I'm just pointing out that if it doesn't get implemented it would be easy to do in a mod once KSP allows celestial bodies to be modded.

Don't get me wrong, I like the idea! I'd love to see a BSG mod, I would definitely play that. That's why I'm suggesting ways to do it that don't involve changes to the game, so it's more likely to happen. If the only difference between "possible now" and "requires dev time" is a 1m black sphere at the barycenter that, granted, might be dense enough to form an event horizon if KSP actually modeled those physics... I think I could live with that.

[NeilC]

Gotcha, thanks for summarizing. Sorry I didn't read it more carefully before.

I hope the devs are listening. I'll be watching the Add-ons for your mod.

[chaos_forge]

So, if the only difference is the presence of a mesh and texture, it should be pretty easy to implement. I'm just pointing out that if it doesn't get implemented it would be easy to do in a mod once KSP allows celestial bodies to be modded.

Sorry, but I'm pretty sure it would require a change in the behavior of SOI's . Using the current SOI shapes would end up producing extremely unphysical/wonky behavior.

EDIT: But on the up side, I don't think changing the shapes of SOI's would be that difficult. After all, the shape should be little more than just a glorified if statement. Then again, I have no idea how KSP works on the inside . . .

EDIT2:

I'll be watching the Add-ons for your mod.

Well I start college in about two months, and I severely doubt I'll have enough free time to make a mod then (also I know nothing about programming C# or how Unity works), but if somebody else wants to make a mod using my idea, then go for it.

Edited July 11, 2013 by chaos_forge

[NeilC]

But on the up side, I don't think changing the shapes of SOI's would be that difficult. After all, the shape should be little more than just a glorified if statement. <...> (also I know nothing about programming C# or how Unity works)

I know a bit about programming. You're right, but the if statement is likely not even glorified. in pseudocode:

for( <all bodies in system> ) { if( distance(ship, <body>) <= SOI_RADIUS_FOR_BODY ) set_SOI(ship, <body>); }

I'd be surprised if KSP has any concept of the shape of an SOI at the moment: it's probably just a number, hardcoded or defined in a config file, and the circular assumption is built right into the way the code works.

Introducing any notion of shape, while certainly not impossible, would be non-trivial.

That's why this change is unlikely to happen, IMHO. You're proposing replacing a trivial system with a non-trivial one, and there don't seem to be any gameplay benefits associated with the change.

You could implement multi-planet and multi-star systems with the current SOI model. It's just that you'd either have to pick one of them as the center instead of having the concept of a barycenter, or you'd have to use a "tiny black hole" of a planet as a barycenter and have both orbit it. It wouldn't be as accurate. It wouldn't be as cool. But it would work the same for all intents and purposes as far as gameplay is concerned, with erratic behaviour near the barycenter - same with your SOI model, that's where your error is highest.

I really don't mean to be a negative nelly - I think this is a cool idea! Just possibly not a very practical one, in my opinion. Here's hoping the devs disagree.

Edited July 11, 2013 by NeilC

[CouchLizzard]

Chiming in with my two cents.

Unless I've got something confused, a hemisphere system should still be trivial, but would require a little extra coding. Whenever the ship is inside the inner barycenter radius, just consider the ship to be within the sphere of influence of the closer of the two bodies.

So, something like this: if( distance(ship, <barycenter>) <= BARYCENTER_INNER_RADIUS) { if( distance(ship, <body1>) < distance(ship, <body2>)) set_SOI(ship, <body1>); else set_SOI(ship, <body2>);}

Edit: Of course, this is assuming that the 'inner area' of the system is still spherical. I'm not sure if that could cause problems for more complex systems...

Edited July 11, 2013 by CouchLizzard

[tntristan12]

The problem is that the model chaos forge came up with (although it is impressively close to the real system), is still just for objects of the same mass. Granted, since the primary stipulation is that the barycenter must be external to both bodies (otherwise the current system could be used), but if they are not exactly equal than wouldn't the larger body's HSOI (HemiSphere Of Influence) be larger than the other one's? Perhaps the surface that divides the sphere into parts would be curved towards the smaller of the bodies, so that the region around the larger one was more of a waxing crescent shape, and the one around the smaller one was waning. Again, I disclaim that I don't know enough about n-body mechanics to say one way or the other, but it seems like a complication that'd need to be addressed for this to work.

Also, how would you set the size of each region? It seems to me like the best way to do it would be to set the size of the SOI to whatever the size would be of a single planet that contains the mass of both objects (using the standard SOI size formula) then deciding how to separate them based on the individual masses and other characteristics of the system.

I'm not sure how possible any of this is in the current framework. The only way to know for sure would be to get some input from the devs themselves, and I wouldn't hold my breath waiting for harv to come comment on this.

[CaptainKipard]

Wow chaos those plots look great but I noticed that you seem to be using "stars" that are either very large or very close together. Is that the reason for the large errors? Would it be more helpful to the devs if you demonstrated this method with something like BSG Helios Alpha and Beta for example?

Anyway here's some ideas for asymmetric VOIs (Volumes of influence) in addition to tntristan12's crescent idea.

[chaos_forge]

Unless I've got something confused, a hemisphere system should still be trivial, but would require a little extra coding. Whenever the ship is inside the inner barycenter radius, just consider the ship to be within the sphere of influence of the closer of the two bodies.

So, something like this: if( distance(ship, <barycenter>) <= BARYCENTER_INNER_RADIUS) { if( distance(ship, <body1>) < distance(ship, <body2>)) set_SOI(ship, <body1>); else set_SOI(ship, <body2>);}

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.

The problem is that the model chaos forge came up with (although it is impressively close to the real system), is still just for objects of the same mass. . . . Also, how would you set the size of each region?

I'm planning to do an analysis of the behavior when the masses are unequal next, but I won't be able to get to it until at least 12 hours from now (at the time of the writing of this post). The size of the SOI of the barycenter would be determined by using the normal SOI formula with an body whose mass is the combined mass of both stars/planets/moons. The SOI's of the two stars/planets/moon would be calculated using the relative locations of their lagrange points (specifically the L1 and L2 points).

Wow chaos those plots look great but I noticed that you seem to be using "stars" that are either very large or very close together. Is that the reason for the large errors?

Well right now what I'm doing is an extremely rough "proof-of-concept" simulation. I'm using a system of units such that the gravitational constant is 1, so it's hard to get "real-life" numbers. Once I make sure things work like they should, I'll use more realistic numbers. However, since I'm using percentage error and not absolute error, I'm not sure how it would be affected. I think the HemiSOI's should look like the picture on the left, but since I haven't gotten to test it yet I'm not sure.

Edited July 11, 2013 by chaos_forge