Body items (including stationary surface objects)

[charliewhitfield]

IVBody is our core program object for anything that orbits or is orbited. But we have no program object that represents an item on a body. You could jury-rig a visual on IVSpheroidModel, but that's fragile. E.g., we just added custom 3D models for Iapetus, Mimas, and Charon, so they don't even use that visual class now. Note that I, Voyager class pattern is to split a thing (IVBody, IVOrbit, IVSmallBodiesGroup) from its visual representation (all the "visual" classes in tree/ plus shaders). The distinction is even more important now with the recent "farwarp" system that keeps everything visible at all zoom scales. IVBody global position and scale are not the same as IVBodyVisual.

Surface objects could include stationary launch facilities, landers, "buildings" (e.g., a space elevator), or non-stationary objects like rovers. We probably should be agnostic even about "surface". The defining characteristic is an item that is fixed to an IVBody, which is exactly exclusive with our IVBody definition above. I propose to call this IVBodyItem. (Alternative suggestions are welcome.) We're not providing anything complicated in ivoyager_core, but it should do the following:

• Be ready for project subclassing.
• Have a "position" relative to its IVBody. We'll need Euclidian coordinates internally, but could provide convenience polar coordinate setters or even just latitude/longitude/altitude (accounting for oblateness of a spheroid body).
• Provide a reference frame for a provided model analogous to IVBodyVisual for IVBody (this handles the farwarp system).
• Provide properties and signals that can be used by a position visual (see below).
• (Optional) Provide process method registry similar to IVBody and IVSpheroidModel (so tables can specify process logic).

We can repurpose the existing IVBodyPositionVisual to simply "IVPositionVisual" to handle both classes. That gives access to the same symbols and GUI seen here. Some special logic might be needed to keep text from disappearing into the body for a surface item.

[andreasfranke1]

At first glance, this looks very nice, and is something similar to what we have done!

We pivoted away from defining a unique new class, though, to extending IVBody. The reason for that is that we borrow a lot from IVBody and we have quite some logic which applies to both ground and space assets, making the differentiation bloaty in code (if gdscript would support interfaces, that would be another story...). I stand by my comment in the other discussion and would suggest to keep using IVBody, but generalize it. That way, e.g. many things stay the same (e.g. selection logic, displaying characteristics, and the ground assets show up as children the same way e.g. spacecraft do) without much changes. Additionally, it could support something like rockets that are first stationary, but then start out with a trajectory, i.e. a transition from fixed to a not fixed reference system? I feel like this could be easier done with one IVBody which changes the way its positioning works based on some IVOrbit derivative.

(Overall, and this is a little off topic, IVBody is huge and thus could profit from a component system. Currently, a lot of logic is embedded within IVBody for selection, managing its visualization, camera behavior, huds, some getters like mean_radius, spheroid_type, polar_radius, has_rings, or gravitational_parameter which really only make sense for larger bodies. "Surface" could just be another component here then. What do you think?)

[charliewhitfield]

OK, the rocket example makes your point about using IVBody for both. Conceptually, a surface item is just a body that's being contact-accelerated by another body. Code-wise, we already support bodies that don't have an IVOrbit: the Sun or any primary star. The sun has a fixed position in Universe, which happens to be (0,0,0) but could be anything. A surface item could have no orbit but have a position, but it does need to be rotated by IVBody. We could have a surface_items dictionary analogous to the existing satellites.

Note that IVBody can't rotate because it would "break" space for our orbits. IVPhysicalBody was our rotating frame of reference, but it got absorbed into the farwarp visual system; it's position is no longer "real" (and it was doing only graphics work) so I renamed it IVBodyVisual. Maybe IVPhysicalBody should return as the "real" rotating frame that can support surface items. (IVBodyVisual can then use that and do it's graphics-only job.)

A conceptually cleaner alternative (but bigger change) would be to have a dedicated IVGravityCenter that serves the current translation-only spatial role of IVBody. This is the object that orbits and is orbited. Then IVBody is the object with mass, rotation, a "surface", etc. This would lead more naturally to barycenter implementation. And it would split the roles to help with the current bloat. (But this is firmly v0.3 stuff if we do it.)

[andreasfranke1]

Maybe IVPhysicalBody should return as the "real" rotating frame that can support surface items.

That honestly sounds nice already, and maybe is the smaller change for now until IVGravityCenter takes over. For now, I think we can get around by assigning the Basis of IVBody's get_orientation to the stationary body that rests on it.