Making Semi-realistic 2D Solar System

Hi,
First I want to say I'm a beginner user of Unity and C#, so if there are any viable tutorials for the questions I ask, please direct me to them.

I'd like to make a 2D (all objects are in 2D) model of our Solar System which should be somehow realistic in appearance.

By semi-realistic I mean I don't need 100% accurate model, but some real life conditions should be applied:
- objects orbit around Sun which is center static object.
- moons and various object orbit around their parent object (e.g. Moon orbit around Earth)
- objects moves with real life speed (e.g. Earth make one orbit in one Year)
- orbits and objects should be same size as in real life (or scaled accurately, if Unity is not capable)
- entire model is chained with real life calendar, where I pick up a start date, e.g. 1st January 2020 and then entire model run with configurable time compresion (e.g. 1m, 1h, 1d, 5d, 1m, 1y)
- for simplicity orbits are cicular for most planets
- one hard pickle is Pluto with it's Ellipsoid orbit

- because above real scale condition even biggest planets would be tiny when looking at entire Solar System, so at certain camera distance accurately sized Planet objects should be replaced by planet GUI icon for better visibility.

I guess that for a basic prototype I'd need:
- Sun (static, in the center of entire model)
- Earth-Moon (Circular orbits for both)
- Pluto-Charon (Ellipsoid orbit of Pluto and circular orbit of Charon)

In the end I aim for full system from Mercury to Pluto with all main moons, plus some dozens of minor objects like big asteroids - therefore between accuracy and performance, I'd favor performance, so that model could handle larger amount of objects without some heavy calculation.

Could someone guide me with creation of such model?

 

My suggestion would be layering, starting from the Sun at the base. Each planet would have a parent element that would sit underneath the Sun. On each of these elements, you can put a base line script that handles rotation, making that value (rotationSpeed, would be a good option) public. This script would be configured as you set the children up, giving each it's accurate rotation value, per the timeline you're after.

Similarly, moons of planets would have the same setup, but instead of their origin point being placed at the Sun, they would be placed on the planet, and be children of the planet. This would be a pretty simple scenario for standard orbits, but would have to do special math for the Ellipsoid orbit.

 

OK this seems like a good start.

I mashed up something like this:


https://imgur.com/lzvj4zL

However when I toy with rotation of a parent object it seem Earth rotate along (the "North" is rotated along with orbit rotation):


https://imgur.com/vBVTBF9

