View Design Documentation

From FIFE development wiki
Jump to: navigation, search

This article is part of design documentation. Design 32.png

Design documentation describes how software is implemented or is about to be implemented. It focuses on system structure (e.g. dependencies), module interactions and relevant algorithms. Concepts described in these articles should form the terminology that is used when discussing about the software that forms FIFE.

This article is outdated and needs to be reviewed! Outdated.png

The content of this article is outdated and should be treated as such. We cannot guarantee the accuracy of the information presented here.

Introduction

Missing yet.

Naming conventions

Caution: this list might be heavily outdated at the moment. A view module expert can hopefully clean up this area.

In this part I will propose a little naming scheme, to ease discussions about the Map View:

  • Camera: An object, that controls the field of view.
  • Display List: A list of Renderables, that are about to be drawn in the order they are on the Display List
  • Prerendering: A techinque to save alpha blending of Renderables. Blitting them on a temporary rectangle surface.
  • Opaque rectangles: The part of an renderable, that will allways stay opaque, thus containing no alpha value less then 254
  • Dirty Optimizations/Lighting: Rendering or optimization, that is not 100% correct, but a lot faster.
  • Renderer Separation: Code path, that needs specific knowledge about the RendererBackend used. E.g. Lighting Code.
  • Volatile: A renderable, that changes it's physical representation. An animation basically.
  • Gourand Shading: A fast lighting technique, linear interpolation of a lightmap between given points.
  • Lighting Grid: A triangulation of the map surface, at each point calculating the light value, using Gourand Shading for the rest.
  • Second Level Cache: A cache for prerendered and possibly pre lighted Display Lists

Coordinate system & transformation

Prerequisites

Background info on elevation, layer, camera.

Handedness

The handedness of a coordinate system determines how the axes grow from the origin. There are only 2 of them: left or right. Those who have taken higher chemistry classes might find this familiar with the term 'chiralty'.

Relationship between elevation, layer(cellgrid) and screen coordinate system

Each exists in their own coordinate space. Since each layer is contained within an elevation, layer->elevation coordinate mapping can be done. This is also what happens when an instance is drawn. A layer to elevation to screen coordinate mapping is used to find the screen coordinate of an instance and draw it.

Layeraxis.png

Layer coordinate transformation sequence is rotate->scale->translate for easy visibility on changes during mapping. Keep this in mind when you are adjusting cellgrids for a map. Transformation on the layer coordinate is visually independent of the elevation coordinate space.

Layertransform.png

Elevation coordinate transformation is translate->scale->rotate->tilt. Transformation on elevation coordinate will have a visual effect on layer/cellgrid coordinate space.

Layersinelevationaxis.png

Lastly ,we have the screen coordinate, which is basically the coordinate space on which everything is drawn. take note that although it says 'screen', it's not a 2d space. It's in fact, 3D. the elevation->screencoord transformation maps the model coordinate onto actual pixels for rendering. Thus, the z-coord of a screencoordinate is in pixels unit.

Screenelev.png

Coordinate system and transformation

All coordinate spaces are left-handed. The most important feature is that the y-axis increases downward instead of upward (in keeping with SDL coordinate ). Another point is that z-axis increases as it goes out of the screen into the observer's face.

Our transformation matrix reflects the left-handed transformation. for example, our rotation matrix looks something similar to this(left side):

Rotationhandedness.png

Rotations at positive angle around a left-handed axes is shown here,

Lefthandrotaxis.png

Camera positioning & movement

The camera, at 0 angle and constant reference scale, is located at a constant z-coord. The reference scale specifies that at certain zoom value, how much of an area is viewed through the viewport. Changing the camera's location will only change it's (x,y) value. The camera is also capable of infinite(almost  ;D ) zoom/scale factor. Tilting the camera keeps it's pointing vector at the same magnitude. However, the camera itself moves around the elevation x-axis (range:[0,-90] for now, with the vector changing direction to keep pointing at it's x,y location.

Tilthemisphere.png

When a camera rotates, the camera pointing vector also changes while the magnitude is preserved. The camera position range & movement can be described in a circular track around it's location. However, the track of which the camera follows will depend on the tilt value. At tilt value of 90, the track's z-coord is 0. For an isometric map with your camera looking at the ground, use a negative value for tilt. If your camera looks at the sky, use a positive value.

Rothemisphere.png

References