Future Ideas

historyking

Thought I would get this thread kicked off as there are going to be many, MANY updates and ideas for the future of this project. 

Anyways, I would throw in my two cents by stating that one thing I would like to see if maybe some sort of audio clips for those who might be sight impaired that might not be able to read the text, yet still want to hear a synopsis of a planet, star, moon, etc.

Charlie W

@historyking, That's a great idea!

The planetarium has a WikiBot that grabs the top section of the Wikipedia page. Since there will be 1000s of bodies with wiki entrees, we would need a robot to read all of them. Perhaps instead (or in addition?) we should write custom text (w/ real human voice) for the largest and most interesting bodies...?

I've been puzzling over the Wikipedia licence page to try to figure out if this feature is allowed in commercial projects. Wikipedia is broadly under GPL licence so ok for non-profit. If it's not allowed in commercial, I'll pull it out to be a separate addon so developers don't get confused. This might be further reason to write custom entries for major bodies. (Also, the wiki is a little dry...)

EDIT: My understanding now is that a Wikipedia excerpt will be perfectly OK to distribute in a for-profit project (including a voice reading). Based on private messaging it seems we will have a voice wiki excerpt and/or a shorter voice intro to major bodies, perhaps quite soon after initial release. 

Charlie W

I, Voyager VR anyone? (I don't have any VR equipment to attempt this now. But it would be cool!)

mbg

(I don't have any VR gear, but it looks like Godot itself is making strides in that area.)

Is there a feature roadmap for I, Voyager? There are a few far-flung ideas I have for my project, and those inspired by other software such as Celestia and Universe Sandbox, which might be worth planning in or ruling out ahead of time. I know you're already working hard, and these are pie-in-the-sky features from long-established projects, but I figure if it's worth breaking stuff to get to beta, it's worth breaking good and proper

8K Textures

Celestia recently moved to a dynamically-loaded tiled texture model when the player zooms in on a specific body, but it still cuts down on Celestia's performance quite a bit when going to 32K or 64K tiles. Going from 4k to 8k could be feasible IMO, maybe even with a 16k "advanced graphics" option.

Earth and Mars Snow Cover/Ice Caps

NASA Blue Marble - snow cover month to month, night lights, displacement map/normal map, gloss map

I was thinking to filter out the snow from the images above to create a separate texture that could be overlaid onto any generic ground texture. The combined snow cover/ice cap texture could just animated from day to day or every couple of days, swapping out every 12 hours between day and night to hide the transitions. There are also some good images from which to make normal maps and gloss maps for the water.

Weather

EUMETSAT - animated weather map (filtered from footage or constructed through visualisation packages or Data Tailor)

I'm also considering filtering out the weather from a few days out of the EUMETSAT "A Year of Weather" videos, or possibly trying to render a generic simulated weather texture in Blender. Weather textures would look best if they were updated every 30 minutes (current resolution of EUMETSAT's observations) (faster for lightning storms) and possibly cast shadows on the ground.

It would be easy enough (if somehwat time-consuming) for me to make two or three 'tiling' textures each for the following weather patterns:

-24h "boring uneventful weather"

-24h tornado (build-up to funnel to dissipation)

-1 week Caribbean hurricane

-1 week African/European hurricane

-1-week Pacific typhoon

-24h thunderstorms w/lightning (two or three per continent, day and night) (these could potentially even be overlaid on the cloudier parts of the 'boring weather' textures)

Other Atmospheric Phenomena

-meteor showers

-aurorae

-dust storms on Earth and Mars

-volcanic activity on Io

Eclipses

I noticed, when taking a close look at Luna and Io the other day, that orbital bodies don't eclipse each other. I suspect this is indirectly due to the CENTER_ORIGIN_SHIFTING trick. You mention in the scale problem thread that you are planning to overhaul the scale system. Will that make it easier to implement eclipses, or is there something else going on?

N-body Pseudo-Simulation

Your "orbit on rails" solution makes perfect sense for I, Voyager's planetary orbits. But I was thinking to have Children of a Dead Earth-style ship navigation in my project, which would involve "cheating"an N-body physics implementation along the lines of Universe Sandbox's solution. Should I just do that in my corner of my own add-on, or would there be a broader interest in such a module for other applications within I, Voyager or other add-ons?

Just a wishlist of long-term features.

Charlie W

I definitely want atmospheric effects and Earth city lights in the core assets. Changing clouds too if there is a good way to do it. Dynamic higher res images will be something to experiment around with. We already have "ivoyager_assets" and "ivoyager_assets_web" and there can be more along these lines. The code is somewhat flexible in the way it looks for assets, and it can be made even more so.

Yeah, I don't know why we don't have shadows. I wish we did. I've gone in several times to solve this and then got distracted by something else...

So, n-body, and real-world non-spherical effects, etc. Well, I've been saying "orbits on rails" as a bit of a deflection. I've collected a couple 1000 page tomes (e.g., Fundamentals of Astrodynamics and Applications, 4th ed.) which I sometimes press against my head in an attempt to internalize orbital mechanics. In fact, what we are doing is just a different coordinate system. It's not more or less "on rails", tbh. It's just a coordinate system that happens to be more convenient in some ways and less convenient in others. So instead of x, y, z, vx, vy, vz (& time), we have a, e, i, Ω, ω, M0 (& time). In our coordinate system, it just so happens that things do a simple (unperturbed, 2-body) orbit if you leave them alone (in the same way that objects in euclidean coordinates travel in a straight line if you leave them alone).

However, use of orbital elements as coordinates doesn't preclude full n-body simulation. It just makes it not-necessary for well-understood perturbations. We already can make a sun-synchronous orbit by simply giving a delta Ω-rate of 360°/yr. You would need a very powerful computer to capture that accurately with F=ma updates in euclidean coordinates. Similar argument for Lagrange points, tadpole orbits, etc. The math for those is hairy indeed, and involves conversion into yet more coordinate systems (rotating frames). But mainly it involves pushing a, e, i, Ω, ω, M0 around in various ways.

Obviously, firing a rocket is easier to calculate in euclidean coordinates.

So, the big question is how to implement a spaceship. My thinking right now is that it is just a coordinate switching problem. The Orbit class provides conversion functions. Use them! Then let Orbit carry you on your current geodesic. Let Orbit do the heavy lifting, and don't worry that it runs internally on a, e, i, Ω, ω, M0 coordinates (who cares? that's under the hood!). (Well, we're not quite where we need to be yet. For example, I don't know how to calculate Ω-rate given a particular orbit around a particular not-quite-spherical body. But I know it can be done with some pretty good approximations.)

Charlie W

A roadmap is also a good idea. I'll start a thread after the next release.