Generalize IVOrbit to allow for other movement definitions

[andreasfranke1]

In our project, we want to have two additional movement definitions, one for stationary objects on planet surfaces, for example, and another one for very precise trajectories (fed from ephemeris data). While it is possible to cover this by implementing a new Body class, it would be way cleaner for us if IVOrbit references in IVBody would be replaced by a more generic class, from which IVBody just requests the data, because we do not really alter IVBody in another manner (for now). Would that be feasible?

[charliewhitfield]

Note 2nd item under "Ongoing improvements" in our Roadmap.

See IVRealPlanetOrbit, which is used by our Planeterium. It's a subclass of IVOrbit that adjust orbit elements (specifically, time of periapsis passage, t₀) to implement Table 2b adjustments from https://ssd.jpl.nasa.gov/planets/approx_pos.html. We don't exactly follow that page's instructions, which tells you to adjust mean anomaly (M) "on the fly". Instead, we use the provided adjustments to change the orbit elements (t₀ here) so that IVOrbit can just do what it does normally: i.e., calculate everything from the defining elements. I think this is more correct, and it means that we can use IVOrbit as is. This is also the intended pattern for a future IVManeuveringOrbit that adds impulse and thrust options (see IVOrbit class doc TODOs).

I think you should follow this pattern by creating an IVOrbit subclass "EphemerisOrbit" (for example). What you need to do is "fix" IVOrbit elements at runtime, not the class logic or its existing plumbing with the rest of the simulation. IVOrbit is deeply entrenched in IVBody and visuals like IVPathVisual (e.g., the latter listens to its changed signal to update its graphic).

[Edit: This is in master, not current release:] I just added static var replacement_subclass: Script in IVOrbit following existing pattern in IVBody. For project-wide replacement, just set IVOrbit.replacement_subclass = EphemerisOrbit in init code somewhere. I tested with a print-only test class and it works. It's harmless to do a project-wide replacement and then only use ephemeris update logic for selected orbits. Or you can use the subclass only for selected bodies, but you'll need to modify the class factory (IVTableOrbitBuilder) to do that.

If and when you get this working and your project allows, I'd love to have this in the Core plugin as an optional IVEphemerisOrbit class. It's not too useful for games but it would be a major improvement for our Planetarium.

Let me think about the stationary surface objects ... that's something different.

[andreasfranke1]

I think you should follow this pattern by creating an IVOrbit subclass "EphemerisOrbit" (for example). What you need to do is "fix" IVOrbit elements at runtime

The thing with our Ephemeris data is that it does not necessarily reconstruct orbits. Thus, all the orbital parameters one can set in IVOrbit are unused, and that could confuse future developers (as in: What do we use of the parent class and what do we not use?)

I just added static var replacement_subclass: Script in IVOrbit following existing pattern in IVBody. For project-wide replacement, just set IVOrbit.replacement_subclass = EphemerisOrbit in init code somewhere.

Thank you!

If and when you get this working and your project allows, I'd love to have this in the Core plugin as an optional IVEphemerisOrbit class. It's not too useful for games but it would be a major improvement for our Planetarium.

As soon as we go open source, I think we can backport it. For now, it's also just a todo that will hopefully be done in the near future, but probably not by me.

[charliewhitfield]

@andreasfranke1 , I opened a separate proposal for surface items. Please check to see if that would meet your needs.

[charliewhitfield]

IVBody has to have something from which it can ask: What is my position? What is my velocity? Also, other parts of the simulation are asking IVBody: What is your orbit apoapsis? What is your orbit eccentricity? IVBody must provide answers, even if they are nonanswer answers like 0.0 or NAN (though this would break the sim already in several places). All of these queries logically go to a component called "orbit". I believe there are only 3 design possibilities:

