EO Solar System

EO Solar System


Bradford Evans


Kyle Otto

Computer Graphics II (4003
-
571
-
70)

Reynold Bailey


Project URL:
http://www.cs.rit.edu/~kro7400/cg2/eoss


Introduction
:


Our primary goal for this project was
to create a physically
-
accurate 3D simulation of the
solar system. We included several objectives in doing so: allow flying through the environment;
experiment with translucency, volumetric fog, and other effects; implement fractal terrain generation.
Esse
ntially, we were going for a few aspects of the “rendering pipeline” all in one. We wanted to create
a realistic visualization of the solar system, have it be semi
-
interactive, and implement a fractal terrain
algorithm.


Approach
:


Our approach was fairly
simple (though not properly judged for time/difficulty). First, we
gathered a bunch of data from the web about the solar system, including planet sizes,
colors/appearances, radii, distances, the sun's size, etc. The next step was to create a basic project
frame
to use, with an empty OpenGL window for the time being. From there, we started modeling the sun and
planets and texture
-
mapped them. Fly
-
through controls were added at this point so assist with the
modeling process. A basic “twinkling” starfield was
added to the background to make things a little
prettier. Following this, the planets and sun were animated. The creation of asteroids was next. We
experimented with randomizing point coordinates of these objects to approximate a rough, jagged
surface. An
attempt was made to adapt fractal terrain generation to these asteroids, but it was
unsuccessful. We underestimated the difficulty we'd have in adapting the algorithm to spherical
coordinates, and thus got pinched by time at the end. In the last bit of rem
aining time we had, we added
simple, animated atmospheres to the Earth and sun to enhance realism without significantly
compromising framerate.


Technical Details
:




Controls implemented to allow the user to move through the scene.



Shape Library
–

A Collect
ion of
user created

shapes that could be inserted into the system

◦

Shape
–

Base class that was the parent for half of the other shapes, contains vital
information regarding all of the shapes.

▪

Originally for each Shape, the goal was to generate the points fi
rst, then worry about
piecing them together to form triangles (initially) and (later) squares.

▪

Stores a collection of points/triangles/squares for each shape that then get drawn at
runtime allowing for all the rendering and point arithmetic do be done ahea
d of time.

▪

Contains most of the Drawing methods for both Triangles as well as Squares

◦

Sphere
–

A sphere subdivided on latitude and longitude making nice even squares.

▪

You can substitute one with 30+ subdivisions for a glSphere and have them look almost
pe
rfectly identical.

◦

Asteroid
–

A twist on the sphere.

▪

Take number of divisions and create a "map" of random variances from it and apply
these at the appropriate times. This generates our Mega
-
steroid as shown in the
presentation. However, significant medd
ling from this point to try and enable the fractal
algorithm has rendered this difficult to see.

▪

This object served as the testing ground for several of the different terrain generation
and fractal terrain generation methods

◦

Cone
–

A class originally inten
ded for the Ray Tracer, not used.

◦

IcosaSphere
–

A sphere based on the icosahedron rather than lat/long.

▪

Looks great, but the implementation had to be re
-
computed every frame so it was set
aside due to performance issues. Too bad too because it was very
nice.

◦

Highlight
–

A class that was going to show data about a planet. Beyond scope of project.

◦

Square
–

A collection of 4 points that do the Diamond Square algorithm.

▪

Each square has a depth, and basically divides itself until the desired depth is achi
eved.
We believe part of the problem with the algorithm lies with the subdivision.

▪

Originally triangles were used because of performance, but in an effort to accommodate
the diamond square algorithm, which we could not convert into a triangular formula, al
l
shapes were changed to using squares to store their data.

◦

Triangle
–

A simple collection of 3 points and some intersection code.

◦

EColor
–

This is basically just an easy way to represent the (R,G,B,A) information.

◦

EPoint
–

This is 3D point class that supp
orts arithmetic operations between the points.

▪

It stores a color value with every point to help maintain the color of any objects that it is
a part of.



OpenGL Extension Library

◦

Custom built library that imports calls directly from Window's OpenGL functio
nality.

◦

Contains a Visual Studio User Control for the use inside Window Forms.

◦

This was borrowed and again modified from earlier projects created by our team members.



Diamond Square fractal algorithm

◦

Tried to adapt to spherical coordinates; unsuccessful, s
crapped it

◦

Points are modulated by small random values instead. See the Asteroid Class for an
example.



Volumetric Information

◦

In part, the Kilgard Technique “
Fast OpenGL
-
rendering of Lens Flares” was

used to blend
the flares in with the sun. This is a mo
dified/simplified technique.

▪

Sun Volumetric algorithms are in SolarSystem.cs and the cool lens flares that allowed
them to work were found here:
http://www.opengl.org/reso
urces/features/KilgardTechniques/LensFlare/


◦

Cloud Maps were modified from here:
http://xplanet.sourceforge.net/clouds.php


◦

Planetary texture information was obtained from:
http://orsa.sourceforge.net/download.html




Information was gathered from:
http://solarsystem.nasa.gov/planets/index.cfm

and related pages
therein. This was sup
plemented by data from
http://www.nineplanets.org/
.




Results
:



Controls:



W
–

Move Forward along the Z Axis (Into Window)



A
–

Pan Left



S
–

Move Backward along the Z Axis (Out of Window)



D
–

Pan Right



Z
–

Move

along the X Axis to the Left



C
–

Move along the X Axis to the Right



Q
–

Quits Program



R
–

Enables Rotation of the system



L
–

Switches the Rendering mode of the sun. (Slower)



V
–

Switches the perspective from Angled, to inline with rotation plane.



1
–

Dis
able/Enable the Sun



2
–

Disable/Enable the Planets



3
–

Disable/Enable the Asteroid field.



Mouse Controls
–

Were broken in the process of trying to get a free
-
look camera. Sorry.


Future Enhancements
:



Implement a fractal algorithm for generating planetary t
errain properly

◦

Non
-
uniform planetary object creation

▪

donut or bean shapes would be great.



Optimize; increase framerate

◦

Offload majority of processing from CPU to GPU

▪

This is the primary bottleneck. The CPU can only generate so many of these scenes
withou
t help.

◦

Vertex Buffer Objects (VBO)
–

the best way to offload information to the graphics card.



Increase realism

◦

Elliptical orbits on varied plane orientations

◦

Better atmospheric and volumetric effects

◦

Add moons/comets/debris.



Improve fly
-
through controls

◦

Add support for mouse
-
look

◦

More degrees of freedom


Appendix A
:




On a Windows XP or Vista machine



Open the provided solution in Microsoft Visual Studio 2008



Clean, Rebuild and Run the program.


Appendix B
:



You should see it in the same folder that this i
s in.