Roadmap

[charliewhitfield]

This is a work-in-progress todo list for I, Voyager. The list will evolve over time, and I'm happy to discuss possible additions. If you wish to contribute, please let us know what you are working on. I'm eager to see our first contributor pull-request!

This list does not limit you! If you want to contribute something different that you think would be useful to others, please do make it and post in FOSS Tools & Addons. Also feel free to discuss any projects at any stage, free or otherwise, in Projects.

[2023 August Update] Migration to Godot 4.x is underway! Go here to track progress. After the 4.x migration, our API will stabilize as we move on to betas and then "v1.0" release.
[2023 November Update] The Godot 4.x migration is really done. I'm just waiting for Godot 4.2.official with HTML5 export fixes before calling it official. It looks like we have a working web Planetarium now using 4.2 betas: link.

Things I consider priorities, but I'm either not doing or can't do by myself (we need contributors!):

• Make "level design" in the editor possible. This hasn't happened because all of my own design is via data tables. The IVBody class and all of its associated objects would require major work to export properly for the editor. See discussion here.
• Fix the Shadows Bug. Someday. It's issue number 1 (literally) dating back to early 3.x versions. I've gotten nowhere after countless hours... fixed!

Things I'm working on:

• Ongoing... Write and improve documentation comments.
• Add an assets loader that manages ivoyager_assets directory version and downloading. [It's in v0.0.18!]
• Restructure "ivoyager" (the 3.x core submodule) into a set of Godot Editor plugins: ivoyager_core, ivoyager_table_importer, ivoyager_tree_saver. [Done in v0.0.18!]
• Support for multiplayer. We only need to sync IVTimekeeper and IVOrbit instances, and the latter only when one gets a "thrust" applied to it. Otherwise, everything is determined.
• Ability to select and visit explored asteroids. [Partly done. Some visited asteroids are in. All 78,000+ display their name on mouse-over of the asteroid point or orbit line.]
• Stand alone "apps" for the Planetarium for various platforms with digital sigs and self-updaters (probably using Electron, but I'm not sure). [Even better: We got a Progressive Web App with v0.0.10!]
• User can select whether camera tracks with body orbit (as it does now), ground (constant latitude, longitude) or neither. [released in v0.0.7!]
• More componentization of Body: Atmosphere, Gravity, Composition, etc., that go alongside existing components Orbit, Model, etc. A spacecraft, for example, is just a Body that has some of those components but not others. [Partly done but more components are likely...]
• AsteroidPacker addon. This is what turns source data into the asteroids binaries. It's currently repository asteroid_importer, but doesn't work with current versions. It'll be renamed "asteroid_packer" and polished up a little. Done! See ivbinary_maker.
• Fixing errors in 3RD_PARTY.txt and possible clarification elsewhere on our website. This is mainly a concern for commercial projects: specifically, some of our "maps" are of ambiguous provenance. These were made by various space enthusiasts mostly in the '90s and ended up at NOAA ftp sites, with no attached copyright info. (All could be remade from public domain NASA images, if it comes to that...) done in v0.1!
• Ability to select an asteroid/comet/whatever from a point-graphic on the screen. The 48,000+ asteroid points are positioned by the GPU. Godot 4.0 will allow us to communicate those coordinates back to the CPU so you can select individual asteroids with a mouse-click. [Done! I coded some pretty wild shader magic to do this in v0.0.14.]

Ongoing improvements. I may get around to any of these at any time. But progress more likely depends on contributors:

• An AI assistant named "Galileo" that can navigate around in the Planetarium. This would be fantastic for accessibility.
• Ephemeris orbit updating for Planetarium. An option in the Planetarium could allow ongoing updates to orbits using ephemeris data from the Horizons System. Queries should be lazy (only get what's needed) and cached within defined time blocks. This would put ISS, Juno, etc., at true locations with current orbits, and make events like eclipses much more accurate.
• An online class wiki for developers! It's possible to export class documentation (from ## doc comments) as an xml file using godot.exe cmd line functions. The hard part is converting that xml into markdown files (or other format) supported by GitHub wiki pages, with all the correct web page links. It's too bad there isn't a generic Godot plugin to do this.
• More graphic effects: atmosphere, shadows(fixed), maybe a little sun flare, etc.
• A planet rings shader for Saturn! Some resources for that here. [Done! v0.0.14]
• For the Planetarium, an "astronomy sky mode". A long time ago I tried adding an "outward" camera view but it wasn't useful for astronomy since the user had no reference to orient themselves.
• API for orbit perturbations. Our "orbits-on-rails" system (as some call it) uses Keplerian orbit elements as its internal coordinate system, with rates or modification of these elements to represent common, well-understood (and extremely well-approximated) perturbations that occur due to n-body effects and non-spherical planets. * * We are using this already for orbit precessions, but currently, the values (for precessions: Ω-rate and ω-rate) have to be given. We need code to calculate these given a Body in a particular environment. The formulas exist for most situations one finds in our solar system including oblateness of planets (allowing things like frozen orbits) and Lagrange points (which give tadpole & horseshoe orbits).
• A shader-based starmap. The starmap looks OK -- until you narrow the field-of-view, then it looks terrible! Surprisingly, there are only ~10,000 visible stars, which is 1/6 of the number of asteroids we show (quite easily) even in our web deployment. So we should be generating stars in a similar way. Magnitude, color & position of stars would be in binary files similar to our current asteroids. (We may or may not have PanoramaSky for diffuse effects, but I suspect these should be shaders too.)
• Barycenter mechanic. We'll probably use only for Pluto-Charon where it gives obvious visual improvement.
• Comets!
• Nearby star systems with known or probable exoplanets. (I, Voyager is already built to handle multi-star systems.)
• Models for non-fictional spacecrafts. Priority would be those exploring the the solar system -- Voyager 1 & 2, New Horizon, Juno, etc. -- but maybe also Earth-orbiting Hubble, ISS, etc. [Partly done: We have ISS and Hubble]
• Some kind of dynamic loading mechanism for close-up planet views. I'd like to be able to replicate the view one would have looking at Earth when zoomed to the ISS.
• API for astronomical navigation. E.g., get_hohmann_transfer_orbit(), etc.
• More as I get to it...

Not specifically a priority (for me), but I'd love to have in official I, Voyager...

• VR.
• "Interpretive" completion of world maps for Pluto and the half-imaged moons from Uranus outward. This would be appropriate as an addon feature.
• "Interpretive" small bodies: procedurally generated asteroids, comets and small moons. I forgot where I saw it, but there is a database somewhere with current best estimates of the shape of real small bodies based on long-distance images. It would be nice if we could incorporate this even if the detailed shapes and textures are fictional.
• Fully procedural star/planetary systems.
• Support for "special case" n-body effects. It's a complicated discussion, but we don't do a full n-body simulation (see comment "API for orbit perturbations" above). But there's no reason we can't simulate individual special cases this way. For example, a rogue planet tearing through the system...

[croxis]

For the starfield, I've written an implementation using the HYG catalog you are welcome to use: https://gitlab.com/godotuniverse/starfield.

[charliewhitfield]

For the starfield, I've written an implementation using the HYG catalog you are welcome to use: https://gitlab.com/godotuniverse/starfield.

Thanks! I had forgotten even where I saw the star data. I'll probably want to crunch a subset into binaries the way we do for asteroids.

Btw, I noticed you used 1 Godot unit per parsec. We used to set 1 unit per 1e13 meters (or something like that) to not break Godot. However, at some point in 3.x development that became no longer necessary. We now use 1 unit per meter and it works fine at solar system scale. I don't know about galactic scale though...

[croxis]

I thought about using a binary format. If I expand into the Gaia dataset i probably will. Even though 1 unit=1 parsec, I set the depth to 0.99999 so it always renders in the background. I have my local solar system scene as normal (still need to compile the engine for doubles), and then change the position in the Star field node in code if I have any big movements. Example here: https://gitlab.com/croxis/itf/-/blob/main/systems/test_system/test_system.gd

…

On Mon, Mar 27, 2023, 5:50 PM Charlie Whitfield ***@***.***> wrote: For the starfield, I've written an implementation using the HYG catalog you are welcome to use: https://gitlab.com/godotuniverse/starfield. Thanks! I had forgotten even where I saw the star data. I'll probably want to crunch a subset into binaries the way we do for asteroids. Btw, I noticed you used 1 Godot unit per parsec. We used to set 1 unit per 1e13 meters (or something like that) to work at all. However, at some point in 3.x development that became no longer necessary. We now use 1 unit per meter and it works fine at solar system scale. I don't know about galactic scale though... — Reply to this email directly, view it on GitHub <#5 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAA5V5YDI4VN6BH7TBSY4IDW6IYXFANCNFSM6AAAAAAWHVNMDM> . You are receiving this because you commented.Message ID: ***@***.***>

[0xIonRod]

Happy to help with the port to Godot 4.1, how could I contribute?

[0xIonRod]

I've spend half a day converting the code and managed to run it, however it shows black screen.

The project is really great, however the core contains code for a lot of things like GUI and orbital mechanics calculations. Have you ever thought of splitting it into several subprojects?

[charliewhitfield]

Well, I’m at the top of Newfoundland (St. Lunaire) in sight of several large icebergs, but starting the long drive south tomorrow. Happy to discuss code architecture changes in depth if you want. Note that GUI is added by the extension project (planetarium.gd or replace_me.gd), so the whole GUI Control scene can be detached. I’ll be more helpful around 25th or 26th.

[0xIonRod]

Amazing! I'll make a deep look into code and will come with ideas.

Basically, gd-plug is a nice working and maintaned package manager for Godot.

I was thinking of moving things like csv file importing to a separate project as well, thou I still need to deeply familiarize myself with the code, before I'll be able to propose something specific.

I'll be happy if we could jump on the call at your convenience

[charliewhitfield]

Might be good to have two separate discussion threads for the 4.x port and subsequent architecture changes/improvements. Feel free to start that if you want.

(I want to port before any other work, and don’t plan any further support for 3.x.)

[charliewhitfield]

@Difint, I opened a new thread for the migration. I'm reluctant to cut off a potential contribution, but I'm thinking that I need to do this myself from scratch. Each system needs to be migrated, tested and debugged in isolation (table loading, etc.). I'm afraid I'm the only one that knows these systems well enough to do so.

[mbgaron]

Models for non-fictional spacecrafts. Priority would be those exploring the the solar system -- Voyager 1 & 2, New Horizon, Juno, etc. -- but maybe also Earth-orbiting Hubble, ISS, etc. [Partly done: We have ISS and Hubble]

I used this as inspiration to dust off my Blender skills. I now have a modeled Voyager 1/2 (not textured yet) and am working on a Tiangong. There will be some new assets to add to iVoyager when you get back from The Rock!

[0xIonRod]

Will do! I expect to review the code by the end of this week, and once it's done I'll make a new Discussion with my ideas. BTW we are also in touch via Twitter ------- Original Message -------

…

On Monday, July 17th, 2023 at 8:08 PM, Charlie Whitfield ***@***.***> wrote: Might be good to start two new discussion threads for the 4.x port and subsequent architecture changes/improvements. You can start that if you want. (I want to port before any other work, and don’t plan any further support for 3.x.) — Reply to this email directly, [view it on GitHub](#5 (reply in thread)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AYITIZKOPWGLMOZNCTXDEFLXQU2N5ANCNFSM6AAAAAAWHVNMDM). You are receiving this because you commented.Message ID: ***@***.***>

[charliewhitfield]

I should post here so it looks like I'm doing something...

Our major restructuring into a set of Godot Editor plugins was mostly done in v0.0.17. In v0.0.18 I'm currently splitting off the system we use for saving the procedural tree into a gamesave file and rebuilding it on load. See new repository ivoyager_tree_saver.

I built the asset loader in v0.0.18! No more manual download. The ivoyager_core plugin will prompt you and do all the work.

I added new item to the list: A class wiki for developers! The idea is to document everything using the new in-editor doc system, export as xml, convert to markdown pages, then add that to a new GitHub wiki pages. (The hard part is the "convert" step.)