i
i
i
i
i
i
i
i
19
Kelvin Sung
Building Interactive Graphics
Applications
While most of the other chapters in this book discuss the fundamental algorithms
in the field of computer graphics, this chapter treats the integration of these al-
gorithms into applications. This is an important topic since the knowledge of
fundamental graphics algorithms does not always easily lead to an understanding
of the best practices in implementing these algorithms in real applications.
We start with a simple example: a program that allows the user to simulate the
shooting of a ball (under the influence of gravity). The user can specify initial ve-
locity, create balls of different sizes, shoot the ball, and examine the parabolic free
fall of the ball. Some fundamental concepts we will need include mesh structure
for the representation of the ball (sphere); texture mapping, lighting, and shading
for the aesthetic appearance of the ball; transformations for the trajectories of the
ball; and rasterization techniques for the generation of the images of the balls.
To implement the simple ball shooting program, one also needs knowledge of
• graphical user interface (GUI) systems for efficient and effective user inter-
action;
• software architecture and design patterns for crafting an implementation
framework that is easy to maintain and expand;
• application program interfaces (APIs) for choosing the appropriate support
and avoiding a massive amount of unnecessary coding.
467
i
i
i
i
i
i
i
i
468 19. Building Interactive Graphics Applications
To gain an appreciation for these three important aspects of building the ap-
plication, we will complete the following steps:
• analyze interactive applications;
• understand different programming models and recognize important func-
tional components in these models;
• define the interaction of the components;
• design solution frameworks for integrating the components; and
• demonstrate example implementations based on different sets of existing
APIs.
We will use the ball shooting program as our example and begin by refining the
detailed specifications. For clarity, we avoid graphics-specific complexities in
3D space and confine our example to 2D space. Obviously, our simple program
is neither sophisticated nor representative of real applications. However, with
slightly refined specifications, this example contains all the essential components
and behavioral characteristics of more complex real-world interactive systems.
We will continue to build complexity into our simple example, adding new
concepts until we arrive at a software architecture framework that is suitable for
building general interactive graphics applications. We will examine the validity of
our results and discuss how the lessons learned from this simple example can be
applied to other familiar real-world applications (e.g., PowerPoint, Maya, etc.).
19.1 The Ball Shooting Program
Our simple program has the following elements and behaviors.
• The balls (objects). The user can left-mouse-button-click and drag-out a
new ball (circle) anywhere on the screen (see Figure 19.1). Dragging-out a
ball includes:
–(A).Initial mouse-button-click position defines the center of the cir-
cle;
–(B).Mouse button downand moving the mouse is the dragging action;
–(C).Current mouse position while dragging allows us to define the
radius and the initial velocity. The radius R (in pixel units) is the dis-
tance to the center defined in (A). The vector from the current position
to the center is the initial velocity V (in units of pixel per second).
i
i
i
i
i
i
i
i
19.1. The Ball Shooting Program 469
(R): Radius
(V): Initial velocity
(A): Initial mouse
click position
Dragging
(C) Current
mouse position
(
B
)
Dra
gg
in
g
Figure 19.1. Dragging out a ball.
Once created, the ball will begin traveling with the defined initial velocity.
• HeroBall (Hero/active object). The user can also right-mouse-button-
click to select a ball to be the current HeroBall. The HeroBall’s velocity
can be controlled by the slider bars (discussed below) where its velocity
is displayed. (A newly created ball is by default the current HeroBall.)
A right-mouse-button-click on unoccupied space indicates that no current
HeroBall exists.
• Velocity slider bars (GUI elements). The user can monitor and control
two slider bars (x-andy-directions with magnitudes) to change the veloc-
ity of the HeroBall. When there is no HeroBall, the slider bar values are
undefined.
• The simulation.
– Ball traveling/collisions (object intrinsic behaviors). A ball knows
how to travel based on its current velocity and one ball can potentially
collide with another. For simplicity, we will assume all balls have
identical mass and all collisions are perfectly elastic.
– G ravity (external effects on objects). The velocity of a ball is con-
stantly changing due to the defined gravitational force.
– Status bar (application state echo). The user can monitor the ap-
plication state by examining the information in the status bar. In our
application, the number of balls currently on the screen is updated in
the status bar.
i
i
i
i
i
i
i
i
470 19. Building Interactive Graphics Applications
Ball Shooting Program
Velocit
y
(X)
12.48
(
Pixel/Sec
)
Velocit
y
(Y)
9.12
(
Pixel/Sec
)
Q
UIT
Status:
Currently there are 5 balls on screen.
User
Velocit
y
Motion
Motion trajectory
for the next second
Slider
Slider bar
numeric echo
Dragged
out balls
Current
Hero Ball
Application
Status
Figure 19.2. The ball shooting program.
Our application starts with an empty screen. The user clicks and drags to
create new balls with different radii and velocities. Once a ball travels off of the
screen, it is removed. To avoid unnecessary details, we do not include the drawing
of the motion trajectories or the velocity vector in our solutions. Notice that a
slider bar communicates its current state to the user in two ways: the position of
the slider knob and the numeric echo (see Figure 19.2).
We have now described the behavior of a simple interactive graphics appli-
cation. In the rest of this chapter, we will learn the concepts that support the
implementation of this type of application.
19.2 Programming Models
For many of us, when we were first introduced to computer programming, we
learned that the program should always start and end with the main() function—
when the main() function returns, all the work must have been completed and the
program terminates. Since the overall control remains internal to the main() func-
tion during the entire life time of the program, the type of model for this approach
to solving problems is called an internal control model,orcontrol-driven pro-
gramming. As we will see, an alternative paradigm, event-driven programming
or an external control model approach, is the more appropriate way to design
solutions to interactive programs.
i
i
i
i
i
i
i
i
19.2. Programming Models 471
In this section, we will first formulate a solution to the 2D ball shooting pro-
gram based on the, perhaps more familiar, control-driven programming model.
We will then analyze the solution, identify shortcomings, and describe the moti-
vation for the external control model or event-driven programming approach.
The pseudocode which follows is C++/Java-like. We assume typical function-
ality from the operating System (OperatingSystem::) and from a graphical user
interface API (GUISystem::). The purpose of the pseudocode is to assist us in
analyzing the foundation control structure (i.e., if/while/case) of the solution. For
this reason, the details of application- and graphics-specific operations are inten-
tionally glossed over. For example, the details of how to UpdateSimulation() is
purposely omitted.
19.2.1 Control-Driven Programming
The main advantage of control-driven programming is that it is fairly straightfor-
ward to translate a verbal description of a solution to a program control structure.
In this case, we verbalize our solution as follows:
while the user does not want to quit (A);
parse and execute the user’s command (B);
update the velocities and positions of the balls (C);
then draw all the balls (D);
and finally before we poll the user for another command,
tell the user what is going on by echoing current application state to
the status bar (E).
while user command is not quit
parse and excute user’s command
if (OperatingSystem::SufficientClockTimeHasElapesd)
UpdateSimulation() // update the positions and velocities
// of the all the balls (in AllWorldBalls set)
DrawBalls(AllWorldBalls) // all the balls in AllWorldBalls set
EchoToStatusBar() // Sets status bar: number of balls on screen
(A): As long as user is
not ready to quit
(B): Parse the user
command
(C): periodically
update positions and
velocities of the balls
(D): Draw all balls to
the computer screen
(E): Sets status bar
with number of balls
Figure 19.3. Programming structure from a verbalized solution.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.