The software used is OpenGL
For more information about OpenGL: OpenGL
What is the OpenGL Graphics System?
OpenGL (for ``Open Graphics Library'') is a software interface to graphics
hardware. The interface consists of a set of several
hundred procedures and functions that allow a programmer to specify
the objects and operations involved in producing
high-quality graphical images, specifically color images of three-dimensional
objects.
Most of OpenGL requires that the graphics hardware contain a framebuffer.
Many OpenGL calls pertain to drawing objects
such as points, lines, polygons, and bitmaps, but the way that some
of this drawing occurs (such as when antialiasing or
texturing is enabled) relies on the existence of a framebuffer. Further,
some of OpenGL is specifically concerned with
framebuffer manipulation.
Programmer's View of OpenGL
To the programmer, OpenGL is a set of commands that allow the specification
of geometric objects in two or three dimensions,
together with commands that control how these objects are rendered
into the framebuffer. For the most part, OpenGL
provides an immediate-mode interface, meaning that specifying an object
causes it to be drawn.
A typical program that uses OpenGL begins with calls to open a window
into the framebuffer into which the program will draw.
Then, calls are made to allocate a GL context and associate it with
the window. Once a GL context is allocated, the
programmer is free to issue OpenGL commands. Some calls are used to
draw simple geometric objects (i.e. points, line
segments, and polygons), while others affect the rendering of these
primitives including how they are lit or colored and how they
are mapped from the user's two- or three-dimensional model space to
the two-dimensional screen. There are also calls to
effect direct control of the framebuffer, such as reading and writing
pixels.
Implementor's View of OpenGL
To the implementor, OpenGL is a set of commands that affect the operation
of graphics hardware. If the hardware consists
only of an addressable framebuffer, then OpenGL must be implemented
almost entirely on the host CPU. More typically, the
graphics hardware may comprise varying degrees of graphics acceleration,
from a raster subsystem capable of rendering
two-dimensional lines and polygons to sophisticated floating-point
processors capable of transforming and computing on
geometric data. The OpenGL implementor's task is to provide the CPU
software interface while dividing the work for each
OpenGL command between the CPU and the graphics hardware. This division
must be tailored to the available graphics
hardware to obtain optimum performance in carrying out OpenGL calls.
OpenGL maintains a considerable amount of state information. This state
controls how objects are drawn into the framebuffer.
Some of this state is directly available to the user: he or she can
make calls to obtain its value. Some of it, however, is visible
only by the effect it has on what is drawn. One of the main goals of
this specification is to make OpenGL state information
explicit, to elucidate how it changes, and to indicate what its effects
are.
We view OpenGL as a state machine that controls a set of specific drawing
operations. This model should engender a
specification that satisfies the needs of both programmers and implementors.
It does not, however, necessarily provide a model
for implementation. An implementation must produce results conforming
to those produced by the specified methods, but there
may be ways to carry out a particular computation that are more efficient
than the one specified.
OpenGL Fundamentals
OpenGL (henceforth, the ``GL'') is concerned only with rendering into
a framebuffer (and reading values stored in that
framebuffer). There is no support for other peripherals sometimes associated
with graphics hardware, such as mice and
keyboards. Programmers must rely on other mechanisms to obtain user
input.
The GL draws primitives subject to a number of selectable modes. Each
primitive is a point, line segment, polygon, or pixel
rectangle. Each mode may be changed independently; the setting of one
does not affect the settings of others (although many
modes may interact to determine what eventually ends up in the framebuffer).
Modes are set, primitives specified, and other GL
operations described by sending commands in the form of function or
procedure calls.
Primitives are defined by a group of one or more vertices. A vertex
defines a point, an endpoint of an edge, or a corner of a
polygon where two edges meet. Data (consisting of positional coordinates,
colors, normals, and texture coordinates) are
associated with a vertex and each vertex is processed independently,
in order, and in the same way. The only exception to this
rule is if the group of vertices must be clipped so that the indicated
primitive fits within a specified region; in this case vertex
data may be modified and new vertices created. The type of clipping
depends on which primitive the group of vertices
represents.
Commands are always processed in the order in which they are received,
although there may be an indeterminate delay before
the effects of a command are realized. This means, for example, that
one primitive must be drawn completely before any
subsequent one can affect the framebuffer. It also means that queries
and pixel read operations return state consistent with
complete execution of all previously invoked GL commands. In general,
the effects of a GL command on either GL modes or
the framebuffer must be complete before any subsequent command can
have any such effects.
In the GL, data binding occurs on call. This means that data passed
to a command are interpreted when that command is
received. Even if the command requires a pointer to data, those data
are interpreted when the call is made, and any subsequent
changes to the data have no effect on the GL (unless the same pointer
is used in a subsequent command).
The GL provides direct control over the fundamental operations of 3D
and 2D graphics. This includes specification of such
parameters as transformation matrices, lighting equation coefficients,
antialiasing methods, and pixel update operators. It does
not provide a means for describing or modeling complex geometric objects.
Another way to describe this situation is to say that
the GL provides mechanisms to describe how complex geometric objects
are to be rendered rather than mechanisms to
describe the complex objects themselves.
The model for interpretation of GL commands is client-server. That is,
a program (the client) issues commands, and these
commands are interpreted and processed by the GL (the server). The
server may or may not operate on the same computer as
the client. In this sense, the GL is ``network-transparent.'' A server
may maintain a number of GL contexts, each of which is an
encapsulation of current GL state. A client may choose to connect to
any one of these contexts. Issuing GL commands when
the program is not connected to a context results in undefined behavior.
The effects of GL commands on the framebuffer are ultimately controlled
by the window system that allocates framebuffer
resources. It is the window system that determines which portions of
the framebuffer the GL may access at any given time and
that communicates to the GL how those portions are structured. Therefore,
there are no GL commands to configure the
framebuffer or initialize the GL. Similarly, display of framebuffer
contents on a CRT monitor (including the transformation of
individual framebuffer values by such techniques as gamma correction)
is not addressed by the GL. Framebuffer configuration
occurs outside of the GL in conjunction with the window system; the
initialization of a GL context occurs when the window
system allocates a window for GL rendering.
The GL is designed to be run on a range of graphics platforms with varying
graphics capabilities and performance. To
accommodate this variety, we specify ideal behavior instead of actual
behavior for certain GL operations. In cases where
deviation from the ideal is allowed, we also specify the rules that
an implementation must obey if it is to approximate the ideal
behavior usefully. This allowed variation in GL behavior implies that
two distinct GL implementations may not agree pixel for
pixel when presented with the same input even when run on identical
framebuffer configurations.
Finally, command names, constants, and types are prefixed in the GL
(by gl, GL_, and GL, respectively in C) to reduce name
clashes with other packages. The prefixes are omitted in this document
for clarity.
GL State
The GL maintains considerable state. This document enumerates each state
variable and describes how each variable can be
changed. For purposes of discussion, state variables are categorized
somewhat arbitrarily by their function. Although we
describe the operations that the GL performs on the framebuffer, the
framebuffer is not a part of GL state.
We distinguish two types of state. The first type of state, called GL
server state, resides in the GL server. The majority of GL
state falls into this category. The second type of state, called GL
client state, resides in the GL client. Unless otherwise
specified, all state referred to in this document is GL server state;
GL client state is specifically identified. Each instance of a GL
context implies one complete set of GL server state; each connection
from a client to a server implies a set of both GL client
state and GL server state.
While an implementation of the GL may be hardware dependent, this discussion
is independent of the specific hardware on
which a GL is implemented. We are therefore concerned with the state
of graphics hardware only when it corresponds
precisely to GL state.
The five major elements of a Computer Graphics System are:
1. Processors
2. Memory
3. Frame
Buffer or Frame
Buffer
4. Output Devices
Cathode
Ray Tubes
Random-scan
Calligraphic
5.
Input Devices
Lights and Images
Ray
Tracing
Ray
Tracing
Ray Tracing
Details of the Human Eye
Depth Cues in the Human Visual System
The Human Visual System - Slide Show