Planetary Model Design
William Jones
01/22/2015
Part A
Simplified High level design for a 3D
engine
Start
3D Engine with a GUI
End
3D Engine specs
• Suggested engine Crystal Space
http://www.crystalspace3d.org/
• Any 3D engine that creates a GUI should work
• Must have spherical models
• Must have animation paths
• Must store static data that will be retrieved at
run time, and displayed in panel
10 3D Models
• Create 10 spherical models representative of the eight
planets, (Mercury, Venus, Earth, Mars, Jupiter, Saturn,
Uranus, and Neptune) the Sun, and Earth’s moon
• Approximate color should match, but no texture
required
• Info at http://planetfacts.org/the-solar-system/
• Scaled down is acceptable, all to the same scale
• Will be view from a vantage on top of the z-axis where
a 2.9 billion mile circular orbital path can be view just
inside the view frame, ie. Neptune’s orbit is just within
view at all times
Animation and Orbital paths
• The Sun model center will at the XYZ origin,
(0,0,0)
• Each of the 8 planets will have a circular line on
the XY plane a radius equal the max. distance
from the Sun (scaled the same as the planets),
and orbital path
– The circular line will be white or transparent,
adjustable at run time
– Orbital paths will linked to the related model
• An animation path for each planet will match the
orbital path
The Earth’s Moon
• The Earth’s moon dose not require a circle
showing its path
• The moon’s animation path will have to rotate
around the Earth while the Earth moves on it’s
animation path
Animation Speed
• One orbit of the Earth should take 10 seconds
• All other planets animation speed should be
scaled to be proportion, thus Neptue’s 164.83
Earth year orbit should take 1648.3 seconds
• All animation speeds must be multiplied by a
single animation factor variable
• The variable at this time will be equal to 1, but
in the future could be use to adjust the global
speed of the planets
The Camera view
• The camera will be above the XY plane along the
Z axis, so that all of Neptune's 2.8 billion mile
orbit is within the frame of view
• No lighting effect at the current time, although a
light in the Sun may be desirable later
• The camera will be fixed and not move at this
time, nor will zooming be allowed, however in
the future these features will be desired
• The background will be solid black
Planet Data
• Each of the 10 models will have static data
associated with it
• At the current time this data can be hard
coded with any number of facts from
http://planetfacts.org/the-solar-system/
• In the future, the data will be loaded in from a
database at application startup
The GUI
• The GUI will have three buttons, two toggles
and one “Exit” button
• One toggle button will be play and pause the
animation
• The other toggle will display and hide the
orbital paths Orbits
• The “Exit” button ends the application Exit
GUI
• The orbital paths and the 10 Models will be
selectable (clickable)
• Upon selection, half the GUI will be filled with
a panel displaying the data related to that
model
• Any selection (click) will remove panel, when
the panel is displayed
Neptune is the forth largest planet.
Neptune in Roman mythology is the god
of the Sea
Orbits
Exit
What to do next
• Get a game design or 3D engine expert to
review this design and offer feedback
• Get a 3D engine code to explain back to me
what I have in this design
• Look for feedback from the client, that the GUI
is shaping up like they want, and the most
important features are included
Part B
Simplified High level design for a 3D
engine
Abstraction
• 3D model are abstraction, and I defined then
only to be respective of the planet
• The GUI defined in general term and with
elements likely to be in any GUI
• Circles to represent orbital paths are an
abstractions manifested in the design
• The camera view is used to show where the
view point of the users is
Detail added
• Any details where two or more items where
connected added – orbital path match
animation paths and are selectable
• Static data would be connected to the models
and displayable
• Ruff images of how the display should look
• Images of the buttons desired
“Good Enough”
• When I ran out of things to describe
• I would go over the slides and try to see if I
had enough detail, where I would know what
to do, if I were coding this
• Dead line coming up. It is 5:40am on the 22ed,
my original idea died, and this is the much
simplified replacement
Requirements or Design
• This is more requirements to me
• It is you must have this and that
• There is some design in that proper
requirement do not say use this type of
button or anything that forces the coders
down a certain path
Rejected design
Research showed the physics of
depicting orbits as they truly are, is
not feasible at the current time
Concept
• Many stellar bodies of interest orbit or are
satellites of other parent bodies, who intern
have parents, etc.
• Those the do not have parents move in a liner
path, thus all motion could be defined relative
to each other and apply not just to our solar
system, but many
Object Interactions
Initiation
Start
User Input
GUI
End
Graphic Output
3D Engine
Stellar Objects
Stellar
Objects
Database
Stellar Object Class
Stellar Objects are use polar
coordinates based off a parent Stellar
Object. The ultimate parent is the
universe center.
Research on polar coordinates and
Stellar Date/Time required.
Parent stellar objects have a normal
orbital plane. Parents have satellite
children, who become part of their
FarMass.
All stellar objects have vector of
motion. If the object has a parent
other then the universe center, then
an orbit is created. The orbit may not
match the normal orbital plane of the
parent. Additional gravitational forces
can alter the objects orbit.
Rotational Axis are independent of
other factors.
StellarObject
ParentStellarObject: StellarObject
Satellites: LinkedList <StellarObject>
MotionVector: Polar3DVector
ParentMass: Long
NearMass: Long
FarMass: Long
OrbitAngle: Polar3DOrbitAngel
Axis: PolarLine
NomalOrbit: PolarPlane
StartLocation: PolarLocation
StartDate: StellarDateTime
Facts: FactMap
GavitationalPulls: LinkedList <StellarObject>
Location(StellarDateTime);
GetSatlites();
LocationFromUniverseCenter(StellarDateTime);
GetFacts();
GetParent();
GetAxis();
Stellar Object Database
Research on polar coordinates
and Stellar Date/Time required
to define Polar3D Vector,
Polar3DOrbitAngel, PolarLine,
PolarLocation, and
StellarDateTime.
Model3D is a 3 dimensional
model that the GUI will show
multiple views of. A 3D Model
class should exist in the library.
The database can be expanded
to include other types of
standard data, as the client
requests.
StellarObject
+SellarID: Int
Name: String
Model: Model3D
Orbits: SellarID
Satellites: Table <ParentStellarID, SatelliteStellarID>
MotionVector: Polar3DVector
NearMass: Long
FarMass: Long
OrbitAngle: Polar3DOrbitAngel
Axis: PolarLine
NomalOrbit: PolarPlane
StartLocation: PolarLocation
StartDate: StellarDateTime
GavitationalPulls: Table <StellarID, GavPullsStellarObjectID>
Population: String
Atmosphere: String
Temperature: Long
Other: Memo
(additional info as client asks)
3D Engine
• Identify a 3D engine that works with the desired
programing language.
• The 3D engine must bind to an adjustable view in
the GUI
• Objects in the 3D view must be selectable
• 3D objects must be linked to stellar object
instances
• Stellar object instances will define object
movement, and can return facts about the object
GUI Initiation
1. Default parent = Sol (our solar system) of the
Milky Way galaxy
2. Query database for parent object and create
StellarObject populated with database
information
3. Create 3D object of parent and place it in the
center of the 3D view
4. Repeat step 2 for each satellite of the parent
5. Place satellite relative to parent in the 3D view
based on the current date
GUI User Input
• Date/time to be viewed: calendar and time
spinner
• Speed to step forward in time: integer spinner
• Parent to center on: selectable list
• Clickable objects in 3D view
• 3D rotation controls: X, Y, and Z (integer
spinner and graphic hand control)
• Play/pause: toggle button
Realization of using 3D
• At this point, I realized, I wanted a 3D engine to
create the view inside the GUI
• While I was looking for a 3D engine likely to allow
being inside a standard application, I also started
looking at what the 3D physics engine could do
• This lead to looking deeper at physics evolved for
a real simulation and the fact an accurate
simulation can not be done
• Then it dawn on me 3D engines do their our GUI
flipping the project inside out
Information Links
• http://star-www.stand.ac.uk/~fv/webnotes/chapter6.htm
• https://en.wikipedia.org/wiki/Cosmic_Calendar
• https://en.wikipedia.org/wiki/Julian_day
• http://answers.unity3d.com/questions/27792/or
bit-sim-without-physics-engine.html
• http://www.crystalspace3d.org/main/Features
• http://www.arachnoid.com/orbital_dynamics/ind
ex.html
• http://planetfacts.org/the-solar-system/