Vanity URLs

By
Dave
Project
Published
15 Apr 2011 11:31
Last Modified
13 Jan 2013 18:15

The category controller currently uses the following URL structure:

http://{domain}/blog/category/{slug1}

It is often useful for URLs to be more concise, for example when adding a caption to a video. In such cases "vanity URLs" are often used. I've updated the blog categories to enable them to support a vanity URL, currently based on the category slug, as follows:

http://{domain}/blog/{slug}

The approach I took was to inject specific entries into the MVC routing table. Clearly this wouldn't be sensible for large numbers of entries, but the number of blog cetegories should be relatively small, and not every category has to have one. An added complication is that whenever I add, update, or delete a category I may need to regenerate the routing table to support adding/removing vanity URLs. I add the enries as follows:

foreach (Category category in new BlogService().ListCategories())
   if (category.VanityUrl)
      routes.MapRoute(category.Slug, category.Slug, new { controller = "Archive", action = "CategoryIndex", name = category.Slug });

Listing 1. Adding vanity URLs to MVC route table

1 A slug is a "friendly" URL (both from an SEO and human-perspective), using characters which do not require HTML-encoding (e.g. dashes instead of spaces)

Star Selection

By
Dave
Project
Published
9 Apr 2011 16:28
Last Modified
13 Jan 2013 17:36

I wanted to be able to select individual stars for further information. In order to do fast lookups of stars near to a cursor or reticle I added a further spatial index to my background stars. Due to the inaccuracies of using right-ascension and declination near to the celestial poles, I used an indexing scheme based on cartesian coordinates. A screenshot is shown below in Figure 1.

Reticle for star selection

Figure 1. Reticle for star selection. Note that the reticle is shown at 2x scale for clarity.

More information on the star is shown after a configurable delay, and hidden when the reticle is no longer focussed on the object. This avoids rendering data when it is not required, and allows higher-latency data (such as from the internet) to be shown when ready. Going forward, I should consider a hierarchical indexing scheme such as a Hierarchical Triangular Mesh1, which would give me the ability to find the nearest star at a given level of resolution.

1 "Indexing the Sphere with the Hierarchical Triangular Mesh", Alexander S. Szalay, Jim Gray, George Fekete, Peter Z. Kunszt, Peter Kukol, and Ani Thakar, August 2005

Level of Detail Part 2

By
Dave
Project
Published
24 Mar 2011 22:17
Last Modified
13 Jan 2013 17:40

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.

Normal and Specular LOD

Normal and Specular LOD

Normal and Specular LOD

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.

Level of Detail

By
Dave
Project
Published
20 Mar 2011 18:49
Last Modified
13 Jan 2013 17:40

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.

AABB Intersections with View Frustum

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

LOD

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.

Surface 3D Demo Part 3

By
Dave
Project
Published
18 Mar 2011 20:32
Last Modified
13 Jan 2013 18:24

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:

SIRDS

Figure 1. Depth map

SIRDS

Figure 2. SIRDS for animation

SIRDS

Figure 3. Texture for static image

Filters

By
Dave
Project
Published
14 Mar 2011 23:19
Last Modified
13 Jan 2013 17:36

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.

H-Alpha Filter

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.

Size Matters

By
Dave
Project
Published
24 Jan 2011 21:08
Last Modified
13 Jan 2013 18:15

There's plenty more features I'd like to add to this blog engine, but it's currently serving me well.

One of the things I found refreshing about this project is that I now have a reasonably-spec'd personal blog-engine in just a 75Kb download (the source code is 80Kb). OK, the downloads are .zip files, but they expand to 176Kb, and 225Kb respectively (including images).

Disk-space and bandwidh may be cheap, but such a small download to run a blog site appeals to me. Could this be one of the smallest .NET-based blog engines available? :)

Multitouch Game Loop Input Processing

By
Dave
Project
Published
21 Jan 2011 19:37
Last Modified
13 Jan 2013 18:13

There are multiple potential sources of input for an XNA game component, such as keyboard, gamepad, mouse, Surface multitouch, .NET 4 Touch, etc. Dealing with multpile approaches to gathering input in the Update loop of each component can become complex, and adding support for a new input type further adds to this complexity.

