19. Building Interactive Graphics Applications (8/10)

Search in book...
Toggle Font Controls
Create new playlist

Name your new playlist

Playlist description (optional)
Sign In

Email address

Password

Forgot Password?

or

Continue with Facebook

Continue with Google
Sign Up

Full Name

Email address

Confirm Email Address

Password

or

Continue with Facebook

Continue with Google

502 19. Building Interactive Graphics Applications

(C2): Drawing

commands

Graphics

Hardware

Context

Prepare

Application

Rendering State

M M M

(C1): Prepare

for drawin

(A): Initialize

Gra

hics Hardware

(B): Create Graphics

Contex

Rendering State

M M M

Figure 19.19. Working with a graphics API.

It is convenient to consider this functional interface as consisting of two stages:

Graphics Hardware Context (GHC) and Graphics Device Context (GDC).

1. Graphics HardwareContext (GHC). This stage is depicted as the vertical

ellipse on the right of Figure 19.19. We consider the GHC as a conﬁguration

which wraps over the hardware video display card. An application creates a

GHC for each unique conﬁguration (e.g., depth of frame buffer or z-buffer,

etc.) of the hardware video card(s). Many Graphics Device Contexts (see

below) can be connected to each GHC to support drawing to multiple on-

screen areas from the same application.

2. Graphics Device Contex t (GDC). This stage is depicted as a cylindrical

pipe in Figure 19.19. The multiple pipes in the ﬁgure illustrates that an ap-

plication can create multiple GDCs to connect to the same GHC. Through

each GDC, an application can draw to distinct areas on the application win-

dow. To properly support this functionality, each GDC represents a com-

plete rendering state. A rendering state encompasses all the information

that affects the ﬁnal appearance of an image. This includes primitive at-

tributes, illumination parameters, coordinate transformations, etc. Exam-

ples of primitive attributes are color, size, pattern, etc., while examples of

illumination parameters include light position, light color, surface material

properties, etc. Graphics APIs typically support coordinate transformation

with a series of two or three matrix processors. In Figure 19.19, the “M”

19.4. Example Implementations 503

boxes inside the GDC pipes are the matrix processors. Each matrix pro-

cessor has a transformation matrix and transforms input vertices using this

matrix. Since these processors operate in series, together they are capable

of implementing multi-stage coordinate space transformations (e.g., object

to world, world to eye, and eye to projected space). The application must

load these matrix processors with appropriate matrices to implement a de-

sired transformation.

With this understanding, Figure 19.19 illustrates that to work with a graphics

API, an application will

(A) initialize one or more GHCs. Each GHC represents a uniqueconﬁguration

of the graphics video card(s). In typical cases, one GHC is initialized and

conﬁgured to be shared by the entire application.

(B) create one or more GDCs. Each GDC supports drawing to distinct areas

on the application window. For example, an application might create a

GDC for each view component in an application.

(C)drawusingaGDC.An application draws to a desired window area via

the corresponding GDC. Referring to Figure 19.19, an application sets the

rendering state (C1) and then issues drawing commands to the GDC (C2).

Setting of the rendering state involves setting of all relevant primitive and

illumination attributes and computing/loading appropriate transformation

matrices into the matrix processors. A drawing command is typically a

series of vertex positions accompanied by instructions on how to interpret

the vertices (e.g., two vertex positions and an instruction that these are end

points of a line).

In practice, modern graphics APIs are highly conﬁgurable and support many ab-

stract programming modes. For example, Microsoft’s Direct3D supports a draw-

ing mode where the matrix processors can be by-passed entirely (e.g., when ver-

tices are pre-transformed).

19.4.3 Implementation Details

Figure 19.20 shows the design of our implementation for the solution presented

in Section 19.3.3.

Here, the MainUIWindow object represents the entire ball

shooting program. This object contains the GUI elements (slider bars, quit button,

Source code for this section can be found at http://faculty.washington.edu/ksung/fcg3/ball.tar.zip

504 19. Building Interactive Graphics Applications

MainUIWindow

// GUI Elements:

SliderBars, EchoArea, QuitButton

LargeView

Service Mouse Events

Draws Application State

TheModel

HeroBall,

AllWorldBalls, etc.

SmallView

Service Mouse Events

Draws Application State

Figure 19.20. Implementation of the ball shooting program with two views.

etc.), the model (application state), and two instances of view/controller pairs (one

each for LargeView and SmallView).

OpenGL with FLTK

Figure 19.21 shows a screen shot of Fluid, FLTK’s GUI builder, during the con-

struction of the GUI for the ball shooting program. In the lower-right corner of

Figure 19.21, we see that (A) Fluid allows an application developer to interac-

tively place graphical representations of GUI elements (3D-looking icons); (B)

is an area representing the application window. In addition (C), the application

developer can interactively select each GUI element to deﬁne its physical appear-

ances (color, shape, size, etc.). In the lower-left corner of Figure 19.21, we see

that (D) the application developer has the option to type in program fragments

to service events generated by the corresponding GUI element. In this case, we

can see that the developer must type in the program fragment for handling the X

velocity slider bar events. Notice that this program fragment is separated from

(B): Area representing

the application window