1. Duck-type orbit. Existing IVBody.orbit becomes type Object, and we just expect that object (whatever it is) to have the methods to deliver these answers. Or we have IVBody always query first to see if a method exists.
2. IVOrbit is a pure interface/abstract class with no logic. Then we add our logic as subclass IVKeplerianOrbit (or more verbosely IVKeplerianOrbitWithPrecessions).
3. IVOrbit is a concrete class with overridable logic. (This is what we have.)

Duck-typing is not an option. We use it in GUI and some other areas, but not for physics.

So that leaves 2 or 3. I know that some coders would say everything should be an interface. One advantage to using Godot's @abstract annotation is that it forces a subclass designer to "fulfill the contract". Specifically, it's a compile error if you don't override an abstract method. My argument for our current design is that "Keplerian" is essentially synonymous with orbit. We're just giving you some Keplerian orbit logic. You are free to override it.

But you still have to answer questions: What is your eccentricity? What is your apoapsis? Our visual class IVPathVisual needs to know to determine vertex density (for the line graphic when zoomed in close) and AABB. You could get away with nonanswer 0.0 or NAN for some specific orbit properties, but you would have to identify these case-by-case.

On ephemerides specifically, if you have state (position and velocity) then you can obtain orbit elements. It's just a coordinate conversion for any object moving in space assuming you have GM of a parent body. IVOrbit provides static methods to do these conversions. The reason we use elements as our "fundamental" coordinate system is that it doesn't need an update every frame. If you update elements, then you can generate state to very high precision for some amount of time before you need an element refresh. If you update state only and bypass elements, then you will need to update 60 frames per second. (But you'll still need some elements or element-related stats to service other parts of the sim.)

[andreasfranke1]

I would go for 2., for the reasons you have mentioned. As for the questions that need to be answered, everything that includes questions about orbital parameters should, in my opinion, first be asked when the question are you an orbit? has been answered, e.g. by trying to parse a more generic (abstract) type, say, IVPositionProvider, into an IVOrbit. This IVOrbit instance then provides the interface needed for orbit-specific calculations. But this whole construction still allows for non-orbital positioning. The problem with the ephemerides is basically, yes, we have position and velocity, and yes, mostly even the body in which reference frame we are moving, but the thing with ephemeride is that they might include forces contrary to the assumptions of IVOrbit. A spacecraft can accelerate or slow down based on propulsion or atmospheric drag. We would be required to update the calculated orbit every frame and every shown predictions/lines of this orbit will always be off.

That's why I propose to separate the idea that an IVBody must have an Orbit into the idea that the IVBody has something that provides positional, attitudal, and maybe velocity information, and that that something can be an orbit object, but not necessarily has to be. Yes, this means that for some bodies existing classes such as the IVPathVisual do not work anymore, but that would be totally fine from my side, as these would require other implementations anyways.

[charliewhitfield]

forces contrary to the assumptions of IVOrbit. A spacecraft can accelerate or slow down based on propulsion or atmospheric drag

I think you're underestimating IVOrbit. See plans for IVResonantOrbit and IVManeuveringOrbit in the doc comments. This is exactly what we're building toward.

In any case, I think the near-term solution is to provide an alternative alt_positioning component that is called in IVBody._process() if it exists. IVBody already can exist with orbit == null (that's the Sun) and we're talking about surface items as IVBody. I think a fully abstract IVOrbit is not what you want, because you would then have to override every method in the class (so you're even more forced into Keplerian stuff you don't want to deal with).

While you're here, check out some new graphics capabilities coming in v0.2: here and here.

[andreasfranke1]

I think you're underestimating IVOrbit. See plans for IVResonantOrbit and IVManeuveringOrbit in the doc comments. This is exactly what we're building toward.

Ah, that's very cool!

In any case, I think the near-term solution is to provide an alternative alt_positioning component that is called in IVBody._process() if it exists.

Sounds good to me.

I think a fully abstract IVOrbit is not what you want, because you would then have to override every method in the class (so you're even more forced into Keplerian stuff you don't want to deal with).

I agree. In my opinion, I would try to decouple the assumption that IVBody has access to Keplerian parameters from the class itself.