Dr Dave

While it is possible to select a planetary body using a touch-and-hold gesture on its label or the body itself, finding the planet can be tricky. At the very least the orbital lines and labels need to be visible. A bigger problem, however is that the "inner" and "outer" planet orbits have markedly different scales. Hence when in orbit around an outer planet it will not generally be possible to resolve an inner planet for touch-and-hold.

I therefore added a further control for selecting a planet, as shown below in Figure 1. Since moons are relatively close to a planet in comparion to other planets, touch-and-hold can be used to move to a moon in orbit around the currently selected planet. The control can be added from the tag selection bar, as shown below in Figure 1. Touching a planet switches the camera to orbit mode around the body.

Figure 1. Planet Selector Control. Earth is the current planetary system.

The planet names and images are built at run time to ensure that they reflect any extensions to the base data.

Following on from my post on panoramas, I thought I would make available some desktop backgrounds for multi-monitor configurations. The following are for dual monitors, each full-HD (1920x1080).

I currently use Surface Tags for menus, reticles, compasses, and filters.

There are both advantages and disadvantages to this approach. Advantages inlcude the ability of a tag to provide context of which control to add to the screen, and the ease at which a physical object can be moved, rotated, and removed (i.e. no requirement for "close" buttons). Disadvantages include the requirement to have the tags, and what to do in either Windows 7 multi-touch or vertical Surface deployments. With the latter in-mind, I was keen to explore a "tag-free" mode, which uses touch instead of tags.

In order to add a control to the screen without a tag, I needed a gesture which was easy to discover, and which had a low chance of being invoked accidentally. I opted for an analogy to sliding a physical tag from the bezel onto the edge of the screen. To add a default control, I drag a touch from the edge of the screen. In order to add different controls, I slide in a default "virtual tag" until the tag "selection bar" appears, then move in an orthogonal direction to cycle through a circular list of controls, then continue sliding in to place the control. These steps are illustrated below.

Figure 1. Hint to "tag-free" default control.

Figure 2. Slide-in "tag-free" default (menu) control.

Figure 3. Cross-slide to "tag-free" compass control.

Figure 4. Cross-slide to "tag-free" reticle control.

In a similar way to physical tags, I can rotate the "virtual tags" using two or more touch points placed where the physical tag would normally reside. To remove a tag, I slide or flick it to the edge of the screen.

In order to best support multiple users and/or orientations, it is possible to slide in controls from each edge of the Surface, with the tag "selection bar" and controls being oriented appropriately.

I thought it would be interesting to create some space panoramas using screenshots from the app. Clearly there are a number of ways I could do this programmatically, but there are plenty of stitching tools avaialble. I'm using Image Composite Editor from Microsoft Research. Some initial attempts are shown below.

Figure 1. Earth with orbit trails along the ecliptic plane.¹

Figure 2. Outer solar system with orbit trails and scale grid.¹

Figure 3. Earth with Milky Way visible along galactic plane.¹

Figure 4. Outer solar system with contellation art.¹

Figure 5. Saturn and ring system.¹

Figure 6. Earth horizon.¹

I limited the above panoramas to an aspect ratio of 4.5:1, however it is of course possible to stitch much wider images, such as Figure 7, which has an aspect ratio of 6.75:1 and a field-of-view of virtually 360°.

Figure 7. Constellations around the equator.¹

¹ Background filter generated from image credit Nick Risinger, skysurvey.org

One of the difficulties when judging distances in the solar system, other than that they are very large, is that the solar system is mostly empty space. Orbit lines only give a hint of motion and indicative scale.

I've added some planar grids to the ecliptic to try to help visualise distances at logarithmic scales starting at 1AU, with each grid fading out as the next fades in. Grids can be circular, square, or hexagonal. Circular grids are useful to visualise orbit eccentricity, perihelion and aphelion. Square grids are useful to disambiguate from orbit lines.

Figure 1. Circular scale grid.¹

Figure 2. Square scale grid.¹

Figure 1. Hexagonal scale grid.¹

I've yet to find a compelling use for hexagonal grids, however they appear to be useful for Klingon tactical displays.

Additional screenshots are in the gallery.

¹ Background filter generated from image credit Nick Risinger, skysurvey.org

In part 1 I discussed adding support for drawing constellations, boundaries and asterisms, along with their names.

I've now added support for constellation art. Rather than loading individual images for each constellation shown in the camera view, I opted instead to use the same rendering approach as for background filters, which gives on-demand loading at the appropriate level-of-detail. A screenshot is shown below in Figure 1.

Figure 1. Constellation art. The field-of-view is 70°.

