1. Planetary Model Design William Jones 01/22/2015

2. Part A Simplified High level design for a 3D engine

3. 3D Engine with a GUI Start End

4. 3D Engine specs Suggested engine Crystal Space http://www.crystalspace3d.org/ 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

5. 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/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

6. 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

7. 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

8. 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

9. 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

11. 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/ http://planetfacts.org/the-solar-system/ In the future, the data will be loaded in from a database at application startup

12. 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 The “Exit” button ends the application Orbits Exit

13. 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

14. Orbits Exit Neptune is the forth largest planet. Neptune in Roman mythology is the god of the Sea

15. 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

16. Part B Simplified High level design for a 3D engine

17. 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

18. 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

19. “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

20. 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

21. Rejected design Research showed the physics of depicting orbits as they truly are, is not feasible at the current time

22. 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

23. Object Interactions Start Stellar Objects Stellar Objects Database GUI User Input Graphic Output End Initiation 3D Engine

24. 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 MotionVector: Polar3DVector ParentMass: Long NearMass: Long FarMass: Long OrbitAngle: Polar3DOrbitAngel Axis: PolarLine NomalOrbit: PolarPlane StartLocation: PolarLocation StartDate: StellarDateTime Facts: FactMap GavitationalPulls: LinkedList Location(StellarDateTime); GetSatlites(); LocationFromUniverseCenter(StellarDateTime); GetFacts(); GetParent(); GetAxis(); Stellar Object Class

25. 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 MotionVector: Polar3DVector NearMass: Long FarMass: Long OrbitAngle: Polar3DOrbitAngel Axis: PolarLine NomalOrbit: PolarPlane StartLocation: PolarLocation StartDate: StellarDateTime GavitationalPulls: Table Population: String Atmosphere: String Temperature: Long Other: Memo (additional info as client asks) Stellar Object Database

26. 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

27. 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

28. 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

29. 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

30. Information Links http://star-www.st- and.ac.uk/~fv/webnotes/chapter6.htm http://star-www.st- and.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://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://www.arachnoid.com/orbital_dynamics/ind ex.html http://planetfacts.org/the-solar-system/