Camera Control

By
Dave
2012
Jan
31
17:58
Posted in

Currently the app supports a number of different types of manipulation, depending on the camera mode. These are demonstrated in the following short video and summarised below.

Video 1. Touch Manipulation used for camera control, recorded on a Microsoft Surface 2.0.

Free Camera

  • Pitch and Yaw by moving one or more touchpoints on the background
  • Roll by rotating two or more touchpoints on the background

Orbit Camera

  • Orbit body by moving one or more touchpoints on the background
  • Roll by rotating two or more touchpoints on the background
  • Adjust distance to body by pinch-zooming two or more touchpoints on the background

Geosync Camera

  • Roll by rotating two or more touchpoints on the background
  • Adjust distance to body by pinch-zooming two or more touchpoints on the background

Tracking Camera

  • Roll by rotating two or more touchpoints on the background

As shown in the video, when time is running, an orbit camera travels with the body, maintaining constant orientation so that the background stars remain fixed. The geosync camera always points at a specific coordinate on the body, and maintains a constant north bearing.

Smoothing

Touch resolutions oftern correspond to approximately the screen resolution in pixels, hence smoothing is necessary to avoid "jumps" in orientation or position. Also of importance is the use of momentum and inertia to provide a more "natural" touch experience.

I initially used a simple spring algorithm to add smoothing, momentum and inertia, and tracked manipulation speed to continue inertia when manipulation ended. This worked well at high framerates, but when using vertical sync (i.e. 60fps) the experience degraded.

Switching to a simple linear interpolation (LERP) of position and spherical linear interpolation (SLERP) for orientation bahaves well at lower frame-rates, and also gives the impression of momentum and inertia. I no longer track manipulation speed, nor continue inertia when the interpolation is complete.

HDR Tone Mapping

By
Dave
2012
Jan
13
15:54
Posted in

The XNA4 HiDef profile supports a SurfaceFormat.HdrBlendable format, allowing color values in a higher dynamic range than can be displayed. One of the most important steps in High Dynamic Range (HDR) post-processing is mapping color values to a displayable range, such as that shown in Figure 1 below.

Tone-mapping

Figure 1. Tone-mapped rendering of North America.

I initially scale the pixel luminance using the average luminance (1). If the average luminance greater or less than the mid-gray value, the pixel is scaled accordingly.

Scaled Luminance(1)

Scaled Luminance

Figure 2. Scaled Luminance by Average Luminance.

I then compress the luminance using the scaled and maximum luminance (2). If the average luminance is the same as the mid-gray value, the pixel values are compressed to within the 0-1 range.

Compressed Luminance(2)

Tone-mapped Luminance

Figure 3. Tone-Mapped Luminance by Average Luminance.

I can then downsample, apply the tone mapping algorithm, and reject any color values below a given threshold for a bright-pass filter. After applying appropriate post-processing filters I can then recombine with the original tone-mapped image. An example is shown below in Figure 4, where an emissive texture on the ship's engines has exceeded the bloom threshold after tone-mapping.

HDR Image

Figure 4. HDR Image showing engine bloom. Battlestar Galactica models (based on new TV series) by Coxxon.