I enjoy looking at scaled models of the solar system. I've seen many cool example of the solar system created with Tinkercad's 3D editor, and it got me wondering how accurately I could scale down the whole solar system.

As I trudged through, I realized there were a lot of different elements that would need to be scaled, and quickly realized that I would need to decide what elements were most important and which I would skip. One example of something I decided not to include was a planets obliquity to orbit, which would show the angle a planets axis of rotation is off from it's orbit (read more here).

I ended up visualizing: planet size and orbit distance (both measured in kilometer), and for orbits I included eccentricity and inclination. In the following steps, I'll go into more depth on what each of these element represent, and how I went about visualizing them (in both simple and complex manners).

In each of the steps below, you'll see a clickable "project link" that links out to the unique project(s) showcased in that step.

Supplies

Required:

Computer (with internet)
Tinkercad

Optional:

Spreadsheet (to check math functions)
Note paper & pencil

Step 1: Understanding Codeblocks

The first step in understanding what can be done, is understanding what is possible. Additionally, when running into roadblocks, it's helpful to create a new project, break it down to it's most simple elements, and tinker with values to see what's going on.

I started by messing about a bit (project link) to figure out what limitations were imposed on me as well as how Tinkercad handled orders of operations for more complex math problems (which I'll get into later). Some things I found:

Tinkercad can only create 200 primitives.
Deleting primitives will not reduce the total count. Grouping x primitives and copying will double the primitives.
Primitives have a minimum size of 0.1 and a maximum size of 100.
Values that exceed those, will be set to those values.
Scale can alter the size of a primitive to be larger or smaller than min/max input values.
Move can shift primitives using units smaller than .1 and larger than 100.

Step 2: Mapping Values

One of my favorite functions from Arduino is map(). I use it in just about every sketch to translate raw sensor values to something easier to understand.

The map function takes a range of input values, and re-maps them to a user specific range of numbers. I created an example in Codeblocks to fiddle with values, and give myself a reference to check back with.

In the example (project link) there are items 01 through 05, with values ranging from 1,000 to 16,000. Since Tinkercad can't do much with values this large, the first step is to translate them to a usable range. I chose 1 to be my low mapped value, and 20 to be the high mapped value. The only other values we need to know are the input range of values, and the mapped range of values. To figure these out, you just need to subtract the lowest value in the range, from the highest.

The full equation to map values is:

(Item_to_Be_Mapped - Smallest_InputValue) * (output_high - output_low) / (input_high - input_low) + out_min

Seeing as how many operations are happening, the order of operations will be very important, let's dive into that real quick.

Step 3: Order of Operations

Equations are generally built in Codeblocks by combining multiple (0 + 0) blocks.

Each (0 + 0) block is in its own set of parenthesis. So something as simple as 3-2+1, needs to either be entered into Codeblocks as (3-(2+1)) or ((3-2)+1), each of which will give a different answer (animated above).

To showcase the importance of the order of operations, I used the following equation with different order of operations for a circles radius: 25-2*√81+3. Depending on how the parenthesis are arranged, the answer can be 1, 4, 10, or 210. You can play around with it yourself here in this project link.

One other thing to keep in mind with math equations in code, is that variables act like buckets that can be used in their own equations. So I can set x to 15, then update x to x - 5. Since x is already 15, the code will subtract 5 from 15. The new value of x will be 10. You can see an example of this is the linked Codeblocks and one of the images above.

With all of this out of the way, let's start working with real values!

Step 4: Planet Distances

When starting this journey, I imported all the variables I could find into Tinkercad, and couldn't think how to take my next step. After staring at the screen, unsure for several minutes, I decided to step back and make the problem simpler. I would just focus on a single variable, and see how I might visualize that. To start, I pulled out planet distances.

NASA Jet Propulsion Laboratory hosts a reference PDF on their site with average planet diameters (in kilometers) and distances from the sun (in both in kilometers and astronomical units). Since I opted to focus on planet distances, I decided to import just the Km values to Tinkercad, and set up and early version of the mapping function above (project link).

My goal was just to get an idea of how far each planet was from the next, so I laid out the planets from one corner to the opposite to give it as much distance as possible. You can see my early attempt at setting up a multi-step function in Tinkercad, as I was still figuring out how Codeblocks handled order of operations, and this gave me more control. I also created a spreadsheet in google docs so I could put the equation in there for each of the planet distances and verify that math against what was displayed in 3D. Whenever I ran into troubles wondering if my equations where set up correctly in Codeblocks, I would either set up a similar spreadsheet to calculate for me, or past a copy of the smallest and largest objects I expected to see, to make sure something was mapped to each of them (see the reference images in step 2).

Last, since all the planets looked awkwardly similar, I decided to look at images of all the planets to tried to figure out a color to represent each of them, I attempt to stick with these colors throughout the rest of the visualizations.

Step 5: Planet Sizes

Since the PDF from NASA JPL also had planet diameters, I created a new Codeblock to try to visualize those.

I set all of the planets a set distance apart, and just modified their radius based on the mapped scale (0.1 to 100 units). I was quite surprised by the shift in perspective when I shifted the mapped input range from Jupiter as the largest body, to the sun. Since I couldn't find a good way to get both scales in one Codeblock file (without the sun covering everything), I made two (With sun project link) (Without sun project link)

The first sketch shows the sizes of all of the planets and the sun to scale. There's very little difference between the smaller planets.

The second sketch shows the sizes of just the planets, using the same scale as when including the sun, but mapping the largest value to Jupiter. So it would be equivalent to taking sketch with the sun, and scaled Jupiter up to the size of the sun.

Step 6: Planet Orbits & Inclinations

With planet sizes and distances mapped, the next step was putting the planets into an orbit, and thinking about how to alter their orbits in 3D to reflect that not all planets are traveling along the exact same axis. Orbits have an eccentricity and inclination.

Eccentricity is used to show how non-circular or elliptical the orbit is.
Inclination shows how tilted or angled an orbit is in relation to a common plane of reference.

The first step was figuring how to make a circular orbit elliptical in Tinkercad. Looking at this wiki page I eventually figured out a method that worked for me.

Once that was finished, I created a simple view of the orbits (with Tubes), using orbit distance to determine the radius, eccentricity value to represent the height, and the equation I found above to squish the orbit elliptical (Simple project link).

I came back to inclination after getting further ahead as I realized that while setting the height of the orbits to to the eccentricity value shows how eccentric the orbits are, it doesn't take into account how big the orbit is (Complex project link). What I mean to say is that if I use 2 right triangles to represent the orbits, even though Mercury has a much higher eccentricity value then Neptune, with an additional 4.5 billion Km orbit radius, the smaller angle ends up creating a larger rise from base to top of orbit. The image above shows how I calculated the height of the orbit using a bit of trigonometry, you can learn more here.

Step 7: Putting It All Together

With all of the different aspects devised separately, it was time to figure out how to put them all together (project link). In the code image above, you can see I go through the steps of:

Setting the orbit radius, then drawing the orbit (with the smallest possible height and thickness).
Then I set the planet size, and eccentricity.
I apply the eccentricity, then rotate and tilt the orbit based on the Orbit Inclination and the Longitude of Ascending Node (both measured in degrees).
After the orbit is finished, I set the planet to draw, then move it out to match the orbit.
Finally I apply the same rotation and tilt that I applied to the orbit, to the planet, but keep the pivot to 0,0,0 so the planet rotates on the same axis as the orbit did.

When applying move, rotate, or scale it will only apply to the most recently created primitive. I could have created the orbit, then the planet, grouped them, and applied the rotation & tilt just once, but when grouping things in Codeblocks, it seems to make things more complicated, and the draw cycle can often freeze. By leaving out groups, I very rarely run into trouble when playing the build.

Step 8: Resources & Next Steps

There is a lot of data recorded about planetary bodies in our solar system. Some of the things I didn't include in this project were the tilt of the planets in relation to their orbits, the direction of their spin, or the time it takes them to complete a full rotation around the sun, and plenty of others.

Now that I have a template, I want to try to plug in the data for individual planets with their moons, to see if they look the same or different. I was very surprised at how similar the path and direction of each of the planets rotations around the sun, and I'm curious if there are planet-moon systems that look more like what I image an atom looks like, with planetary bodies orbiting all around an object, and not just confined to one plane.

The image in this step is from exporting to Fusion 360, and messing with rendering the model.

If you want to find data on the planets in the solar system, here are a couple of additional places I used throughout this project with tons of information: