I, Voyager is in beta!
Try our beta Planetarium! And please give us feedback at our Forum!
What does “beta” mean for us? I’ve bumped each of our two main project repositories (Planetarium and Project Template) and our four Godot Editor plugins (Core, Tables, Units, and Save) to version v0.1. That’s a big milestone! Practically, it means that our API is mostly stabilized (more on that below) and our code is realistically usable by other developers.
Our API is now generalized to support any orbital system(s), even if our own projects are focused currently on the Solar System. See About and Developers if you want to help make I, Voyager into a better space simulator. Or, if you need to insist “This is not a space simulator!” you can engage with us on X. (Srsly, we need the boost.) We’re also at Facebook and about to start posting at Bluesky.
Shadows (finally…!)
Visually, our biggest recent advancement has been to get shadows working. These are visible now at vastly different distance scales, from the rings of Saturn to small spacecraft. And we even have semi-transparent shadows!
Unfortunately, our system doesn’t work using “Compatibility” renderer, so shadows aren’t present in HTML5 exports. It works using “Forward” renderer so should be available for most projects.
Orbit code and orbit “simulation” roadmap
Our simulator uses orbital elements rather than Cartesian coordinates at its heart (the heart being IVOrbit and small-body orbit shaders). Essentially, our coordinate system is p, e, i, Ω, ω, T₀, μ rather than x, y, z, vx, vy, vz. This means that 2-body (spherical) gravitational dynamics are perfectly accurate forever. Perturbations from 3rd-bodies, non-spherical bodies, and other sources can be applied in whichever coordinate system is most convenient, using coordinate-swaps when needed. Well… that’s where we’re going anyway. This makes implementing simple things like rocket thrust more difficult. On the other hand, implementing a Sun-synchronous orbit is easy — it’s simply a constant Ω-rate! The goal is to make all of this under-the-hood so developers can call apply_thrust() without worrying about it. That’s in our roadmap with a lot of implementation detail already laid out in IVOrbit design and documentation.
We’re really developing two different systems for two different use cases: 1) An accurate replication of the Solar System. This if for applications like our Planetarium and involves mechanics that aren’t needed for typical games and not used by default (e.g., IVRealPlanetOrbit; perhaps we will even implement Ephemerides). But also: 2) A more free-running, anything-can-happen, simulator. This will involve heuristics and selectively applying 3rd-body and other perturbations as needed. It won’t be JPL. But it will do things like orbital precessions and Lagrange points (these exist already but we need code to apply them “on-the-fly”), and also respond reasonably accurately if suddenly there is a rogue planet zooming through the Solar System.
After a few redesigns, we settled on our orbit-defining elements as p, e, i, Ω, ω, T₀, μ so we can support parabolic and hyperbolic trajectories using mostly the same code. Other elements are available but derived. These can now be changed in the editor at runtime…
Code modularity and scene tree construction
For developers, the biggest recent changes are about code modularity and scene tree construction. This is especially helpful for GUI building. We now have 47 GUI widgets — from a simple date/time label to a planet/moon navigation widget that builds itself from simulator content. They mostly just work when added to a Godot Container. Some do require context. For example, “selection” related widgets expect to find an IVSelectionManager somewhere in their ancestry tree.
The physical star(s), planets, moons, etc. (IVBody), and their orbits (IVOrbit), are only constructable via data tables. That’s an historical artifact of simulation development: it was easier to build a data table system than to set 10000s of body and orbit parameters in the editor by hand. It’s in our roadmap to make these also constructable in the editor so “level editing” is possible. I’d really like to have a two-way system where we could build or update data tables from the editor, including from code-generated, fully procedural star systems.
Class documentation
Class documentation is ongoing but completed in many classes, including several documentation “entry points.” These are best viewed from within the Godot Editor, but here are repository links:
- IVUniverseTemplate for scene tree construction.
- IVCoreInitializer & IVCoreSettings for Core plugin init & settings
- IVGlobal & IVStateManager for runtime state management.
- IVBody for the physical 3D world.
- IVOrbit for orbital mechanics.
When will v1.0 be released?
The plan is to stay in “beta” until we have significant external usage and feedback on our projects or specific plugins. Please do let me know in our Forum if you are using these in your own project development. There will be less API breakage in beta development than before (especially compared to the immediate run-up to beta). But I’ll certainly calibrate this depending on external usage that I know about. When developers have given feedback and think it’s ready, we’ll move on to more stable v1.0 releases.