Graphics Reference
In-Depth Information
There are, of course, many details in these operations, and we have only
sketched the overall process here. Many of these should be familiar from your
experience with graphics programming using OpenGL. Later in this chapter
we will review some of these details and discuss some others that may not be
quite as familiar. And in the later chapters that describe fragment shaders and
show how you can use them, you will see how to control most of the details
yourself.
State in the Graphics Pipeline
In order to manage the large number of OpenGL operations and all of the
options they need, OpenGL sets and maintains a set of state information that
is used in the vertex and rendering operations. A large number of OpenGL
functions have as their only operation the seting of information in the graph-
ics state. As these operations are carried out, they get their information from
the state.
We need to be very aware of the OpenGL state in working with shaders,
because we will have to replace some critical fixed-function operations. It will
be useful to have a comfortable language and notation to talk about OpenGL
state. We introduce the notion of a graphics context to describe the OpenGL
state, and introduce a diagram of this context in Figure 1.4.
The initial graphics context has a number of default values (e.g., lines
are white and one pixel wide, the background color is black, and there are no
active textures.) When we set values with functions such as glColor3f(...) ,
we will say that we “dock” the color value to the slot that holds the primary
color value in the OpenGL state. If we change that color with another function
call, then the slot holds the new value and the old value is lost. Thus, each
“docking point” holds a unique state value that is used in the graphics process,
and most values can be queried as well as set. We will see this from time to
time as we discuss shader operations.
Figure 1.4. The OpenGL state as a graphics context object.
Search WWH ::




Custom Search