Component System for IVBodies

[andreasfranke1]

Heyhey, just dropping a random thought into the discussion forum here: Maybe IVBody could profit from being split into components. I think we have talked about this somewhere already shortly, but I couldn't find it for now, so sorry if I repeat myself at some spots.

The background of the thought is that with every feature added, the IVBody class tends to get bigger and bigger, combining more and more functionality into one class. It is important that IVBody keeps that functionality, but I regularly loose overview of the class simply because of its size.
At the same time, I am starting to think about extending IVBody with ground and space asset specific functionality. But sometimes, they might even combine, having e.g. antennae to display. So instead of using inheritance, it might make sense to split IVBodies' functionalities into components, and thus cleanly separate code chunks from each other.
That way, we could split the whopping almost 2000 (!) lines of code of ivbody into, let's say, the following components:

• A Visualization component, which handles everything in regards to visuals
• A HUDs component, which handles everything in regards to huds
• A selection component, which handles everything in regards to selection
• A camera_navigatable component, containing the necessary functions for the camera to focus this object
• A spheroid_body component, if the body can be modelled as a spheroid, containing relevant functions (mean radius, poles, ...)
• A small_asset_body component, if the body is too small to be a spheroid.
• A orbit component, containing everything in regards to orbit data

The upside of this is that it separates code that does not necessarily rely on each other (or only has a one-way relationship), but also allows to configure bodies to e.g. become unselectable or unfocusable when never adding the specific components, and adding new components only to these bodies that require it. (The idea is thus closely related to ECS btw, which is often used in games with lots of bodies)

Let me know what you think. I believe such a system would require a lot of rework within the architecture, and maybe there is a better way to handle said problems other than using components.

[charliewhitfield]

This will be v0.3, since it's an overhaul of IVBody API (which is currently rather massive). Just some high level thoughts for now...

IVBody used to be a free object in space. Even the Sun was supposed to get an IVOrbit, since its path is just a locally perturbed orbit around the galaxy center of gravity (exactly what IVOrbit and its subclasses are designed to handle). But we're talking about making IVBody into an abstract "entity" (more on ECS below) that could be a rocket on the ground, a rover, or a building. So orbit then becomes optional.

There's are benefits and costs to doing that. The cost is that all of my game code can't just query a body for its orbit periapsis. Instead it has to check if body has an orbit, get the orbit, then query the orbit. Same goes for position, geometry, size, etc. It's a pain if you have to go through 3 steps to get anything. We should think about what minimal thing an IVBody represents, and allow at least those things to be gotten from members or API getters.

Current architecture for "visuals" and HUDs is that body isn't aware of them. They need information from body. Body needs nothing from them. (Note: If you're reaching into the visual for something like geometry, that's an indication that something is missing from body.)

