Now you can observe real solar and lunar eclipses in SpaceEngine! This video shows the upcoming full solar eclipse of August 21, 2017, which will be visible in the USA.
Over the past month I have worked on planet ephemerides. They are data tables and pieces of code, which provide the precise positions and velocities of the Solar system’s planets and moons at a given moment in time. Previously, SpaceEngine used Kepler orbits – they are a good approximation of the motion of a planet around the Sun (or of a moon around a planet) without any perturbations. But the real Solar system is not so simple, we have multiple planets and moons which pull each other with their gravity. This perturbs their orbits, making the Keplerian solution inaccurate. The most significant perturbations are applied to the moons, as you can see on the video below – their orbits precess and wobble.
To predict the movement of planets and moons, astronomers use N-body integration running on supercomputers. They make observations to derive initial state vectors (coordinates and velocities) of all major Solar system bodies (the Sun, planets, moons and hundreds of major asteroids, and even an analytical model of Saturn’s rings), and run a simulation, similar to those you can run in Universe Sandbox. But unlike the game, the scientific simulation is very precise and takes into account various subtle effects, such as the non-uniformity of the gravitational potential of oblate planets, mascons in the Moon, and relativistic effects. The simulation is run to hundreds or thousands of years in both directions – in the future and in the past. After completion, we have large datasets, which are not very convenient to use. So astronomers derive an analytical solution, which approximates the obtained results with some accuracy, or build smaller data tables and provide and formulae for interpolation between data points. Sometimes it is possible to create a completely analytical model, with parameters fit by observations.
Plenty of such solutions (“theories”) for the movements of planets and moons exist: VSOP87, DE405, TASS 1.7 etc. They are used to calculate object positions, predict eclipses, and plan space missions; they are also used in various planetarium software. From our perspective, we can subdivide them in two categories:
To date, I implemented these theories in SpaceEngine:
Outside of the valid timespan of the orbital theory, SE uses extrapolation. It takes the first or latest coordinates and velocity vector of the body generated by the model, and constructs a simple Keplerian orbit.
There are many other theories, including alternate theories for these major bodies, and theories for minor moons. I will add some of them to SE later. Note that the VSOP87 theory doesn’t include the Moon, and the only Moon theory implemented for SE so far is DExxx, so the next version of SE will be shipped with the DE436 data file (nearly 100 MB). In the future I plan to implement the ELP2000-82 theory of the Lunar orbit, so SE could use VSOP87 for the major planets by default (it has no large data files, and much larger valid timespan than DE436). It has a more modern version – VSOP2013, but it requires several 300 MB-size data files.
I implemented support of all JPL ephemeris data files (DExxx), which could be downloaded directly from their FTP server. It includes the incredible DE431 solution for the planets, the Sun and the Moon – it has a huge timespan of 30,000 years (from year -13,200 to 17,191), but its data file is 2.6 GB. SpaceEngine should work with it, but I didn’t test it; it could crash because of lack of memory (currently SE loads the entire file to RAM). The available files on the JPL server stop at DE431, but in upper folders there are files in ASCII format and the tool asc2eph.f which can be used to convert them to a binary format supported by SE (you have to install the Fortran compiler to compile and run it). The JPL server also has data tables for hundreds of asteroids, as well as for all modeled moons, but their summary size is many tens of gigabytes – I think this is redundant for SE.
I also implemented custom rotational models for planets and moons, based on a document from the IAU Working Group on Cartographic Coordinates and Rotational Elements (WGCCRE). They model precession of the polar axes of bodies, as well as tiny periodic perturbations, and are valid only in a limited time span, like orbital theories. The Earth’s precession is not modeled there, it needs some other analytical model. The Moon’s rotation is also modeled by the DE436 solution, so we have two options here.
In order to support custom orbital theories, I had to change the way orbital lines are rendered in SE. Previously, a “mesh” is generated for each body; its shape and size depends on the orbital parameters. But then I realized that because all Kepler orbits are just conic sections (ellipse, parabola or hyperbola), they can be rendered by just three different meshes with appropriate scaling and shifting – circle, parabola and hyperbola. This is a very fast solution, because now I can use instancing to render thousands of orbits, save memory and loading time (no need to generate and store thousands of meshes). Updating of changing orbits in real-time (those analytical models and also ships orbits) costs no performance now, because there is nothing to update – just compute new scale/shift values.