- Co-ordinate Systems
- Perspective and Parallel Projection
- Geometric Transformations
- Matrix Algebra and BRender
- Visualisation
- Hidden-Surface Removal

In a computer graphics system, a mathematical model of an imaginary scene is created and stored inside the computer. In order to accomplish this, the graphics system must provide some means of describing an imaginary scene to the computer. For the computer to generate a realistic simulation of the scene, it needs to know:

- the shape and position of all models (or model
*actors*in BRender terminology) in the scene - the colour and texture of these model actors
- the view (or camera) position, direction and orientation
- the lighting conditions.

**Figure 3 ** *Models are defined in model co-ordinates*

Note the orientation of the axes. With positive x to the right, and positive y pointing up, the positive z-axis points towards the viewer.

Actor data structures are designed to facilitate hierarchical relationships between elements of a scene. An actor may have a parent, and/or children. If an actor has no parent, it is the root actor of its hierarchy.

If an actor has a parent, its position and orientation is defined solely with respect to its parent's co-ordinate system, rather than with respect to some absolute co-ordinate system.

**Figure 4 ** *Actors transformed into parent's co-ordinate system*

By default, an actor is centered at the origin in its parent's co-ordinate system. Geometric transformations, discussed below, are used to change the position, orientation and size of an actor in its parent's co-ordinate system.

If an absolute frame of reference is required, the application might define a universal parent actor (called `World' perhaps), and make all other participants in a scene children of `World'. `World''s co-ordinate system (call it `world space') could then be used as an absolute frame of reference within the application.

Besides arranging the model actors that constitute the scene, the application must define a view position and orientation. These, together with other parameters such as lighting conditions and the shape of the view volume, determine which parts of a scene are visible.

**Figure 5 ** *Everything outside the view volume is invisible*

Model actors are tested, or *clipped*, against the sides of the view volume before being projected onto the screen. Everything lying entirely outside the view volume is eliminated. For lines or polygons that are partly inside and partly outside the view volume, the portions lying outside are eliminated. The edges of clipped polygons are reconstructed automatically.

**Figure 6 ** *Model actors are clipped against the sides of the view volume*

**Figure 7 ** *Perspective projection*

It is important to realise that with perspective projection physical dimensions are relative. How big a model appears on the screen depends not only on its physical dimensions as defined in model co-ordinates, but also on its position in 3D space relative to the view position. The farther a model is from the camera, the smaller it appears on the screen.

