Dr Dave

In Part 1 I described a lightweight class to process general multitouch manipulations using a game-loop model in XNA.

A key aspect in bringing realism to a multitouch experience is the use of momentum and inertia. The Microsoft.Surface.Core.Manipulations.Affine2DInertiaProcessor provides this support in an event-driven model. In order to continue the approach of using a game-loop model, I needed to add linear and angular velocities, and expansion rates to my manipulation processor.

Changes in manipulator position occur relatively rarely in relation to the game loop frequency, hence calculating rates of change requires averaging these changes over time. The choice of duration and quantity of these time periods is somewhat subjective, and I settled on 5 samples averaged over a maximum of 200ms. Clearly this leads to a small latency between measured and actual velocities, however the smoothing effect is beneficial.

In order to visualise these rates, both for debbugging and to settle on suitable sampling settings, I added visual indicators of direction and magnitude, as shown below in Figure 1.

Figure 1. Visualising linear and angular velocities and expansion rates during multitouch manipulation.

With the addition of linear and angular velocities and expansion rates, I could now add a simple inertial processing component which uses these properties as input parameters. This inertial processor uses a simple deceleration algorithm, with configurable rates for translation, rotation, and expansion. The solution is demonstrated in the following video.

Video 1. Multitouch game loop inertia processing.

Note that for gestures such as a flick, where velcity increases rapidly, a time-weighted average may be more suitable for calculating the inertia processor's input parameters, and I'll investigate this at a later date.

I wanted to add labels to the brighter background stars. Stars are commonly identified using multiple designations, including:

1. Common names
2. Bayer names
3. Flamsteed names
4. Catalogue identifiers such as Hippacos, Henry Draper etc

In this way, the same star may be referred to as Belelgeuse, α Orionis, 58 Orionis, HIP27989, and HD39801 respectively. Since each designation is used for a varying group of stars, a given star may have a varying number of designations.

I chose to start with Bayer names, since there are a reasonable number of these (approximately 1500), and they would also serve as a good reference to add definitions of constellations and asterisms at a later date. The first step was to build a suitable list, which was greatly helped by the availability in the public domain of cross-references between designations.

I previously discussed a couple of approaches to text rendering for deep sky object labels, and I took a similar approach here. Since I was using wireframe labels, I needed to add a further set of vector definitions for the Greek alphabet. Unfortunately, these characters are not included in the "Modern", "Roman", and "Script" Windows fonts. However, other definitions are available in the public domain, such as the Hershey fonts developed in the 1960s by Dr. A. V. Hershey at the US Naval Weapons Laboratory.

Numeric superscripts are also used in the Bayer system. These may be used to distinguish stars with the same Greek letter, such as (typically optical) binaries, however there are some exceptions such as the chain of stars π¹, π², π³, π⁴ and π⁵ Orionis. I therefore needed to further extend the wireframe font rendering to support superscripts. An initial screenshot is shown in Figure 1.

Figure 1. Bayer star names, in the region of Orion

One of the remaining issues, now highlighted by the larger number of names, is dealing with overlapping labels. Culling labels on the CPU, either by magnitude for wide fields-of-view, or when not visible outside narrow fields-of-view might be a useful approach, and will be investigated at a later date.