Exoplanet Visualization in CAVE2


This project was completed as a part of my graduate level graphics course concentrating on visualization in large, high-resolution environments, such as CAVE2 at EVL.

The goal of this project was to take exoplanet data and combine 2d-small multiple views with 3d-immersive views, to provides scientists with a visual window into exoplanet data. Further, this project aims make the findings of astronomical research accessible to a general audience by translating data into a graphics. The program is head and hand tracked and runs onomegalib in CAVE2.

In the process of completing this project, it was necessary to do some background research on exoplanets, stars, orbital mechanics and astronomical coordinate systems. I hope to present some of this work here so that others wishing to design similar systems may have an easier time.


Exoplanet detection is challenging, but surveys such as the Kepler space telescope have enabled scientists to catalog hundreds of systems with potential exoplanets. Most of these exoplanets documented resemble Jupiter or Neptune, largely due to bias in detection. It is difficult to detect planets like earth because one of the major modes of detection is the 'transit method'.

This makes visualization alongside earth difficult, since detected exoplanets can be radically larger than earth.


After examining several sources of exoplanet data, I ended up choosing the open exoplanet catalog: http://www.openexoplanetcatalogue.com/index.php because this database provided xml files from Kepler and other exoplanet surveys. These xml files are simple to parse in python, using the mini-dom library.

My approach was to identify 48 interesting systems to present in both 2d-small-multiples and in the center of the cave in 3d.

I chose the 48 systems by searching for lists of systems with potentially habitable planets or high earth-similarity indices. I primarily obtained this list from http://phl.upr.edu/projects/habitable-exoplanets-catalog/data and http://en.wikipedia.org/wiki/List_of_potential_habitable_exoplanets. I then augmented the list based on these articles:

Determining Planet Type

To texture planets appropriately, I used Sudarsky's method ( http://en.wikipedia.org/wiki/Sudarsky_extrasolar_planet_classification ) which classifies planets based on temperature.  

I used the textures from Celestia to texture spheres and create planet images.  

Computing Habitable Zone

There are several approaches to computing the habitable zone around a star.  I ultimately used the following computations for 'habitable zone':

I wanted to use a computation based on luminosity, but I was getting strange results:  habitable zones that were overly large or non-existent, suggesting that something was wrong with either my computation or the data I was using to compute the zones.  I didn't have time to track down the problem, so I defaulted to the simpler computation based on star type.  

Some articles on this:

My Program

On load, my program displays both a single 3-dimensional representation of our solar system in CAVE2 but also 48 2d 'small multiple' representations of systems with potentially habitable planets. 

Central Solar System:

The center system shows planets orbiting a central star.  The orbits on the planets are drawn with accurate eccentricity, major-axis, inclination, longitude of ascending node and argument of periapsis.  The planets orbit the star with accurate angular velocity, which increases as the planet approaches the point closest to the star.  

Constructing the orbits and moving planets around these orbits accurately was a challenge.  The first step, was to draw an ellipse as a series of lines.  The code to accomplish this is below: 

After drawing the orbit, it needs to be positioned in 3d space.  3 parameters specify the position of the orbit relative to the sun:  longitude of ascending node, inclination and argument of periapsis.  

Translating this diagram into scene-node rotations:

The next step is moving a planet in this elliptical orbit with appropriate angular velocity.  Angular velocity changes relative to distance from the star.  Computing this involves some trigonometry:  

I believed my planets to be rotating properly, but then I discovered at the last minute that one failed to complete its rotation, and would repeatedly jump back to an earlier point in the orbit.  As a result, I would advise anyone using this code to check the computation.  

Binary systems, while not handled in this project, are drawn by computing the center of mass between stars and then allowing the stars to rotate around the center of mass just as planets rotate around a star.  

In early versions of my code, planets rotated about their rotational axis properly.  Somewhere in the final two days of the assignment, this rotational code broke and I didn't have time to fix it.  Future work on this project will involve fixing this bug. 

The central solar system can be changed by clicking on one of the small multiples using the left-shoulder button on the wand.  

The habitable zone is drawn as a narrow green disk. 


The central solar system can be navigated around using the wand and the 'left analog trigger' button.  It can be rotated relative to the camera using the 'cross' buttons.  It can be expanded through an option in the menu.  The rate of orbit can be increased through an option in the menu.  

Some images of different solar systems loaded into the central solar system:

Small Multiples:

Along the side, small multiples show simplified representation of each solar system.  The distance from the central star and the radius of the planets are shown, with some limitations:  Since most planets were much larger than earth, I tried a couple of methods of sizing the radius.  I kept a 'maximal size' variable in place, because otherwise the planets would fill the entire space.  However, this meant that size was not ultimately shown properly.  I meant to try accurate sizing, with the small planets drawn 'in front' or to limit the size but include some text to show how much larger a planet was than its drawn size, but I ran out of time to finish this. 

The user can 'expand' the small multiples or compress, which allows the user to see the distances between planets at different scales.  

Small multiples can be selected, to view in the central system.  They can also be sorted by number of planets, number of stars, distance to earth and star type.  

All Systems View

I had a view that showed all systems as stars, with position and orientation obtained from right ascension, declination and distance parameters.  

I got this view working, but then something broke this view, making it very difficult to position and map accurately.  I didn't have the chance to figure out what had gone wrong.


I had a lot of technical problems during the completion of this project.  Something would work and then break unexpectedly and I wouldn't notice right away, making debugging very difficult.  If given the opportunity to do this project again I would have spent much less time on accurate orbit creation and more time on the small multiples, binary star systems and user interaction, since estimated orbits are sufficient for a first pass viewing of the systems.  
I re-worked the scaling approach, deciding to focus on mapping one coordinate system (scales in KM) to another coordinate system (position in screen space).  I ended up rewriting most of the starter code and I had so many problems getting this to work that I didn't have time to add additional features.  

Future Steps:

I am considering doing some further work on these systems to consider whether this is an interesting multi-scale, hybrid 2d/3d research problem. In particular:
- How can you relate systems with vastly different scales to each other? In particular, if you size every element and position according to a single mapping system, the vast stretches of space will consume most of the view. In the case of my small-multiples, showing small planets at a useful resolution, make large planets too large, such that they block the users ability to percieve distance. As a result, I ultimately placed an upper limit on the size of planetary images in the small multiples, so that distance between elements could be percieved.

I wanted to try the following schemes in my visualization, and I wonder whether these have been done before:
- space systems at optimal mapping for that particular system and cue the viewer using:
- interactivity- as user moves mouse over small multiple X with mapping Y, a line appears in all the other small multiples indicating a distance marker for all systems.
- color gradient with color changes relative to mapping. So, elements that are vastly far apart will pass through few colors, while elements close together will hit all the colors at once.

I also was interested in trying to create a 'zoom' box, that shows elements within up close, while elements further away could also be seen.

I didn't have the chance to implement these approaches in this visualization, but I will be on the lookout for how people solve spatial disparity problems in multi-scale visualization.

Subpages (1): Part 2...