Dr Dave

I described in Part 1 the basis of an approach for a planetary renderer with Level of Detail (LOD) support. I've now added the following:

• Support for a simple cylindrical tiling scheme, using 512-pixel, square tiles and 2 tiles at LOD 0.
• A background process to load tiles as required, without locking the rendering loop.
• Datasets for surface texture, normals, specularity and clouds to LOD 5 (2048 tiles with an overall size of 32,768 x 16,384 pixels).

Figures 1-3 below show the mapping of surface texture, normals and specularity.

Figures 1-3. View the French Alps showing normal and specular mapping at LOD 1, 3 and 5 respectively.

The next step is to adapt the atmospheric shaders for a tile-based approach. Adapting the cloud-shadowing algorithm will be the biggest challenge, since this will require more than one cloud tile in order to calculate the correct shadows for a single ground tile.

The current implementation of the planetary renderer uses a single texture, or level of detail (LOD). In order to provide more realistic views when moving closer to the planet's surface I need to vary the LOD according to the view. This is a well-studied and potentially complex topic, however it is useful to start by considering the following:

• A tile system for spherical textures.
• An approach for culling geometry that is not visible.
• An algorithm for picking LOD based on the current view.
• Availability of data.

Tile System

There are several tiling systems available, however I thought I'd start with a simple quad-tree. Bing maps currently uses 256-pixel, square tiles based on a Mercator projection. The first level has 4 tiles, the second level has 16 tiles etc. Simple cylindrical datasets are also available which use different tile sizes and arrangements, for example 1024-pixel, square tiles with the first level having 2 tiles for east and west, the second having having 8 tiles etc.

Culling

I thought I'd start with a simple quad-tree approach, based on culling the results of recursive intersection tests between tile bounding boxes and the view frustum. Figure 1 shows an initial screenshot of this approach. Each of the tiles in a quad is a different primary color, and tiles are drawn for LOD 3 (64 tiles in this tiling scheme). Bounding boxes are shown when there is an intersection at a given LOD with the view frustum. Each child within the bounding box is then checked. If the child is outside of the view frustum, it is culled. If it intersects, the processes recurses to a lower LOD.

Figure 1. AABB Intersections of Tiles with View Frustum

LOD Calculation

The amount of planet surface visible is a function of the distance from the planet, and the field of view and direction of the camera. I therefore needed to work out the size of each tile (they vary by latitude) so that the appropriate LOD can be rendered. I thought I'd start by measuring the maximum distance along a line of longitude within the tile. Figure 2 shows a rendering of the sphere where the upper tiles are rendered at a higher LOD (since for a given LOD they are smaller due to their lattitude).

Figure 2. Tiles rendered at varying LOD

The geometry used to create the tiles uses a constant number of vertices per degree of latitude and degree of longitude. In addition to minimising vertices, this also ensures that adjacent tiles of different LOD "line-up" correctly to a certain level. For example, if I use 64 vertices per 360 degrees of longitude and 32 vertices per 180 degrees of lattitude, the tiles tesselete without gaps up to LOD 6 in this tiling scheme (since these tiles are the first to have only 4 vertices).

Data

The current planetary renderer uses the following data sources:

• Surface texture
• Normal map
• Cloud map

Going forward, I'd also like to include specularity maps (seperately or as part of the alpha channel of the texture) to deal with the different reflectivity between land and water. In supporting a LOD approach, I don't want to sacrifice realism when rendering lower LOD. Since I would therefore also need normal, cloud (and optionally specularity) maps, I will use the simple cylindrical datasets.

In Part 1 and Part 2 I described an interactive autostereogram viewer. In this post, I thought I start by including a link to a video.

The video shows how multitouch gestures on Microsoft Surface can be used to interact with the models. A depth-map shader then processes the model, and a second-pass converts the depth-map to an autostereogram. As described previously, to avoid distracting the eye when animating a tile-based autostereogram, a randon-dot pattern is used which is regenerated each frame. Unfortunately the video doesn't have the required resolution to see much detail when animating the autostereogram, but the 3D-effect seen when the animation stops is maintained when viewing the application.

Here are some further screenshots:

Figure 1. Depth map

Figure 2. SIRDS for animation

Figure 3. Texture for static image

I wanted to be able to view the sky and planets using different wavelengths of light, and a convenient way to achieve this was by the use of "filters", as shown below in Figure 1.

Figure 1. H-Alpha Emmision Filter.

This enables me to either adjust the camera orientation while keeping the filter in fixed position, or move the filter around a while keeping the camera orientation fixed (or a combination of both), and see the relevant portion of the sky in a different wavelength. By ajusting the opacity scale it is possible to see how items relate to each other in different wavelengths (for example an area of H-Alpha emmision originating from particular star or deep-sky object in the visible spectrum).

The approach I am currently taking is to render the view in each wavelength, and create opacity masks which I can use to blend the views together. In this way I can use multiple filters of arbitrary shape and size.