OpenGL - Uses and Brief History
What is OpenGL?
A sofware interface to graphics hardware.
GLUT
Stands for Graphics Library Utility Toolkit
Used to simplify opening a window in which to place the graphics
An alternative to using the more complex(less intuitive) MIcrosoft Windows
The OpenGL API (Application Programming Interface) began as an initiative by Silicon Graphics to create a single, vendor-independent API for the development of 2D and 3D graphics applications. Prior to the introduction of OpenGL, many hardware vendors had different graphics libraries. This situation made it expensive for software developers to support versions of their applications on multiple hardware platforms, and it made porting of applications from one hardware platform to another very time-consuming and difficult. Silicon Graphics saw the lack of a standard graphics API as an inhibitor to the growth of the 3D marketplace and decided to lead an industry group in creating such a standard.
The result of this work was the OpenGL API library. The OpenGL API began as a specification, then a sample implementation was produced that hardware vendors could use to develop OpenGL drivers for their hardware. The sample implementation has been released under an open source license.
Modifications to the OpenGL API are made through the OpenGL Architecture Review Board, an industry group that contains founding, permanent, and auxiliary members.
The OpenGL specification is overseen by the OpenGL Architecture Review Board (ARB) which was formed in 1992. The ARB consists of a set of companies with a vested interest in creating a consistent and widely available API. According to the official OpenGL website, voting members of the ARB as of June 2002 include 3Dlabs, Apple Computer, ATI, Dell Computer, Evans & Sutherland, Hewlett-Packard, IBM, Intel, Matrox, NVIDIA, SGI and Sun Microsystems.
Microsoft, one of the founding members, left the ARB in March 2003.
Software developers do not need to license OpenGL to use it in their applications. They can simply link to a library provided by a hardware vendor. Hardware vendors do need to have a license to create an OpenGL implementation for their hardware.
OpenGL 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.
OpenGL 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 OpenGL, 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 OpenGL (unless the same pointer is used in a subsequent command).
OpenGL 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 OpenGL 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 OpenGL (the server). The server may or may not operate on the same computer as the client. In this sense, OpenGL 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 OpenGL may access at any given time and that communicates to OpenGL how those portions are structured. Therefore, there are no GL commands to configure the framebuffer or initialize OpenGL. 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 OpenGL. Framebuffer configuration occurs outside of OpenGL in conjunction with the window system; the initialization of a GL context occurs when the window system allocates a window for GL rendering.
OpenGL 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 OpenGL (by gl, GL_, and GL_, respectively in C) to reduce name clashes with other packages. The prefixes are omitted in this document for clarity.
Bring in libraries need by the program
Those preceded by gl are provided by OpenGL
Rest are C files. math.h, for example, contains functions prototypes for he math library functions. They are enclosed in < > which tells the compiler to look in the usual location to find them.
Header files provided by OpenGl are enclosed in <>. Additional OpenGL functions you write or obtain elsewhere should be stored in a directory you create. You must then tell the compiler where they are located. This will be covered in class – it is explained in my manual. You must enclose these in “ “
Window Management Routines (not using Win32) - controlling window using OpenGL
Graphics library utility toolkit (glut) – is a system independent toolkit for creating windows. It hides the complexities of different windows systems (such as the one provided by Microsoft). Five useful functions provided by glut are summarized below. In this introductory treatment, the parameters (items in parentheses) are omitted.
glutInit ( )
Initializes glut. This function should be called before any othe glut routine
glutInitDisplay mode()
Deals with colors and a number of other things
glutInitWindowsPosition()
Specifies the screen location for the upper left corner of your window
glutInitWindowSize()
Specifies the size, in pixels, of the window
glutCreateWindow()
Creates a window. Note that, until glutMainLoop() is called, the window will not be displayed.
The following functions are used to control actions when specified events occur. In this introductory treatment, the parameters (items in parentheses) are omitted.
glutReshapeFunc ()
Indicates what action should be taken when the window is resized
glutKeyboardFunc()
Invoked when a keyboard key or mouse button is used.
glutMotionFunc()
Deals with movement of the mouse
|
File |
Location |
|
gl.h glut.h glu.h |
Program Files\Microsoft Visual Studio 8.0\VC\include\gl |
|
OpenGL32.lib glut32.lib glu32.lib |
Program Files\Microsoft Visual Studio 8.0\VC\lib |
|
OpenGL32.dll glut32.dll glu32.dll |
Windows\System32 |
gl.h
Primary OpenGL header file.
Contains prototypes for various functions
glu.h
Header file for the OPenGL Utility library
Opengl32.lib
Library containing bindings to OpenGL functions.
glu32.lib
Library containing bindings to OpenGL Utility Library functions
opengl32.dll
Dynamic link library containing OpenGL function implementations and hooks into video hardware drivers.
glu32.dll
Synamic link library containing OpenGL Utility Library function implementations.
glut.h
Header file for OpenGL Graphic Library Utility Toolkit - used to manage Windows.
Ensures that gl.h and glu.h are included automatically - including them with separate code is redundant.