I divided my input handling into two different categories:

  1. Controller-based input such as keyboard and gamepad.
  2. Manipulation-based input such as mouse, Surface multitouch, and .NET 4 touch.

For the latter, I wanted to abstract input handling such that a given game component only had to deal with a custom Manipulator type. In this way, I would be free to change or add input source(s) without affecting the implementation in a game component.

Clearly, different input sources provide different types and degrees of information. Surface multitouch Contacts for example, provide information on size, orientation, type etc, whereas a mouse only provides position. In many cases only position information is necessary, however additional properties can easily be added to the Manipulator type and supported by a game component if available. In this case I decided to sub-class my Manipulator type to the following:

  1. Mouse and finger-touch
  2. Surface Tag contacts
  3. Surface blob contacts

In order to deal with multitouch manipulations, I could process input using my previosuly-discussed Manipulation classes and processor.

The following video demonstrates the use of multiple input sources:

Video 1. Input processing from multiple sources.

Since a mouse can only deliver single-touch input, when demonstrating mouse input in Video 1 I switch the pivot type to "Tracked" in order to be able to demonstrate rotation and scaling, as shown in Figure 1.

Manipulation Input

Figure 1. Input processing from multiple sources.

Of course, it is unlikely that a scenario mixing both Mouse and Surface input would ever be used in practice, however it serves to illustrate how a game component can handle input in a consistent way, without being aware of the input source. For example, the buttons on the left of the screen are "pressed" using either Surface v1 Contact or a mouse-click, however the buttons only tracking Manipulator state.

A useful application of this approach is the ability to write XNA applications which work with both Surface v1 multitouch input and .NET 4 multitouch (and mouse for single-touch if multi-touch hardware is not available) without any code changes, i.e. multi-platform targetting.

Blog Engine v1.2 Released

By
Dave
Project
Published
5 Jan 2011 23:13
Last Modified
13 Jan 2013 18:17

I've made some improvements to my personal, lightweight blog engine from version 1.0 as follows:

  1. Added <meta name="keywords"> and <meta name="description"> tags to the post detail view and post model to help SEO.
  2. Corrected various HTML formatting issues, and provided new, more flexible CSS styles.
  3. Added a blog index showing posts by category.
  4. Added a simple CAPTCHA for comment submission.
  5. Added a gallery.
  6. Added support for site-pinning with Internet Explorer 9 Beta on Windows 7.

You can download version 1.2 using the following links:

  1. Dr Dave's Blog Engine v1.2 (binaries and ASP.NET pages) (zip'd), 75Kb. Files required to run Dr Dave's Blog Engine.
  2. Dr Dave's Blog Engine v1.2 (source code) (zip'd), 79Kb. Visual Studio 2010 project for Dr Dave's Blog Engine.

To install the blog engine using the binaries, follow these steps:

  1. Un-zip the archive and copy the files to your web site.
  2. Browse to your site and you should see the following:

    front page

    Figure 1. Front page after installation.

  3. Click "Sign In". The default username is "admin" with a password of "password". Click "Edit Account" in the Admin menu and change the password. A combination of upper-case letters, lower-case letters and numbers is recommended, with a length of at least six characters. You can also change the username if required.
  4. Click "Settings" on the Admin menu, and update the blog title, sub-title, and feed-title accordingly. Update the other settings if required.

If you decide to use this engine to run your blog, please keep the "Powered by" link, and I'd be grateful if you could inlcude an acknowledgement.

This project remains under active development as and when bugs are identified, or further features are required and I have the time. Note that I do not have time to support the installation or operation of this blog engine, however I will endeavour to answer questions in comments.

Virtual Universe Gallery

By
Dave
Project
Published
31 Dec 2010 00:41
Last Modified
21 Dec 2012 10:43

Now that I've added a gallery feature to my blog engine, I've created a gallery for this project and included a couple of screenshots I had lying around to get started.

There is a link to all galleries in the main menu, and this specific gallery can be found at http://drdave.co.uk/gallery/nuiverse.

Page