On ECS, I'll probably use a little ECS-inspired architecture for IVOrbit specifically. It's the biggest processor load now and would be prohibitive at many 1000s or 10000s of orbiting bodies. (IVSmallBodiesGroup can handle 100000s already but that's via GPU.) In v0.2, I've already overhauled most IVOrbit API to use PackedFloat64Array as the main data type. The next step is to move all orbit data and its calculations to the "S" part of ECS (class "IVOrbitSystem" or something like that). IVOrbit keeps all of its API but becomes an interface to IVOrbitSystem. I'm not interested in wholesale ECS everywhere. But I'm happy to use a better data system where it matters for performance. (Tangential note: After change above, porting IVOrbit to C++ is the logical next step for performance. This is one reason that I'm so loath to use duck-typing in anything like "physics" code.)

[Edit:] I wonder if the class should be renamed IVEntity? When doing such a large change, it's often easier to code the replacement as an entirely new class rather than editing the existing class. And "body" has an astronomical implication that we're intentionally moving away from. (The name may annoy ECS fans if we're not fully ECS, but that's not a big deal.)

[andreasfranke1]

We should think about what minimal thing an IVBody represents, and allow at least those things to be gotten from members or API getters.

I agree, and I also saw some practical implementations which indeed exposed major components (such as position) as members.

Current architecture for "visuals" and HUDs is that body isn't aware of them.

Ah, yeah, the naming in my proposal could be changed to something more generic then, which explains the information exposed rather than its use.

[charliewhitfield]

@andreasfranke1,

See IVBody_REDESIGN_v0.3.md planning doc. The link points to the working doc in my develop branch, which will change more frequently than the master branch.

[andreasfranke1]

Hey @charliewhitfield!

Very cool proposal, thanks a lot! Some feedback:

• "IVBody must be ignorant of its HUD elements. At most a passive hud_elements: Array[Node3D] container for external convenience.": I recommend having a separate Manager for HUD elements, which contains the mapping from body to widgets, or not having any at all and instead just let the HUD elements have a reference to IVBody but not the other way around.
• "IVBody extends Node3D and is never rotated or scaled. Local translations at every tree level are in the ecliptic basis." Tbh, I would move away from that and rather let each node in each level its own reference frame, as is done usually in astronomy afaik. Note that there are always two reference frames: There are terrestrial reference frames, which rotate with the body around its rotation axis, and celestial reference frames, which are rotated like the body, but don't rotate with it. Maybe providing both in some way could prove beneficial. (E.g. having a node3D that is in celestial reference frame, and then a function returning a basis that additionally applies the rotation to get into terrestrial reference frame. But just dumping spontaneous ideas here).
• I would move the "Static registry bodies, top_bodies" to a separate BodyManager.
• 4.1 Regarding readonly variables: What we do in our code is mark them as private (e.g., var _star: IVBody) and have a getter function (func get_star() -> IVBody) that allows to fetch a reference to it. That way it is clear that one can not write to it just by convention, though it makes the code a little bit more unreadable.
• 4.2 regarding get_orbit: If I understand, this function only return a casted IVPositioner. Imo it can be dropped, as we should not make an assumption about what kind of type IVPositioner is (Btw, it doesn't increase the amount of null checks. var orbit := body.get_orbit(); if orbit: orbit.get_eccentricity() turns into if body.positioner is IVOrbit: var orbit := body.positioner as IVOrbit; orbit.get_eccentricity() ). get_orientationwould only call therotater, no? get_mean_radiusalso is a call togeometry`. All of these could be omited, I think, and instead the components could be asked directly if not null (if null, it should probably be up to the respective caller what to do. Abort calculations or proceed with something else?)
• 4.2 "GUI contracts": What is get_float_precision? Furthermore, I would probably move get_selection_texture_2d directly to IVAssetPreloader, since IVBody should not cache in between anymore anyways. (acc. to 4.1)
• 4.2 "duck-type protocol delegates" is a contradiction to one of the ground rules (no duck-typing inside IVBody). I'd recommend all traversal helpers to be moved to a nullable IVSelectable component - I might want to instantiate a IVBody that should not be focusable with the camera.
• remove: You can afaik override free, and queue_free. I would recommend doing that because it is the standard way in godot :)
• 4.3 is missing the update for the rotator.
• 4.5: I'd recommend to move identity flags out of BodyFlags to make it more easy to add new body types (which we wanted to do with e.g. BODYFLAGS_GROUNDSTATION)
• 5.1: Why should positioner be informed about which body it is attached/detached to? I imagine we just fetch the position vector of whatever time we want and that's it ^^
• 5.1: I am confused as to what some functions do. Can't get_translation be derived from get_state? What is get_state_vectors doing?
• 6.1: Same question: Why should rotator be informed about which body it is attached/detached to?
• 7.1: I'd recommend giving IVBodyGeometry no assumptions about the shape of the object, at most a mean_radius. A polar_radius and extend_radius sounds like something that you might want for planets only.
• 11: You can directly override the _init function of body here if you want to enforce people to use that specific interface (which I would recommend at least for name, flags and gravitational parameter). I am not sure why there is a existing_body parameter, though.

My answers to 13, in case you're interested in a second opinion:

• Q1: Keep the already used names (IVPositioner, IVSurfaceAnchor, IVRotator, IVBodyGeometry). Only in IVBodyGeometry, people could confuse it with actual meshes for rendering or physics interaction, maybe IVBodyShape is a better name.
• Q2: Not sure if question understood correctly, but yes, I would keep this a family to make it easier to extend it with custom behavior.
• Q3: I would retire the bits, because other options allow for more flexibility.
• Q4: For now, I think it's fine to keep them combined, but in perspective, I would recommend splitting them into independent components.
• Q5: No opinion.
• Q6: I have ideas, but I think they're too young to paste them here. :)
• Q7: Since this is a massive rewrite already, I would go all the way and remove orbit.
• Q8: No opinion, though it sounds nice.
• Q9: I think that these can stay in IVBody.
• Q10: No opinion/Not sure what these do anyways :D

14: Regarding network sync. Out of curiosity: What are you aiming here at, adding and removing bodies during runtime? Otherwise, network sync would only require syncing the time, no?

Hope that the input helps and feel free to ask questions and get into a discussion here!

[charliewhitfield]

I'm still meaning to go through your points in detail. Meanwhile...

Three new docs might answer some points or change your thoughts (or raise new concerns):

• PHYSICAL_MODEL.md
• VISUAL_MODEL.md
• PHOTOMETRIC_MODEL.md

Also, IVBody_REDESIGN_v0.3 has two new sections 2.3 and 2.4 that you should read. The first lays out the problem, the second is the solution. The fix is not entirely intuitive, but it solves a whole class of 32-bit/64-bit issues that have been the bane of my existence. It also makes the whole solar system an easy "drop in" on top of a standard Godot scene, e.g., a moon base with its own shadows, camera, characters, gravity, collision physics, etc. The key insight here is that a local non-astronomical scene that has the camera has to be the anchor for the world frame. (Otherwise your small scene is moving at astronomical speeds which causes Godot's shadows to boil.) Astronomical bodies are positioned relative to that anchor.

---

Btw, v0.2.1 is coming soon and it is a giant step in graphics. We have real looking atmospheres, correct disc photometry (your proposal), ~2.5 M stars, visible planets at distance as phase corrected stars, and glow. The one addition that seems minor but really makes it look photorealistic is an option for physical light, so a planet and its moons can now be viewed correctly without stars. It's wild to see Jupiter and the Galilean moons as glowing crescents on a black background. (The camera has auto and manual exposure with EV feedback, so you can see how far below detection stars really are when exposing for a lit planet surface.) It's probably way too real looking for game developers so it's an opt-in to enable it.

[andreasfranke1]

Hey there! Just as a heads up: The newest planetarium version looks nice, but I am experiencing massive performance issues with the planet shaders (even when reducing the settings to lowest possible)...

[charliewhitfield]

I'm working on fixes for that in v0.2.1. There are 6 or so new graphic options that have a big effect (the AA options are pretty moderate in effect), plus other optimizations. This is all tracked in GRAPHICS_PROFILING.md.