After implementing constellations, I continued various work on the engine, and support/development of Overview. Most work is technical: finalizing previous work, optimizations, bugfixes. But some may be considered as user-noticeable features:

• Added more error checks for the catalogs loading
• Script command to switch the audio output device (to redirect sound to Rift Audio), audio library OpenAL updated to v1.1
• Command line argument to launch SE in a specified 3D/VR mode (Steam VR launch options)
• Added ability to use super-resolution in VR (VRRenderScaleMax in the config file)
• Ability to change position of labels near planetary and deep space objects (stars, galaxies): left, right, top, bottom
• Graphics settings menu have options to set up resolution of warp and reflection textures, resolution of render buffer for fish eye and 360° projections
• Rendering of various celestial coordinate grids: equatorial, ecliptic, galactic, check boxes in the settings menu
• In the HDR mode star surface automatically become darker on close approach to reveal details
• Fixed positions and/or names of 21 star systems in the binary stars catalog
• New textures of Jupiter and Pluto
• Mini-neptunes have Venus-like clouds texture
• More realistic gas giant's moon system generation: Jupiter-like, Saturn-like and disturbed systems
• Analytical model of orbits of Saturn's trojan moons Helene (trojan of Dione), Calypso and Telesto (trojans of Tethys)
• Analytical model of orbits of Saturn's co-orbital moons Janus and Epimetheus, swapping orbits every 4 years
• "Hide/show object" option in the right-click menu
• Script command to load custom image and put it on top of screen as overlay
• Shape randomization parameters for ray-marched nebulae

This is stunning 14k map of Jupiter made by Björn Jónsson. He merged new images of Jupiter's poles taken by Juno spacecraft with old Cassini map.

This is 24k DEM (digital elevation model) and 24k global b/w mosaic, colored by 6k RGB map, taken from USGS. 24k means resolution of the original map 24000x12000, which corresponds to 300 meters per pixel on Pluto's surface. Of course, such level of detail reached only in some places, the rest is blurred or even filled with uniform color (no data). Maybe someone will make an "art" maps of Pluto, filling the non-imaged parts of the map with some "procedural" pattern. like the Triton map in SE.

Comparison with a famous "Pluto crescent" image from New Horizons:

This is a real location on the Pluto, near the edge of the hemisphere mapped by New Horizons. Terrain model is not very accurate of course, because New Horizons does not have a laser altimeter, and elevation map was obtained by stereogrammetry.

This is useful for making a "comparison with reality" screenshots like one with Pluto shown above. The code below loads the picture, stretches it to fill the screen (with saving aspect ratio), and starts infinite loop which switch between loaded image and SE rendering. It makes easy to compare, align and match images with eye. This technique is commonly used in astronomy to compare two photos of the same part of sky ("blink comparison"): when they are aligned perfectly, any change in object brightness and position became immediately visible.

By the way, I was unable to perfectly match terrain features on SE Pluto with a photo. Probably elevation map and texture is not assembled perfectly. I also was unable to match the horizon line: if match its curvature, terrain features get offset. Maybe this mean that Pluto has noticeable oblateness? Maybe more accurate shot can be made by matching star positions - some stars are visible on New Horizon's photos.

I revisited the code which generates moon systems of gas giant. We have only 4 gas giants to build the theory, but even with such small sample we could do some guesses (supported by modelling). One scenario is a fast migration of moon embryos in the circumplanetary disk around planet, which produces several generations of large moons. Moons are formed primarily in the intermediate, most dense part in the disk. Immediately they affected inward migration and crash into planet some million years after. But another moons are formed instead, because the disk is replenished with a matter inflowing to the planet from the circumstellar protoplanetary disk. When disk depleted, the last surviving moons formed a resonance chain of a relatively large moons with comparable sizes. Real-life examples are Jupiter and Uranus systems. Another scenario is a slow migration: in this case 1-2 very large moons are formed in the most dense part of the disk, and multiple smaller moons in other parts. Real-life example is Saturn system.

In reality some intermediate scenario is also possible. So I implemented a "shape function", which modulates moon mass based on its distance from the planet. The control parameter generated procedurally for every system, in a range from 0 to 1. It produces Saturn-like system if zero, Jupiter-like if one, and intermediate cases in-between.