The Space Telescope Science Institiute worked with the U.S. Naval Observatory's Library to scan and painstakingly re-touch a set of beautiful engravings from the 17th century Firmamentum Sobiescianum sive Uranographia star atlas by Johannes Hevelius¹. In order to use these images, I first needed to align them with the background stars, then re-project them to a suitable format. I opted for an equirectangular projection. Whilst there is almost certainly a choice of tools available for the job, I thought it would be fun to write my own. The result of applying it to Figure 2 is shown in Figure 3 below.

Figure 2. Engraving of Ursa Major, "Firmamentum Sobiescianum sive Uranographia", Johannes Hevelius, 1690¹, positioned appropriately over an spherical, equatorial grid of right-ascension and declination.

Figure 3. Equirectangular, planar re-projection of Figure 2, resulting in vertical and horizontal lines of right-ascension and declination respectively.

The app will ship with low-res versions of the art, with higher-resolution versions available as an extra. It is, of course possible to use alternative art using the same extensibility model.

¹ Image credit the U.S. Naval Observatory and the Space Telescope Science Institute.

I previously discussed a method for rendering background images over specific areas of the screen using filters. In order to combine these images with the entire starfield, I followed a similar level-of-detail approach to planetary bodies. Figures 1 and 2 below show example screenshots.

Figure 1. H-alpha emmision¹ filter, 225,000km from Jupiter. The field-of-view is 90°.

Figure 2. Wide-field Infrared Survey² (WISE) filter, 20,000km from Earth. The field-of-view is 70°.

Now that I am using an extensibility model, once I have generated the image tiles and added the configuration file, I simply need copy the data to the application data directory for use.

Check out the gallery for more images.

¹Composite of the Virginia Tech Spectral line Survey (VTSS) and the Southern H-Alpha Sky Survey Atlas (SHASSA), Credit Douglas Finkbeiner
²Credit NASA/JPL-Caltech/WISE Team

I previously discussed a command-line tool for generating image tiles. I've updated the tool to include an additional parameter for image format. Usage is as follows, and the tool is available for download:

C:\tilegen /?
Generates a directory of tiles from a source image equirectangular projection

TILEGEN [drive:][path]filename level [/S=size] [/D=directory] [/F=filename] [/I=image]

   [drive:][path]filename   Soure image
   level                    Level of detail (0-based)
   /S=size                  Size of tile, default 256px
   /D=directory             Directory format, default level{0}
   /F=filename              Filename format, default {col}_{row}
   /I=image                 Image format (JPEG, PNG, TIFF), default JPEG (Compression=90)

Note that the source image is not scaled so must be correct level and size,
i.e. width (px) = 2 * 2^level * size, height (px) = 2^level * size

C:\>

It's been a while since I've updated my planet shader. One of the items on my list was to make the shader more modular so that I could cope with different "types" of planet or moon, without proliferating the number of techniques. This is particularly important now that I am using an extensibility model for adding or updating data.

The planetary shader currently deals with the following options:

• Color map
• Normal map
• Specular map
• Night map
• Cloud map
• Atmosphere
• Rings (with shadows on both the body and ring)

One approach to support multiple combinations of these options is to use seperate shader techniques. The number of combinations when picking r items from n options is defined by Equation 1.

(1)

Since I could use any number of these options, the number is given by Equation 2.

(2)

For 7 shader options, this therefore gives 127 shader techniques. Clearly this would not be viable, so I opted to use static shader branching. Since certain aspects of my rendering required Shader Model 3.0 anyway, this seemed a good approach, and resulted in acceptable performance.

Figures 1-7 below show individual shader options for color, specular mapping, normal mapping, night, atmosphere, and clouds, with a cumulative combination alongside.

Figure 1. Color Map.

Figure 2. Specular Map.

Figure 3. Normal Map.

Figure 4. Night Map.

Figure 5. Atmosphere.

Figure 6. Clouds.

Figures 7 and 8 below show individual shader options for color and rings with a cumulative combination alongside.

Figure 7. Color.

Figure 8. Rings.

I wanted to provide an easy way to extend the application with additional bodies, textures etc. I had previously used a single configuration file for visual elements, so while it was possible to configure existing or add additional elements it required a configuration change.

I wanted to support a "drag-and-drop" approach, so that additional items could be added, or existing items updated, just by copying files to a directory. This has the additional benefit of allowing the app to "ship" with minimal data (hence size) and be easily updated.

I'm using an XML-based configuration to define star systems. New files added to an "extras" folder can add or amend as many nodes of the XML configuraiton as they wish. In this way, one or more new/existing objects can be added/amended per file, with additional (e.g. texture) data, being referenced by a relative path. The application will recursively search for multiple .xml files, only following a particular branch of subdirectories until an .xml file is found.

I'm currently defining a set of sample extras to serve as examples.