The projection of a given model onto the screen could be enlarged, for instance, by increasing the model's dimensions (see `Scaling' below), by moving it closer to the view position (see `Translation' below), by moving the view position closer to the model or by decreasing the field-of-view angle (see `Visualisation' below).

With a *parallel projection*, the view volume is a rectangular parallelepiped. Distance from the camera does not affect how large an object appears on the screen. Projection rays/vectors do not converge at a focal point but are projected along parallel lines.

**Figure 8 ** *Parallel projection*

Parallel projections are used in architectural and computer aided design applications where it is necessary to maintain relative sizes and angles after projection. In 3D computer graphics, perspective projections are usually specified. BRender supports both (the default is perspective).

**Figure 9 ** *Translation: T(5,0,0)*

Figure 9 illustrates a translation, T(5,0,0). The model actor is moved +5 units parallel to the x-axis (i.e. +5 is added to the x-components of the model's vertices). The y and z components are not altered.

**Figure 10 ** *Rotation: Rz(30)*

Figure 10 shows the, previously translated, model in Figure 9 rotated 30*xb0 * around the z-axis.

A scaling factor greater than 1 will `stretch' a model in the appropriate x,y,z dimension. A value less than 1 will `squeeze' it.

**Figure 11 ** *(a) Scaling: S(2,1,1); (b) Scaling: S(1,0.5,1)*

The scaling applied in Figure 11(a) stretches the model horizontally along the x-axis (the x components of the model's vertices are multiplied by 2). The model appears smaller and fatter. In Figure 11(b) the model is squeezed vertically (all y values are halved).

If the same value is used for all three (x, y, and z) scaling elements, the model will retain its original proportions but change in size.

**Figure 12 ** *Scaling: S(1,-1,1)*

An argument of -1 reflects the model in a plane. The scaling shown in Figure 12 reflects the model in the x-z plane.

A scaling of (2,2,2) doubles a model's length, width and depth - increasing its `volume' by a factor of 8, as seen in Figure 13(a).

**Figure 13 ** *(a) Scaling: (2,2,2); (b) Scaling: (0.5,0.5,0.5)*

Geometric transformations are most commonly represented in computer graphics by matrices. You don't need to understand matrix algebra in order to implement simple transformations. You specify the relevant parameters (direction and extent of the translation, the axis and angle of rotation etc.) and BRender sets up the transformation matrices.

However, in order to make full use of BRender's power and flexibility, you will need to understand how BRender implements matrix arithmetic. Each element of a BRender transformation matrix can be freely and individually accessed. If you are unfamiliar with the rudiments of matrix arithmetic, you may wish to consult your maths textbook before proceeding to the next section.

`br_matrix34`

data structures. These are effectively 44 matrices (in practice, the redundant fourth column is omitted for storage purposes and for speed).
Translation is conventionally treated as addition, whereas scaling and rotation are treated as multiplications. We want to be able to implement all three transformations in a consistent way, so that they can be easily combined. For this reason points are described in *homogeneous co-ordinates*. Homogeneous coordinates make it possible to implement all three transformations as multiplications.

In homogeneous co-ordinates, we add a fourth co-ordinate to a point - (x,y,z,W). The expression (x,y,z,W) represents the same point as (x/W,y/W,z/W,1). x/W,

y/W and z/W are said to be the Cartesian co-ordinates of the homogeneous point. In practice, the W coordinate is almost always 1 and is omitted for storage purposes and speed. See Section 5.2 of *Computer Graphics - Principles and Practice*, by James D. Foley *et al.*, for a more detailed discussion of homogeneous coordinates.

then pre-multiplies it by a row vector representing point P:

**Note that BRender's implementation of matrix arithmetic post-multiplies row vectors by matrices** (rather than the alternative convention of post multiplying matrices by column vectors).

This is easily verified. A unit vector along the x-axis, (1,0,0), rotated 90*xb0 * around the z-axis, should produce a unit vector along the y-axis:

The result (remembering that cos 90*xb0 * = 0 and sin 90*xb0 * = 1) is a unit vector along the y-axis, (0,1,0) as expected.

would be built to implement a scaling transformation:

Matrices can be concatenated to accumulate transformations. The compound transformation illustrated in Fig. 10 above for example, a translation followed by a rotation, could be represented by a single concatenated transformation matrix:

given that sin30*xb0 *=0.5, and cos30*xb0 *=
. This transformation matrix would transform a point P = (0,0,0), for instance, to point P' = (5
,2.5,0) as follows:

Matrix multiplication is not commutative, in other words:

**M****1****M****2**** ***xb9 *** M****2****M****1 **

The order in which you specify transformations is thus significant. Consider the consequences of reversing the order in which the above transformations are implemented. A 30*xb0 * rotation about the z-axis, followed by a translation T(5,0,0), would generate the image in Figure 14(b).

**Figure 14 ** *(a) Translate then Rotate: T(dxdydz)Rz(q); (b) Rotate then Translate: Rz(q)T(dxdydz)*

The resultant concatenated transformation matrix is given below.

This transformation matrix would transform a point P = (0,0,0), for instance, to point P' = (5,0,0) as follows:

Clearly, matrix multiplication is not commutative.

Remember to carefully consider the order in which you specify transformations. You may wish to experiment with the tutorial programs presented in the following chapters by changing the order in which geometric transformations are implemented.

**Figure 15 ** *The Default Camera *

Note that the default camera is perspective. The field of view is the angle subtended between the top and bottom of the view volume, typically 45*xb0 * in BRender. Setting this angle is analogous to selecting the focal length of a photographic lens. A narrow-angle field of view simulates a telephoto lens. Models appear closer and larger.

**Figure 16 ** *(a) Default Field of View (45 xb0 )
*

Figure **16** (b) A narrow-angle Field of View

A wide-angle field of view simulates a wide-angle lens. Models appear smaller, and further away.

**Figure 17 ** *A wide-angle field of view*

The field-of-view angle, together with the (user definable) *hither* and *yon* planes, determines the shape of the view volume. The shape of the view volume, in turn, determines what is potentially visible. The renderer tests models against the edges of the view volume to determine whether or not they are inside it. Models found to lie outside the view volume are not considered further.

**Figure 18 ** *Hidden surfaces are not displayed *

Hidden-Surface Removal techniques are used to ensure that only surfaces visible from the view position are displayed. Surfaces must be sorted according to their position in 3D space relative to the view position. This is necessary in order to determine which surfaces are visible, and which are obscured by surfaces nearer the view position.

Generated with CERN WebMaker