Neptune have anomalous system, disrupted by capturing of Triton, SE models this also.

Saturn's moon system have six minor moons, which shares the same orbits with each other or another moons. They are:

Telesto and Calypso - trojan moons of Tethys;
Helene and Polydeuces - trojan moons of Dione;
Janus and Epimetheus - co-orbital moons, swapping their orbits every 4 years.

After implementation of analytical orbits (ephemerides) of Solar system's planets and moons, trojan moons are no longer rotated in Lagrange points of their host moons, because host orbits are not simple Keplerian ellipses anymore. Fortunately, there is analytical theory of motion of Helene, Telesto and Calypso - HTC 2.0 (P. Oberti, A. Vienne). And sadly it does not include Polydeuces, because this small moon was discovered in 2004, while theory was developed in 2002. The video below shows movement of Tethys and its torjan companions in the rotating reference frame.

Janus and Epimetheus are unique pair of moons sharing almost the same orbit. They interact in unusual way, swapping their orbits every 4 years, which is greatly described in this article. Such behaviour cannot be represented by a simple Keplerian orbits, but there are some analytical theories. I implemented one of them, developed by Benoit Noyelles. Timelapse video below shows orbital dance of these moons, accelerated 18003373.0883543885 times.

Why 18003373.0883543885? I wanted to use time scale around 2×10⁷ - this speed is good to see evolution of orbits. But at this time scale, Janus and Epimetheus making 5.55 revolutions around Saturn every frame (at 60 fps). So at every next frame they appearing in different points along their orbits, which looks like almost random jumping. So I calculated such time scale value, that moons making exactly 5 revolutions every frame. In this case at every next frame moons appearing almost in the same position relative to Saturn. Slow drift of their positions is due to a slight difference in orbital periods from the fixed value that is used in the animation (5 revolutions per frame). At the first moments, Epimetheus moves counter-clockwise on the animation: this means that it manages to make slightly more than 5 revolutions per frame. Janus, moving in the opposite direction, makes slightly less than 5 revolutions. This means that Epimetheus' orbit is slightly closer to Saturn than Janus'. But when the two moons approach each other, Epimetheus get accelerated by Janus' gravity, moving to a higher (and slower) orbit, and Janus slows down, moving to a lower (and faster) orbit. They start to move away from each other, and change the direction of drift on the animation.

You also may notice that orbits of Janus, Epimetheus and Mimas (smallest yellow ellipse) are quickly wobbles. This is the apsidal precession, caused by non-spherical shape of Saturn (its gravitational field is not symmetric) and gravitational tug with other moons.

It can be used in scripted presentations, for planetarium usage, and widely used in Overview as a script command. For example, you may want to hide Earth to observe the parts of the sky which are currently below horizon (planetarium usage). In Overview it is used for example in the "Planets" chapter. The chapter is implemented using a fake solar system with Mars, Earth and Jupiter in fixed position. The command is called at a certain moments to show Earth and Jupiter. The new right-click menu option was used in the videos above, to hide all dwarf moons except needed ones.

I started work on procedural ray-marched nebulae. First thing what is needed for this - a "safe" way to modify parameters which defines shape, color and other properties of a nebula. There are dozens of them, some depends on each other, some does not allow significant change (otherwise it produces bad looking results or artifacts). The easiest safe way to change nebula shape is just to add a shift to the noise functions used in its model. Short video below shows this in action: a 3-dimensional vector Randomize is added to input coordinates of noise functions, resulting in "scrolling" effect, which changes nebula shape without producing any artifacts. Similar approach is used in procedural terrain generator (procedural planets also have a parameter Randomize).

Next step is integration to the galaxy generator. Ray-marched nebulae model scripts which are currently used for several test nebulae will be changed to "nebula preset" scripts. When galaxy generator spawns a nebula, it will procedurally choose a preset file, instead of choosing an old sprite nebula model, and generate random values for the Randomize vector. For custom (catalog) nebulae, the Randomize vector will be read from the script, to preserve the shape achieved by author of the model.

Discuss this post on the forum.