Fluid (FLTK

GUI Builder)

(D): Application

developer types in this

code to service the X

velocity slider bar event.

Applicati

developer

Application

developer

would type in

(C): Application Developer

can create GUI elements and

define their appearances.

GUI elements

GUI

(A): Interactively

placed GUI elements

Figure 19.21. Fluid: FLTK’s GUI Builder.

19.4. Example Implementations 505

// Forward declaration of mouse event service routines

void ServiceMouse(int button, int state, int x, int y); // service mouse button click

void ServiceActiveMouse(int x, int y); // service mouse drag

class MainUIWindow {

UserInterface UI; // This is Linkage Code generated by Fluid (GUI Builder)

// This object services events geneated by GUI elements

Model *TheModel; // The application State (Figure 11)

FlGlutWindow *LargeView; // These are View/Controller pairs that understand graphics

FlGlutWindow *SmallView; // outputs (GDC) and mouse events (controller)

MainUIWindow(Model *m) { // The constructor

TheModel = m; // Sets the model …

LargeView = new FlGlutWindow(TheModel); // Create LargeView

LargeView->mouse = ServiceMouse; // callback functions for service mouse events

LargeView->motion = ServiceActiveMouse;

// Create SmallView … exactly the same as LargeView (not shown)

glutTimeFunc( // set up timer and services ) // Set up timer …

}

};

Figure 19.22. MainUIWindow based on OpenGL and FLTK.

the rest of the program source code system and is associated with Fluid (the GUI

builder). At the conclusion of the GUI layout design, Fluid generates new source

code ﬁles to be included with the rest of the application development environment.

Since these source code ﬁles are controlled and generated by the GUI builder, the

application developer must invoke the GUI builder in order to update/maintain

the event service routines. In this way, FLTK implements external service linkage

as described in Section 19.4.1. In our implementation, we instruct Fluid to create

a UserInterface class (.h and .cpp ﬁles) for the integration with the rest of our

application development environment.

Figure 19.22 shows the MainUIWindow implementation with OpenGL and

FLTK. In this case, graphics operations are performed through OpenGL and user

interface operations are supported by FLTK. As described, the UserInterface ob-

ject in the MainUIWindow is created by Fluid for servicing GUI events. The-

Model is the application state as detailed in Figure 19.11. The two FlGlutWindow

objects are based on a predeﬁned FLTK class designed speciﬁcally for support-

ing drawing with OpenGL. The constructor of MainUIWindow shows that the

mouse event services are registered via a callback mechanism. As discussed in

Section 19.2.4, the FLTK (Fast Light ToolKit) is an example of a light weight

GUI API. Here, we see examples of using callback as a registration mechanism

for receiving user events.

FlGlutWindow is a FLTK pre-deﬁned Fl

Glut Window class object (see Fig-

ure 19.23) designed speciﬁcally to support drawing with OpenGL. Each instance

of a FlGlutWindow object is a combination of a controller (e.g., to receive mouse

events) and a Graphics Device Context (GDC). We see that the draw() function

506 19. Building Interactive Graphics Applications

/ Fl_Glut_Window is a pure virtual class supplied by FLTK specifically for supporting

// windows with OpenGL output and for receiving mouse events.

class FlGlutWindow : public Fl_Glut_Window {

FlGlutWindow(Model *m); // Constructor

Model *TheModel; // The application state: initialized during construction time.

float WorldWidth, WorldHeight; // World Space Dimension

void HardwareToWorldPoint(int hwX, int hwY, float &wcX, float &wcY);

// Transform mouse clicks (hwX, hwY) to World Cooridnate (wcX, wcY)

virtual void draw() { // virtual function from Fl_Glut_Window for drawing

glClearColor( 0.8f, 0.8f, 0.95f, 0.0f );

glClear(GL_COLOR_BUFFER_BIT); // Clearing the background color

glMatrixMode(GL_PROJECTION); // Programming the OpenGL’s GL_PROJECTION

glLoadIdentity(); // Matrix Processor to the propoer transfrotm

gluOrtho2D(0.0f, WorldWidth, 0.0f, WorldHeight);

TheModel->DrawApplicaitonState(); // Drawing of the application state

}

};

Figure 19.23. FlGlutWindow: OpenGL/FLTK view/controller pair.

ﬁrst sets the rendering state (e.g., clear color and matrix values), including com-

puting and programming the matrix processor (e.g., GL

PROJECTION), before

calling TheModel to re-draw the application state.

Direct3D with MFC

Figure 19.24 shows a screen shot of the MFC resource editor, MFC’s GUI builder,

during the construction of the ball shooting program. Similar to Fluid (Fig-

ure 19.21), in the middle of Figure 19.24, (A) we see that the resource editor

(B): Area representing

the application window

(D): Event service

source code is integrated

with the rest of the

source code system.

GUI elements

GUI

(A): Interactively

placed GUI elements

(C):

Applicatio

(C): Application Developer

can create GUI elements and

define their appearances.

Figure 19.24. The MFC resource editor.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.

Table of Contents for 19. Building Interactive Graphics Applications (8/10)

Create new playlist

Sign In

Sign Up

Table of Contents for
19. Building Interactive Graphics Applications (8/10)