Doc & Technical Information
Doc & Technical Information
OpenGL: FROM THE EXTENSIONS TO THE SOLUTIONS Training Course materials
OpenGL example source code tree
OpenGL demo source code tree
OpenGL 1 & 2 classes source trees
Introduction:
This document describes the OpenGL graphics system: what it is, how it acts, and what is required to implement it. We assume that the reader has at least a rudimentary understanding of computer graphics. This means familiarity with the essentials of computer graphics algorithms as well as familiarity with basic graphics hardware and associated terms.
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.
Overview:
The GL Utilities (GLU) library is a set of routines designed to complement the OpenGL(TM) graphics system by providing support for mipmapping, matrix manipulation, polygon tessellation, quadrics, NURBS, and error handling. Mipmapping routines include image scaling and automatic mipmap generation. A variety of matrix manipulation functions build projection and viewing matrices, or project vertices from one coordinate system to another. Polygon tessellation routines convert concave polygons into triangles for easy rendering. Quadrics support renders a few basic quadrics such as spheres and cones. NURBS code maps complicated NURBS curves and trimmed surfaces into simpler OpenGL evaluators. Lastly, an error lookup routine translates OpenGL and GLU error codes into strings.
Overview:
This document describes GLX, the OpenGL extension to the X Window System. It refers to concepts discussed in the OpenGL specification, and may be viewed as an X specific appendix to that document. Parts of the document assume some acquaintance with both the OpenGL and X.
In the X Window System, OpenGL rendering is made available as an extension to X in the formal X sense: connection and authentication are accomplished with the normal X mechanisms. As with other X extensions, there is a defined network protocol for the OpenGL rendering commands encapsulated within the X byte stream.
Since performance is critical in 3D rendering, there is a way for OpenGL rendering to bypass the data encoding step, the data copying, and interpretation of that data by the X server. This direct rendering is possible only when a process has direct access to the graphics pipeline. Allowing for parallel rendering has affected the design of the GLX interface. This has resulted in an added burden on the client to explicitly prevent parallel execution when that is inappropriate.
X and the OpenGL have different conventions for naming entry points and macros. The GLX extension adopts those of the OpenGL.
Introduction
This document defines the OpenGL Character Renderer (GLC), a state machine that provides OpenGL programs with character rendering services via an application programming interface (API). This document is written with the assumption that the reader understands the OpenGL specification.
Section 1 provides an overview of GLC, examples of its use, and a comparison with other character rendering services. Section 2 defines the GLC machine, Section 3 defines the GLC API, and Section 4 covers future extensions to GLC.
NOTE: On the cover page of the complete book as a single PostScript file, it says "Early Access Release, November 1995". The chapters-as-separate-files accessible via the Table of Contents link are PostScript versions of the IRIX 6.2-release version. Other than indistinguishable "polish" applied to the chapters as individual files, the two versions ARE identical.from the beginning of About This Guide:
OpenGL on Silicon Graphics Systems explains how to use the OpenGL graphics library on Silicon Graphics Systems. The guide expands on the OpenGL Programming Guide, which describes implemetation-independent aspects of OpenGL. It discusses these major topics:
What This Guide Contains
This guide consists of 14 chapters and 3 appendixes:
Note that although this guide contains information useful to developers porting from IRIS GL to OpenGL, the primary source of information for porting is the OpenGL Porting Guide, available from Silicon Graphics (or via the IRIS Insight viewer online).
NOTE: GLR software is only available on IRIX 6.2. To program and experiment with GLR, load thegl_dev.sw.samplessubsytem which contains man pages and two necessary header files,/usr/include/GL/{glr.h,glrproto.h}.
Abstract:
GLR is a network-extensible render service providing OpenGL rendering into rectangular frame buffer regions. GLR virtualizes access to fast, high-quality, but expensive rendering hardware for purposes such as image processing, printing, frame buffer calculations, and off-loaded high-quality rendering.
In particular, off-loaded rendering using GLR permits expensive high-end graphics hardware to be shared and amortized across a group of users on a local area network. Hybrid GLR programs for applications like computer-aided design and scientific visualization can use local OpenGL rendering for dynamic, interactive 3D graphics, then use GLR to render higher-quality static scenes (enabling higher tessellation, high-quality texturing, antialiasing, etc.) with sub-second latency.
GLR's approach is novel because access to the rendering hardware is virtualized using render intervals allowing guaranteed access to the frame buffer resources for a client-requested duration. GLR is implemented as a client library and a specialized X window manager that schedules render intervals. Unlike a traditional window manager, the GLR window manager policy controls the mapping and unmapping of windows to effect the render interval policy. GLR demonstrates that the X Window System model is adaptable for uses other than the traditional window system.
GLR is an OpenGL based render facility. GLR is a mechanism to share expensive graphics hardware resources between users on a network. The idea is to amortize the hardware among multiple users to bring high-quality rendering to a larger application and user audience. Imagine a network of Indy workstations that use their local graphics acceleration for most interactive tasks, but can fallback to GLR on a RealityEngine or InfiniteReality for extremely high-quality rendering.
This documents (last updated 2/15/96) hails from http://reality.sgi.com/employees/mjk_asd/onyx_on_an_indy.html
-- always reference the above link, for the most current, up-to-date
version of this page.
Render serving with GLR is a new application market for Onyx machines with InfiniteReality and RealityEngine graphics. GLR makes it possible to amoritize the cost of an Onyx across a group of users on a network by providing OpenGL rendering as a networked service. Here are set of 30 frequently asked questions about GLR (last updated, May 10, 1996).
From the "Opener":
Because OpenGL is window-system independent (the OpenGL API can work just as well for X as it does for Windows NT or OS/2), an OpenGL program uses the window management functions of its host window system. In the ``red'' book, OpenGL examples were presented using the AUX library. AUX is a window-system independent toolkit for using OpenGL. The AUX interface lets you open a single window, render OpenGL, and handle basic input, but that is about the extent of its functionality. It's good for examples but not appropriate for anything much more sophisticated.
Two alternatives to AUX are using Motif or Xlib to write your OpenGL applications. Either alternative works. In practice, Motif is likely to be the window system API most X programmers will use for sophisticated OpenGL applications. Unfortunately, both Motif and Xlib are rather complex. Many programmers wishing to explore 3D graphics with OpenGL will want something in between the toyish feel of AUX and the complexity of Motif or Xlib. That's where this issue's column helps out: supplying a reasonable toolkit to explore OpenGL. Future columns will use the described toolkit to demonstrate specific OpenGL functionality like lighting and texturing.
The toolkit I describe is named GLUT, short for the openGL Utility Toolkit. The API for GLUT is designed to be simple and straightforward. Unlike more complex APIs like Xlib or Motif, very little setup is needed to begin displaying graphics. Also the GLUT API avoids obvious window system dependencies. The intent is that a GLUT program could be recompiled for OS/2 or NT if a GLUT implementation for those window systems was available.
The source in this articles spans pp. 6-10, and is located in: toolbox/src/exampleCode/opengl/GLUT/progs/examples/lightlab.c
Excerpts:
In this column, I use GLUT to demonstrate OpenGL's support for lighting as a technique to improve the realism of OpenGL generated graphics.
When generating 3D graphics on a computer, realism is almost always an underlying goal. If the 3D image is to be effective, it needs to convey a sense of realism to the viewer. Lighting is a means to improve the realism of a 3D scene. . . .
The code in Appendix A is for a GLUT program named lightlab that allows you to change the material and lighting characteristics of a scene containing a teapot, a torus, and an icosahedron. The objects in the scene can be rendered to appear to be made of brass, red plastic, emerald, or slate. Two directional lights coming from the left and right can shine red, white, green, or not at all.... GLUT menus are used to control the various lighting parameters. The program's source code is a good start for exploring OpenGL lighting features.
The source in this article spans pp. 6-10, and is located in: toolbox/src/exampleCode/opengl/GLUT/progs/examples/mjkwarp.c
Excerpts:
An important technical reason behind OpenGL's success is its required support of advanced rendering features like texture mapping. The focus of this issue's column is to explain texture mapping for OpenGL. Like previous columns, the OpenGL Utility Toolkit (GLUT) is used in the column's example program.
[Topics explored include:]
mjkwarp example program listed at the end
of the article demonstrates using texture mapping to rotate,
contort, and shatter a 2D image, all while the image
spins. The effects are reminiscent of MTV video effects. The
point of these effects is to demonstrate a few of the possibilities
texture mapping permits. Figure 4 shows mjkwarp
in its various texturing modes:
The source in this article spans pp. 5-10, and is located in: toolbox/src/exampleCode/opengl/GLUT/progs/examples/blender.c
Excerpts:
This month's column continues to survey OpenGL rendering features [and] is about OpenGL's blending operations for effects like translucency, antialiasing, and atmospheric effects like fog.
[Topics explored include:]
The source in this article spans pp. 5-10, and is located in: toolbox/src/exampleCode/opengl/GLUT/progs/examples/origami.c
Excerpts:
Previous OpenGL columns surveyed interesting aspects of OpenGL's core rendering functionality. This column is different; it focuses on how OpenGL implementations are being extended for even better rendering functionality.
[Topics explored include:]
origami program
works by modeling the paper airplane using eight polygons as
pictured in Figure 1. The program then translates and rotates
these polygons to animate the folding and unfolding of the paper
plane. The airplane polygons are rendered in a single color,
so outlines around each polygon help delineate the folds and
edges of the airplane.
Excerpts:
The last five OpenGL columns discussed OpenGL programming techniques and explained source code examples. This feature article is not about programming, but instead explores the ways graphics hardware can accelerate OpenGL rendering. The intent is to provide you with enough knowledge about 3D graphics hardware architecture to evaluate and select the right graphics hardware for your needs and budget.
[Topics explored include:]
The source in this article spans pp. 5-8, and is located in: toolbox/src/exampleCode/opengl/GLUT/progs/inventor/glutduck.c++
Excerpts:
[First page focused on OpenGL's ubiqutous presence at SIGGRAPH '95, which "made it clear that OpenGL is the standard for interactive computer graphics."]
[T]his column focuses on the relationship between OpenGL and Open Inventor and how the two graphics libraries interact. This column's example program demonstrates how to use Open Inventor with the OpenGL Utility Toolkit (GLUT).
[Topics explored include:]
The source in this article spans pp. 6-8, and is located in: toolbox/src/exampleCode/opengl/GLUT/progs/examples/molehill.c
This issue's topic is rendering curves and surfaces using OpenGL.
[Topics explored include:]
Excerpts:
The long-term benefits -- that every major X vendor has now embraced OpenGL, the fastest standard 3D graphics interface available -- are enormous.
Abstract:
OpenGL's window system support for the X Window System explicitly allows implementations to support direct rendering of OpenGL commands to the graphics hardware. Rendering directly to the hardware avoids the overhead of packing and relaying protocol requests to the X server inherent in indirect rendering.
The OpenGL implementation available for Silicon Graphics workstations supports direct rendering using virtualizable graphics hardware in conjuction with the kernel and X server. The techniques described provide "maximum performance" rendering for OpenGL. Some of the issues are specific to OpenGL, but most of the techniques described are appropriate for the implementation of any high-performance direct rendering graphics interface.
Abstract:
ABSTRACT: To support OpenGL(TM) and PEX rendering within the Silicon Graphics X server without compromising interactivity, we devised and implemented a scheme named multi-rendering. Making minimal changes to the X Consortium sample server's overall structure, the scheme allows independent processes within the X server's address space to perform OpenGL rendering asynchronously to the X server's main thread of execution. The IRIX operating system's process share group facility, user-level and pollable semaphores, and support for virtualized direct access rendering are all leveraged to support multi-rendering. The Silicon Graphics implementation of PEX also uses the multi-rendering facility and works by converting rendering requests into OpenGL commands. Mutli-rendering is contrasted with other schemes for improving server interactivity. Unlike co-routines, multi-rendering supports multi-processing; unlike multi-threading, multi-rendering requires minimal locking overhead.
Abstract:
The OpenGL graphics system is a high-performance, window system independent 2D and 3D graphics interface. The technology was developed by Silicon Graphics and is now controlled by the OpenGL Architecture Review Board. OpenGL's GLX extension integrates OpenGL with the X Window System. This article describes OpenGL's functionality and how it is used with X. A simple OpenGL program using Xlib is presented. OpenGL is compared and contrasted with PEX, a 3D graphics interface designed specifically for X. The two subsequent articles in this series describe how to integrate OpenGL with Xlib and Motif programs.
Abstract:
This is the second article in a three-part series about using the OpenGL graphics system and the X Window System. A moderately complex OpenGL program for X is presented. Depth buffering, back-face culling, lighting, display list modeling, polygon tessellation, double buffering, and shading are all demonstrated. The program adheres to proper X conventions for colormap sharing, window manager communication, command line argument processing, and event processing. After the example, advanced X and OpenGL issues are discussed including minimizing colormap flashing, handling overlays, using fonts, and performing animation. The last article in this series discusses integrating OpenGL with the Motif toolkit.
Abstract:
The OpenGL graphics system can be integrated with the industry-standard OSF/Motif user interface. This article discusses how to use OpenGL within a Motif application program. There are two approaches to using OpenGL with Motif. One is to render into a standard Motif drawing area widget, but this requires each application window to use a single visual for its window hierarchy. A better approach is to use the special OpenGL drawing area widget allowing windows used for OpenGL rendering to pick freely an appropriate visual without affecting the visual choice for other widgets. An example program demonstrates both approaches. The X Toolkit's work procedure mechanism animates the example's 3D paper airplanes. Handling OpenGL errors is also explained.
Topics covered include:
Topics covered include:
Abstract:
Graphics standards are receiving increased attention in the computer graphics community as more people write programs that use 3D graphics and as those already possessing 3D graphical programs want those programs to run on a variety of computers.
OpenGL is an emerging graphics standard that provides advanced rendering features while maintaining a simple programming model. Its procedural interface allows a graphics programmer to describe rendering tasks, whether simple or complex, easily and efficiently. Because OpenGL is rendering-only, it can be incorporated into any window system (and has been, into the X Window System and the soon-to-be-released Windows NT) or can be used without a window system. Finally, OpenGL is designed so that it can be implemented to take advantage of a wide range of graphics hardware capabilities, from a basic framebuffer to the most sophisticated graphics subsystems.
Abstract:
OpenGL is an emerging graphics standard that provides advanced rendering features while maintaining a simple programming model. Because OpenGL is rendering-only, it can be incorporated into any window system (and has been, into the X Window System and a soon-to-be-released version of Windows) or can be used without a window system. An OpenGL implementation can efficiently accommodate almost any level of graphics hardware, from a basic framebuffer to the most sophisticated graphics subsystems. It is therefore a good choice for use in interactive 3D and 2D graphics applications.
We describe how these and other considerations have governed the selection and presentation of graphical operators in OpenGL. Complex operations have been eschewed in favor of simple, direct control over the fundamental operations of 3D and 2D graphics. Higher-level graphical functions may, however, be built from OpenGL's low-level operators, as the operators have been designed with such layering in mind.
CR Categories and Subject Descriptors: I.3.3 [Computer Graphics]: Picture/Image Generation; I.3.7 [Computer Graphics]: Three-Dimensional Graphics and Realism
OR, ...