Solar System Simulation

This project was for our implementation of physics in a real-time application. I attempted to create a realistic simulation of our solar system using a custom implementation of the laws of motion (i.e. not using Unreal’s AddForce()) and a few numerical integration methods to try and keep the simulation stable. The simulation also makes use of Kepler’s orbital elements and the real world values of each of our planet’s orbits to make the simulation accurate. It is not a true N-Body simulation – gravity is only calculated between the Sun and the planets.

Sol, Mercury, Venus, Earth and Mars

The simulation includes the 8 major planets of our solar system (sorry Pluto, you don’t have a good texture I can download anywhere), all of which orbit at (close to) their correct orbital paths, velocities, and periods. The motion of each planet is affected by the gravitational pull of the sun. In reality, each planet would also be affected by the gravity of every other planet, but I omitted this from my simulation because the exponential increase in computation didn’t seem worth it for a minor effect.

You can fly around the solar system using Unreal’s standard fly cam controls, and you can adjust the camera speed using the scroll wheel. Clicking on a planet will reveal several planetary and orbital properties, including the object’s mass and radius, as well as it’s major and minor orbital axes, the current distance from the primary, etc.

Jupiter and its properties. All values excluding mass, radius, and tilt are calculated, not predefined, and align pretty closely to the planet’s real-life orbital values defined here.

It’s not possible – or at least, very impractical – for the simulation to be perfectly accurate due to the astronomical magnitudes of the numbers involved, such as the mass of each planet, the gravitational constant (a very tiny number), and the distances of our solar system – 32-bit floats just can’t deal with the difference in magnitude very well. 64-bit doubles might, but flying for literally hours at light speed within the simulation to reach Neptune would be a poor user experience. Therefore, I’ve had to scale the solar system down to sensible values (planet masses range up to the thousands, not octillions, of kilograms, for example) and increase the strength of gravity so that it’s still felt with such (relatively) small masses. Nevertheless, the calculations hold up, and the solar system behaves like it really does – if you really wanted, you could sit and wait a full year for Earth to complete its orbit at 1x simulation speed. Speaking of which, the time slider at the bottom lets you speed up the simulation, so you can watch the planets zip around the sun up to 10,000,000x faster than they normally would (though beyond 1,000,000x does damage the simulation – more on that later).

The drop-down menu allows you to change between 3 integration methods, which essentially changes how the simulation is calculated (again – more on this later). It’s interesting to see how each method affects the simulation. The reset button restores the simulation to its initial state, placing all the planets back in their default positions.

Earth is the only planet in the simulation with a separate scrolling layer for its clouds.

The 8 planets use textures downloaded from here, and Earth actually uses a separate scrolling cloud layer. The appearance of the sun and stars is done entirely procedurally with Unreal’s materials. The sun’s material is composed of two scrolling gaussian noise textures layered on top of each other, one with a large scale and the other a small scale. This gives the surface those big variations in colour. The self-illumination is also cranked way up to give the sun its bright glow, and on particularly bright spots, the glows really shine and do a pretty decent job of emulating solar flares. The stars work by generating UV cells and choosing a random spot within the cell to become a star, feeding the distance of the random spot from the centre of the cell into its own scale, but really I just followed this tutorial.

The light that each planet receives is also done using a basic lambert lighting material. Unfortunately, placing a point light where the sun is and cranking up its brightness and falloff radius wasn’t good enough – over these large distances, the point light is simply too weak, and cranking up the camera exposure helps to light up the further planets at the cost of making the inner planets blinding (I suppose this is pretty realistic, but again, not a great user experience).

Finally, each planet leaves an orbital trail so they can easily be located and identified at a distance. The trailing affect is a basic ribbon particle which uses a solid gradient material. The size of the ribbon is calculated using a logarithmic function and the distance between each planet and the camera. The logarithmic function basically means the size of the trail doesn’t grow much bigger the further you get away, but when you’re very close, shrinks to almost nothing. This is perfect for this situation – when the camera is far away, the trails all look pretty similar to each other, and when you approach one planet, the ribbon shrinks away and doesn’t obstruct the planet itself.

Leave a Reply