Is it possible to "switch off" child rotation ("so that "North" always point "up" no matter the orbit rotation)?

 

will this work ? Add to th earth object

Code (CSharp):

1. void Update () {
2. transform.up = Vector3.up;
3. }

 

Given the scope and intent, I would set the orbit positions up to be deterministic time based (look up parametric equations).
ie. Your simulation starts at time = 0, then you can get the position of the planet at any time t (where t is in your smallest time units, eg seconds/minutes). The simple case is every frame you get the positions of all planets based off simulation time (ie. Add Time.deltaTime to your simulation time count each frame). Time scaling is then just adding Time.deltaTime * timeScale to the toner each frame. (With time reversal subtracting time)

This easily allows time scaling (and reversal) as you can get the position at any time.

While you probably won't need the optimisation, you can also not worry about anything not on screen, as soon as it enters viewing you set the posposit based off the current simulation time. (Also works for moons etc with the parametric equation giving a position offset to the orbited body)
Using an unsigned long integer for the simulation timer will give you 584942417355 years, assuming a time steps in seconds.

I watched this video series a while back that (from memory) addresses it well, might be worth a watch.

 

@MickM:
I think I went with something similar following the tutorial below (It supports Ellipses).

However I think I'll allso check the tutorial you posted, because it mentioned the "real life" distances in the model.
Additionally it seems that YT channel for that video has tons of other interesting tutorials

I think that I have all OP points covered except this two:
"entire model is chained with real life calendar, where I pick up a start date, e.g. 1st January 2020 and then entire model run with configurable time compresion (e.g. 1m, 1h, 1d, 5d, 1m, 1y)"

"because real scale condition even biggest planets would be tiny when looking at entire Solar System, so at certain camera distance accurately sized Planet objects should be replaced by planet GUI icon for better visibility"

Any idea or tutorial how to approach these?



"Using an unsigned long integer for the simulation timer will give you 584942417355 years, assuming a time steps in seconds."

Nice! I'm still undecided, if I will gonna need seconds or minutes as lowest, but for years I think I won't need more than 500 or 1000.

 

That is a good series of videos too from memory. The trio of videos I linked is just a brief overview - just covers the basics and is more geared towards proc gen and galaxy but the underlying implementation is the same.

Points for thought:

Times

If you go down the deterministic orbital path route you can achieve what you are looking for quite easily. Using a freely available source you can have a reference point (eg. http://www.theplanetstoday.com ) and set the initial state of t=0 based off the real locations. From there, assuming your mathematical model of the orbit is relatively accurate, you can put in any value of time (as a time elapsed since your reference point) and you should have an accurate result. As an added bonus, if you go down the signed integer route, you can put in values of negative time to simulate the orbits prior to your reference time. Parametric ellipses are not too difficult and with Kepler's laws you should be able to recreate a simplified parametric model of the orbit for the objects you are simulating.

Astronomical scales are.... astronomical. You will need to render at many orders of magnitude less than 1m to 1 unity unit. The Earth approx distance from the sun is 149.6 x10^9 meters.

I believe the recommended max range from the origin in unity is 100k units? So to fit earth inside the max recommended you will have to scale the down to 1 unity unit = ~1.5 million meters. This will actually have to be increased even further - given Pluto is ~40 AU from the sun it brings out the minimum zoom to ~60 million meters per Unity unit.

There are tricks with moving camera origins etc as well but it really depends on what the actual requirement is. Is this an academic project? Commercial contract? Personal project? etc. In the first two cases you should need to confirm the exact requirements so you know how to best represent the information.

Regarding the visualisation, the only way you could actually show a representative model of a planet while keeping the relative scale is by focusing solely on the planet in question. Any visualisation with multiple planets would end up being a small collection of pixels. The easiest solution that comes to mind is scaling planet images (or replacement icons as preferred) based off the current unity-solar system scale (Manual testing and/or maths will help relate the solar scale to required image scale). This should be clamped to min/max sizes obviously.

 

@MickM:
Thanks for your input. Currently this is just a personal prototype to see what Unity can or cannot do. Eventually, if this works well I might want to make a game with this model, but this is big if and far into the future.
That's why I wanted to know first if realistic scale is possible or I should go with scalling everything from the begining.
Initially I was hoping for 1 unity unit = 1 km, but I see even this is not enough.

As for camera note - I actually have this also listed as a future issue. I plan to have several "levels of view/Camera":
- System View (entire system visible - most of planets would probably be only visible as icons anyway)
- Sector view (view around designated location, e.g Earth-Moon sector, Jupiter sector with moons etc. I think that it would require dynamic scale for each sector as if I fit Earth-Moon in one scale, it might not work/look well when I try to put Jupiter and moons with the same scale)
- Orbital view (designated body view with simplified display of 3 orbits - low, mid, high. E.g Earth, Earth low orbit, Earth mid orbit, Earth high orbit)


I think I'll first focus on 2 things:
- set up scaled model of Solar System with main planets-moons.
- making time management/compresion script.

Do you know any tutorial about setting an efficient time compression manager (something that in future would designate time compression for everything from planet movement, to ship movement, planet production)?
I don't need negative time compresion only forward, something like that (levels of time compresion):
Pause/Stop
1s (tentative)
1m
1h
1d
1w
1Month
1Year


Looking at diffrent "camera views", diffrent time compresions would be useful:
Pluto make one orbit with 250+ years, so seconds and even months wouls be useless here.
However if we jump to Earth low Orbit ISS need 94 minutes to make one orbit.

Seconds seem not so important yet, unless I would want to setup space battle - in real life distance of max 1 lightsecond, ~300'000km, then some things might be useful with 1second time compression.
However on paper, 1m minimal time compression would be good enough.

 

Based on the orbital paths tutorial I tried to set-up the Sun-Earth-Moon.
It went OK and I have Earth orbiting Sun, while Moon orbits Earth.

However I found some issues:
- it seems that Ellipse renderer script doesn't render the Ellipse from center of the parent object, but rather from center of the scene. Thus moon orbit is rendered around the sun. Can you help me adjust the script so that orbit is rendered from the parent object, ranther than scene center(I attached the project like)?
It's probably something trivial, but my basic knowledge seems lacking for this.

Also some minor questions:
- is it possible to render orbit as something else than a line? Like dotted line?
- depending of the camera distance the static orbit line often render too thin (making an impresion that some parts are missing) or too thic. Is it possible to have dynamic line width scalling to camera distance, so that the orbit line is rendered optimally no matter of camera distance?