HP Workstation zx2000, Workstation zx6000 Implementation Manual

OpenGL implementation guide

for HP-UX 11.X (IPF version)

Document Part Number: 5969-3152

june 2003

© 2003 Hewlett-Packard Company

ATI™ is used under license and are registered trademarks of ATI Technologies Inc. in the United States and other
countries.

UNIX® is a registered trademark of The Open Group.
Intel® Itanium™ Processor Family is a trademark of Intel Corporation in the U.S. and other countries and is used

under license.
X/Open® is a registered trademark, and the X device is a trademark of X/Open Company Ltd. in the UK and

other countries.
Hewlett-Packard Company shall not be liable for technical or editorial errors or omissions contained herein or for

incidental or consequential damages in connection with the furnishing, performance, or use of this material. The
information in this document is provided “as is” without warranty of any kind, including, but not limited to, the
implied warranties of merchantability and fitness for a particular purpose, and is subject to change without notice.
The warranties for HP products are set forth in the express limited warranty statements accompanying such
products. Nothing herein should be construed as constituting an additional warranty.

This document contains proprietary information that is protected by copyright. No part of this document may be
photocopied, reproduced, or translated to another language without the prior written consent of Hewlett-Packard
Company.

WARNING: Text set off in this manner indicates that failure to follow directions could result in bodily

Å

harm or loss of life.

CAUTION: Text set off in this manner indicates that failure to follow directions could result in damage to

Ä

equipment or loss of information.

OpenGL implementation guide
for HP-UX 11.X (IPF version)
First Edition (june 2003)

Document Part Number: 5969-3152

contents

1 overview of OpenGL

introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–1

the OpenGL product. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–1

hp’s implementation of OpenGL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–2

standard OpenGL product . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–6

mixing of OpenGL and Xlib . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–7

gamma correction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–7

OpenGL extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–8

draw array set extension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–8

3D texture extension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–8

occlusion extension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–12

visibility test extension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–14

texture autogen MIPmap extension. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–16

X Window extensions for hp’s implementation of OpenGL. . . . . . . . . . . . . . . . . . . . . . . . . . . 1–16

rendering details. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–19

default visuals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–19

EXP and EXP2 fogging. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–19

vertices outside of a begin/end pair. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–19

index mode dithering. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–19

environment variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–20

2 installation and setup

verification instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–1

is your system software preloaded with instant ignition? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–1

verify that OpenGL is on your workstation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–1

installing OpenGL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–2

1. read this entire procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–2

2. install OpenGL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–2

3. check log file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–3

4. verify the product. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–3

the OpenGL file structure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–3

3 running OpenGL programs

virtual GLX (VGL) mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–1

visual support for the VGL mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–1

special considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–1

running hp's implementation of the OpenGL stereo application . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–2

OpenGL Implementation Guide iii

Contents

4 compiling and linking programs

overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–1

including header files. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–2

linking shared libraries. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–2

compiling 32-bit and 64-bit applications for OpenGL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–3

OpenGL procedure calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–3

5 programming hints

OpenGL correctness hints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–1

4D values. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–1

texture coordinates. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–1

OpenGL performance hints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–1

display list performance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–2

texture downloading performance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–5

selection performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–5

state change . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–5

optimization of lighting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–6

occlusion culling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–6

high frame rate applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–6

rescaling normals. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–7

iv OpenGL Implementation Guide

OpenGL is a hardware-independent application programming interface (API) that provides an
interface to graphics operations. HP’s implementation of OpenGL converts API commands to
graphical images via hardware and/or software functionality.

The information in this manual is valid only for OpenGL on IPF. For information on OpenGL on
PA-RISC, refer to the PA-RISC version of the OpenGL Implementation Guide.

introduction

The OpenGL interface consists of a set of commands that allow applications to define and
manipulate three-dimensional objects. The commands include:

■ geometric primitive definitions

■ viewing operations

■ lighting specifications

■ primitive attributes

1

overview of OpenGL

■ pipeline control

■ rasterization control

OpenGL has been implemented on a large number of vendor platforms where the graphics
hardware supports a wide range of capabilities (for example, frame buffer only devices, fully
accelerated devices, devices without a frame buffer, and so on).

For more information on OpenGL, refer to these documents, published by Addison-Wesley and
shipped with HP’s implementation of OpenGL:

■ OpenGL Programming Guide

Instruction on programming in OpenGL, offered in a tutorial format.

■ OpenGL Reference Manual

A reference that contains details on all standard OpenGL functions, as well as utility (GLU)
functions and X Window (GLX) functions.

■ OpenGL Programming for the X Window System

Instruction on interfacing OpenGL with the X Window system.

the OpenGL product

This section provides information about HP’ s implementation of the OpenGL product, as well as
information about the standard OpenGL product.

OpenGL implementation guide 1–1

overview of OpenGL

hp’s implementation of OpenGL

Topics covered in this section are:

■ HP’s implementation of the OpenGL libraries

■ supported graphics devices

■ supported visuals

■ visual support for other graphics devices

■ buffer sharing between multiple processes

■ support for 64-bit programming

■ support for threads

hp’s implementation of the OpenGL libraries

The OpenGL product does not support archived libraries.
HP’s implementation of OpenGL provides the following libraries:

■ libGL.so.2: Stub library that loads the appropriate rendering library

■ libXfGL.so.2: OpenGL library for use with XFree86

■ libGLU.so.2: OpenGL utilities library

There are two sets of libraries:

■ The path for the 32-bit libraries is:

/opt/graphics/OpenGL/lib/hpux32

■ The path for the 64-bit libraries is:

/opt/graphics/OpenGL/lib/hpux64

supported graphics devices

The graphics devices that support OpenGL on IPF are ATI™ Fire GL4, ATI FireGL X1, and ATI
FireGL Z1.

1–2 OpenGL implementation guide

supported visuals

In this section, each visual table will have a graphics device associated with it. For information
on visual support for graphics devices not in the above list, read the subsequent section “visual

support for other graphics devices” on page 1-4.

Visual Table for ATI Fire GL4

X Visual Information OpenGL GLX Information

overview of OpenGL

Class Depth Color

Map
Size

Buffer
Size

Overlay=1
or

Image=0

RGBA=1
or
Index=0

Double
Buffer

# Aux.
Buffers

Color
Buffer

Stencil Accumulation

Buffer

RGBA Z R G B A

PseudoColor 8 256 8 1 0 0 0 0000 0 0 0 0 0 0

PseudoColor 8 256 8 1 0 1 0 0000 0 0 0 0 0 0

TrueColor 24 256 24 0 1 0 0 8880 24 4 16 16 16 0

TrueColor 24 256 24 0 1 1 0 8880 24 4 16 16 16 0

TrueColor 24 256 32 0 1 0 0 8888 24 4 16 16 16 16

TrueColor 24 256 32 0 1 1 0 8888 24 4 16 16 16 16

Visual Table for ATI FireGL X1 and ATI FireGL Z1

X Visual Information OpenGL GLX Information

Class Depth Color

Map
Size

Buffer
Size

Overlay=1
or

Image=0

RGBA=1
or
Index=0

Double
Buffer

# Aux.
Buffers

Color
Buffer

Stencil Accumulation

Buffer

PseudoColor 8 256 8 1 0 0 0 0000 0 0 0 0 0 0

PseudoColor 8 256 8 1 0 1 0 0000 0 0 0 0 0 0

TrueColor 24 256 24 0 1 0 0 8880 24 8 16 16 16 0

TrueColor 24 256 24 0 1 1 0 8880 24 8 16 16 16 0

TrueColor 24 256 32 0 1 0 0 8888 24 8 16 16 16 16

TrueColor 24 256 32 0 1 1 0 8888 24 8 16 16 16 16

OpenGL implementation guide 1–3

RGBA Z R G B A

overview of OpenGL

stereo visual support for ATI Fire GL4

When a monitor is configured in a stereo capable mode, ATI Fire GL4 will have the following
additional stereo visuals available. For more information on OpenGL stereo, read the section

“running hp's implementation of the OpenGL stereo application” on page 3-2.

Stereo Visual Support for ATI Fire GL4

X Visual InformationOpenGL GLX Information

Class Depth Color

Map
Size

Buffer
Size

Overlay=1
or

Image=0

RGBA=1
or
Index=0

Double
Buffer

Stereo # Aux.

Buffers

Color Buffer Stencil Accumulation

Buffer

RGBAZ R G B A

TrueColor 24 256 24 0 1 1 1 0 8 8 8 0 24 4 16 16 16 0

TrueColor 24 256 32 0 1 1 1 0 8 8 8 8 24 4 16 16 16 16

stereo visual support for ATI Fire GL4

Stereo is not supported in the initial release of the FireGL X1/Z1 driver. It will be supported in a
future release.

visual support for other graphics devices

The OpenGL product can also be used with the Virtual Memory Driver (VMD) in Virtual GLX
mode (VGL). VMD allows you to use many X11 dra wables (local or remote) as “virtual de vices”
for three-dimensional graphics with OpenGL. This includes rendering to X terminals and other
non-GLX extended X Servers.

Visual Table for VMD/VGL

X Visual Information OpenGL GLX Information

Class Depth Color

Map
Size

Buffer
Size

Overlay=1
or Image=0

RGBA=1
or
Index=0

Double
Buffer

# Aux.
Buffers

Color Buffer Stencil Accumulation

Buffer

RGBA Z R G B A

PseudoColor 8 256 8 0 0 * 0 0000 24 4 0 0 0 0

PseudoColor 8 256 8 0 0 * 0 0000 0 0 0 0 0 0

TrueColor 8 256 8 1 1 * 0 3320 24 4 16 16 16 0

TrueColor 24 256 24 0 1 * 0 888** 24 4 16 16 16 16

*Double buffering is set to True (1) if the X visual supports the X double-buffering extension (DBE).
**Alpha will only work correctly on 12- and 24-bit TrueColor and DirectColor visuals when the X Server does not use the
high-order nybble/byte in the X visual. Also, note that when alpha is present, Buffer Size will be 16 for the 12-bit visuals
and 32 for the 24-bit visuals.

1–4 OpenGL implementation guide

threads support

OpenGL supports Level 2 threads. This means HP OpenGL can be used in threaded applications,
and more than one thread can use OpenGL.

Using OpenGL graphics in a kernel threaded application requires that the application link with
libpthread.so (not the archived version, libpthread.a).

OpenGL libraries are not cancel safe or fork safe.
A given context can only be current in one thread at a time.
Enable your X11 library to use threads by calling XInitThreads () in your program. An example

of a threaded OpenGL program is given in /opt/graphics/OpenGL/demos/threads.

additional documentation

For more information on using threads, see the following documentation:

■ The http://docs.hp.com Web site (search for “Threads” and “Multiprocessing”)

■ The OpenGL Programming Guide

■ The OpenGL Reference Manual

■ Threadtime by S. Norton and M. Dipasquale

overview of OpenGL

OpenGL implementation guide 1–5

overview of OpenGL

64-bit programming

For information on porting your application to take advantage of 64-bit capabilities, see the

http://docs.hp.com

64-bit OpenGL allows “large data space” because the pointers are now 64-bit. But, the OpenGL
data types themselves are the same as the 32-bit library. For example, GLint is a 32-bit integer,
not a 64-bit long.

All 64-bit OpenGL libraries are located in /opt/graphics/OpenGL/lib/hpux64. The
following sample compile and link lines may help you to build your application once it has been
ported to take advantage of 64-bit capabilities:

Sample 32-bit compile and link:

cc -Ae -I/opt/graphics/OpenGL/include \

-I/usr/include/X11R6 -o cube.32 cube.c \

-L/opt/graphics/OpenGL/lib/hpux32 \

-L/usr/lib/hpux32/X11R6 -lGLU -lGL -lXhp11 -lXext -lX11 -lm

Sample 64-bit compile and link:

cc -Aa +DD64

-I/opt/graphics/OpenGL/include -I/usr/include/X11R6 -o cube.64 \
cube.c -L/opt/graphics/OpenGL/lib/hpux64 \

-L/usr/lib/hpux64/X11R6 -L/usr/lib/hpux64 -L/usr/lib \

-lGLU -lGL -lXhp11 -lXext -lX11 -lm

Web site. Search for “64-bit Computing” to find the topic on “Porting.”

standard OpenGL product

This section covers the following topics:

■ the OpenGL utilities library (GLU)

■ input and output routines

■ the OpenGL extensions for the X Window system (GLX)

OpenGL Utilities Library (GLU)

The OpenGL Utilities Library (GLU) provides a useful set of drawing routines that perform such
tasks as:

■ generating texture coordinates

■ transforming coordinates

■ tessellating polygons

■ rendering surfaces

■ providing descriptions of curves and surfaces (NURBS)

■ handling errors

For a detailed description of these routines, refer to the Reference section or the OpenGL

Reference Manual.

input and output routines

OpenGL was designed to be independent of operating systems and window systems, therefore, it
does not have commands that perform such tasks as opening a window. To obtain these
capabilities, you will need to use X Windows routines (those whose names start with “glX”).

1–6 OpenGL implementation guide

the OpenGL extensions for the X Window system (GLX)

HP’s OpenGL implementation currently supports version 1.2 of the glx extension.
The OpenGL Extension to the X Window System (GLX) provide routines for:

■ choosing a visual

■ managing the OpenGL rendering context

■ off-screen rendering

■ double buffering

■ using X fonts

For a detailed description of these routines, refer to the Reference section or the OpenGL

Reference Manual.

mixing of OpenGL and Xlib

The OpenGL implementation conforms to the specification definition for mixing Xlib and
OpenGL rendering to the same drawable. The following points should be considered when
mixing Xlib and OpenGL:

overview of OpenGL

■ OpenGL and Xlib renderers are implemented through separate pipelines and control streams.

Thus, rendering synchronization must be performed as necessary by the user’s application
via the GLX glXWaitX() and glXWaitGL() function calls.

■ Xlib rendering does not affect the Z-buffer, so rendering in X and then OpenGL w ould result

in the OpenGL rendering replacing the Xlib rendering. This is true if the last OpenGL
rendering to the Z-buffer at that location resulted in the depth test passing. Xlib rendering is
always to the visible buffer (front buffer).

Note that mixing Xlib rendering with OpenGL rendering as well as with VMD, when using alpha
buffers, can produce unexpected side effects and should be avoided.

gamma correction

Gamma correction is used to alter hardware colormaps to compensate for the non-linearities in
the phosphor brightness of monitors. Gamma correction can be used to improve the “ropy” or
modulated appearance of antialiased lines. Gamma correction is also used to improve the
appearance of shaded graphics images, as well as scanned photographic images that have not
already been gamma corrected. A utility for adjusting the display’s gamma correction is pro vided
at /opt/graphics/common/bin/gamma.

For details on this feature, read the section “Gamma Correction” found in the Graphics

Administration Guide.

OpenGL implementation guide 1–7

overview of OpenGL

OpenGL extensions

The extensions listed in this section are extensions that HP has created; that is, in addition to
those standard functions described in the OpenGL Programming Guide, OpenGL Reference
Manual, and OpenGL Programming for the X Window System.

draw array set extension

For additional information, see Chapter 5, “programming hints.”

3D texture extension

The 3D-texture extension is useful for volumetric rendering of solid surfaces such as a marble
vase, or for rendering images where geometric alignment is important (such as an MRI medical
image). For this extension, the texture maps ha ve width and height as the y did for 2D, b ut also an
additional dimension depth not included in 2D. The third coordinate forms a right-handed
coordinate system, as the following illustration shows.

r (depth)

t (height)

s (width)

Right-Handed Coordinate System for 3D Texturing

Each MIPmap level consists of a block of data (see Each MIPmap is a Block in 3-D Texturing
below). Each MIPmap level of the texture map is treated as being arranged in a sequence of
adjacent rectangles. Each rectangle is a 2-dimensional image, so each MIPmap level is a (2m +
2b) (2n + 2b) (2l + 2b) block where b is a border width of either 0 or 1, and m, n and l are
non-negative integers.

Each MIPmap is a Block in 3-D Texturing

1–8 OpenGL implementation guide

GL_LINEAR_MIPMAP_LINEAR Filtering may use Two Blocks

Enumerated Types for 3D Texturing

Extended Area Enumerated Type Description

overview of OpenGL

Pixel Storage GL_[UN]PACK_IMAGE_HEIGHT_EXT

Default: 0 for each

Pixel Storage GL_[UN]PACK_SKIP_IMAGES_EXT

Default: 0 for each

Texture Wrap Modes GL_TEXTURE_WRAP_R_EXT

Default: GL_REPEAT

Enable/Disable GL_MAX_3D_TEXTURE_SIZE_EXT,

GL_TEXTURE_BINDING_3D_EXT
Default: N/A

Get Formats GL_MAX_3D_TEXTURE_SIZE_EXT,

GL_TEXTURE_BINDING_3D_EXT
Default: N/A

Proxy GL_PROXY_TEXTURE_3D_EXT

Default: N/A

steps for 3D texturing programming

To use the 3D texture extension (see sample program below):

1. Enable the 3D texture extension using glEnable(GL_TEXTURE_3D_EXT);

The height of the image from which the
texture is created; it supersedes the value of
the height passed into glTexImage3DEXT.

The initial skip of contiguous rectangles of
the texture.

The wrap mode applied to the r texture
coordinate.

The method to enable/disable 3D
texturing.

The maximum size of the 3D texture
allowed; bind query

The proxy texture that can be used to query
the configurations.

2. Create a 3D texture using glTexImage3DEXT;

3. Specify or generate the s, t and r texture coordinates using glTexGen or glTexCoord3*;

4. Specify other parameters such as filters just as you would for 2D texturing, but use
GL_TEXTURE_3D_EXT for the target.

OpenGL implementation guide 1–9

overview of OpenGL

3D texture program fragments

This program draws four layers in the base MIPmap level, and a diagonal slice through the base
MIPmap level.

/* Allocate texture levels separately, then concat to get 3D
texture */

GLubyte texture1[TEXTURE_WIDTH][TEXTURE_HEIGHT][4];
GLubyte texture2[TEXTURE_WIDTH][TEXTURE_HEIGHT][4];
GLubyte texture3[TEXTURE_WIDTH][TEXTURE_HEIGHT][4];
GLubyte texture4[TEXTURE_WIDTH][TEXTURE_HEIGHT][4];
GLubyte
textureConcat[TEXTURE_DEPTH][TEXTURE_WIDTH][TEXTURE_HEIGHT][4];

/* The checkerPattern procedure fills a texture of width and
height with a period of Checker_period alternating between
firstColor and secondColor, Texture should be declared prior to
calling checkerPattern. */

static void checkerPattern(int width, int height,
GLubyte *firstColor,
GLubyte *secondColor,
GLubyte *texture,
int Checker_period)
{

int texelX, texelY;
int index, fromIndex;
GLubyte *p = texture;

index = 0;
for (texelY = 0; texelY < height; texelY++) {
for (texelX = 0; texelX < width; texelX++) {
if (((texelX/Checker_period)% 2) ^
((texelY/Checker_period)% 2)) {
*p++ = firstColor[0]; /* red */
*p++ = firstColor[1]; /* green */
*p++ = firstColor[2]; /* blue */
*p++ = firstColor[3]; /* alpha */
} else {
*p++ = secondColor[0]; /* red */
*p++ = secondColor[1]; /* green */
*p++ = secondColor[2]; /* blue */
*p++ = secondColor[3]; /* alpha */
}
}
}

GLubyte blackRGBA[] = {0.0, 0.0, 0.0, 255.0};
GLubyte whiteRGBA[] = {255.0, 255.0, 255.0, 255.0};
GLubyte redRGBA[] = {255.0, 0.0, 0.0, 255.0};
GLubyte greenRGBA[] = {0.0, 255.0, 0.0, 255.0};
GLubyte blueRGBA[] = {0.0, 0.0, 255.0, 255.0};
GLubyte yellowRGBA[]= {255.0, 255.0, 0.0, 255.0};

1–10 OpenGL implementation guide

overview of OpenGL

GLubyte purpleRGBA[]= {255.0, 0.0, 255.0, 255.0};
GLubyte cyanRGBA[]= {0.0, 255.0, 255.0, 255.0};
GLubyte greyRGBA[] = {125.0, 125.0, 125.0, 255.0};

main(int argc, char *argv[]) {
/* Open window for displaying.Put your favorite code here to open
a window and perform perspective setup */

glEnable(GL_TEXTURE_3D_EXT);
checkerPattern(TEXTURE_WIDTH, TEXTURE_HEIGHT,
blueRGBA, whiteRGBA, &texture1[0][0][0], 4);
checkerPattern(TEXTURE_WIDTH, TEXTURE_HEIGHT,
redRGBA, yellowRGBA, &texture2[0][0][0], 4);
checkerPattern(TEXTURE_WIDTH, TEXTURE_HEIGHT,
greenRGBA, blackRGBA, &texture3[0][0][0], 4);
checkerPattern(TEXTURE_WIDTH, TEXTURE_HEIGHT,
purpleRGBA, cyanRGBA, &texture4[0][0][0], 4);

/* create a 3D texture, textureConcat, which has a different
checker pattern at each depth */

memcpy(&textureConcat[0][0][0], texture1, sizeof(texture1));
memcpy(&textureConcat[1][0][0], texture2, sizeof(texture2));
memcpy(&textureConcat[2][0][0], texture3, sizeof(texture3));
memcpy(&textureConcat[3][0][0], texture4, sizeof(texture4));

glTexParameterf(GL_TEXTURE_3D_EXT, GL_TEXTURE_WRAP_S, GL_CLAMP);
glTexParameterf(GL_TEXTURE_3D_EXT, GL_TEXTURE_WRAP_T, GL_CLAMP);
glTexParameterf(GL_TEXTURE_3D_EXT, GL_TEXTURE_WRAP_R_EXT,
GL_CLAMP);
glTexParameterf(GL_TEXTURE_3D_EXT, GL_TEXTURE_MAG_FILTER,
GL_NEAREST);
glTexParameterf(GL_TEXTURE_3D_EXT, GL_TEXTURE_MIN_FILTER,
GL_NEAREST);
glTexImage3DEXT(GL_TEXTURE_3D_EXT, 0, GL_RGBA, TEXTURE_WIDTH,
TEXTURE_HEIGHT, TEXTURE_DEPTH, 0, GL_RGBA, GL_UNSIGNED_BYTE,
&textureConcat);

/* Fill a quad with depth of r = 0.125, passed into glTexCoord
for every vertex. */ Add your quad code here

/* Fill a quad with depth of r = 0.375, passed into glTexCoord
for every vertex. */ Add your quad code here

/* Fill a quad with depth of r = 0.625, passed into glTexCoord
for every vertex. */ Add your quad code here

/* Fill a quad with depth of r = 0.875, passed into glTexCoord
for every vertex. */ Add your quad code here

/* Now get a slice across the quad. Here’s some quad code for a
sample. Make sure you have appropriate viewing perspectives. */

glBegin(GL_QUADS);
glNormal3f(0., 0., 1.);
glTexCoord3f(0.0, 0.0, 0.0);
glVertex3f(0.5, 0.5, 0.);
glNormal3f(0., 0., 1.);
glTexCoord3f(0.0, 1.0, 0.0);

OpenGL implementation guide 1–11

overview of OpenGL

glVertex3f(0.5, 62.5, 0.);
glNormal3f(0., 0., 1.);
glTexCoord3f(1.0, 1.0, 1.0);
glVertex3f(62.5, 62.5, 0.);
glNormal3f(0., 0., 1.);
glTexCoord3f(1.0, 0.0, 1.0);
glVertex3f(62.5, 0.5, 0.);
glEnd();

}

The results of code fragments are shown in Results from the 3D Texture Program Fragments
below. This figure shows four layers in the base MIPmap level, and a diagonal slice through the
base MIPmap level.

For more information on 3D texture, see the functions: glTexImage3DEXT,
glTexSubImage3DEXT, glCopyTexSubImage3DEXT, glEnable, glDisable.

occlusion extension

This occlusion culling extension defines a mechanism whereby an application can determine the
non-visibility of some set of geometry based on whether an encompassing set of geometry is not
visible. In general, this feature does not guarantee that the target geometry is visible when the test
fails, but is accurate with regard to non-visibility.

Typical usage of this feature would include testing the bounding boxes of complex objects for
visibility. If the bounding box is not visible, then it is known that the object is not visible and
need not be rendered.

Results from the 3D Texture Program Fragments

1–12 OpenGL implementation guide

occlusion culling code fragments

The following is a sample code segment that shows a simple usage of occlusion culling.

/* Turn off writes to depth and color buffers */
glDepthMask(GL_FALSE);
glColorMask (GL_FALSE, GL_FALSE, GL_FALSE);
/* Enable Occlusion Culling test */
glEnable(GL_OCCLUSION_TEST_HP);
for (i=0; i < numParts; i++) {
/* Render your favorite bounding box */
renderBoundingBox(i);
/* If bounding box is visible, render part */
glGetBooleanv(GL_OCCLUSION_RESULT_HP, &result);
if (result) {
glColorMask(GL_TRUE, GL_TRUE, GL_TRUE);
glDepthMask(GL_TRUE);
renderPart(i);
glDepthMask(GL_FALSE);
glColorMask (GL_FALSE, GL_FALSE, GL_FALSE);
}
}
/* Disable Occlusion Culling test */
glDisable(GL_OCCLUSION_TEST_HP);
/* Turn on writes to depth and color buffers */
glColorMask(GL_TRUE, GL_TRUE, GL_TRUE);
glDepthMask(GL_TRUE);

overview of OpenGL

The key idea behind occlusion culling is that the bounding box is much simpler (that is, fewer
vertices) than the part itself. Occlusion culling provides a quick means to test non-visibility of a
part by testing its bounding box.

It should also be noted that this occlusion culling functionality is very useful for view frustum
culling. If a part’s bounding box is not visible for an y reason (not just because it’s occluded in the
Z-buffer) this test will give correct results.

To maximize the probability that an object is occluded by other objects in a scene, the database
should be sorted and rendered from front to back. Also, the database may be sorted hierarchically
such that the outer objects are rendered first and the inner are rendered last. An example would
be rendering the body of an automobile first and the engine and transmission last. In this way, the
engine would not be rendered due to the bounding box test indicating that the engine is not
visible.

Enumerated Types for Occlusion

Extended Area Enumerated Type Description

Enable.Disable/IsEnabled GL_OCCLUSION_TEST_HP

Default: Disabled

Get* GL_OCCLUSION_TEST_RESULT_HP

Default: Zero (0)

pname variable.

pname variable

For related information, see the functions: glEnable, glDisable, and glIsEnabled.

OpenGL implementation guide 1–13

overview of OpenGL

visibility test extension

The Visibility Test extension provides a way for an application to test whether or not a primitive
or set of primitives are visible against the current contents of the depth buffer. "Visibile" in this
context means that at least one pixel passes the depth test. This differs from previous Occlusion
Culling extensions by allowing the programmer to pro vide memory for many different Visibility
Test results to be returned at the same time. This feature can be used with the
glNextVisibilityTestHP routine in conjunction with the glVisibilityBufferHP routine.

With glVisibilityBufferHP, the programmer specifies a Boolean array in which to store the results
of the visibility tests; a call to glNextV isibilityTestHP finishes the current test (eventually placing
the results of the test in the current position of the array specified by glVisiblityBufferHP), and
beginning the next test, whose results will be placed in the subsequent entry of the array.

Visibility Testing is enabled by a call to glEnable(VISIBILITY_TEST_HP). Making this call to
glEnable (if VISIBILITY_TEST_HP has not already been enabled) causes Visibility Testing to
begin, and sets the result destination to be the first entry in the buffer specified by
glVisibilityBufferHP.

The glNextVisibilityTest function prototype is defined as:

void glNextVisibilityTestHP( void )

The glVisibilityBufferHP function prototype is defined as:

void glVisibilityBufferHP( GLSizei size, GLboolean *buffer,
GLboolean wait_on_get)

glVisibilityBuffer has three arguments: ‘buffer’, ‘size’ and ‘wait_on_get’. 'buffer' is a pointer to
an array of Boolean values, and 'size' indicates the size of the array. 'buffer' returns values of
GL_TRUE or GL_FALSE for each Visibility Test issued. A Visibility Te st begins when a call is
made to glEnable(GL_VISIBILITY_TEST_HP), and ends when a call is made to either
glDisable(GL_VISIBILITY_TEST_HP), or glNextVisibilityTestHP(). When all Visibility Tests
have been performed, glDisable(GL_VISIBILITY_TEST_HP) should be called, followed by a
call to glGet of GL_VISIBILITY_TEST_HP. Calling glGet causes the contents of 'buffer' to be
up to date (based on the value of the 'wait_on_get' parameter, discussed below). A Vi sibility Test
result of GL_TRUE indicates that some portion of the primiti ve(s) rendered during that test were
visible. A value of GL_FALSE indicates that no portion of the primitive(s) rendered during the
test was visible.

The third parameter, 'wait_on_get', is intended to allow for potential optimizations during
Visibility Tests. When Visibility Tests are made, there is often some amount of latency between
the time the request is made and when the answer is available. Once a glGet of
GL_VISIBILITY_TEST_HP is called after glDisable(GL_VISIBILITY_TEST_HP), there will
usually be a short delay (perhaps as much as 50 microseconds) before the answer is available. If
the application would prefer to wait until the Visibility Test results are available before
proceeding, then a value of GL_TR UE should be specif ied for the 'wait_on_get' parameter. If, on
the other hand, the application has some useful work to do during that time, a value of
GL_FALSE can be specified for the 'wait_on_get' parameter, and glGet returns immediately.
However, 'buffer' is not guaranteed to be defined until some time later. To check to see when the
Visibility Test results are complete, the programmer can look at the data returned by a glGet of
GL_VISIBILITY_TEST_HP.

Two Boolean value are returned. The first indicates whether or not GL_VISIBILITY_TEST_HP
is currently enabled. The second indicates if there are any test results pending. If there are no test
results pending, the programmer may conclude that 'buffer' is up to date.

1–14 OpenGL implementation guide

overview of OpenGL

The following is a sample code segment of how the visibility test extension might be used.

#define NUMTESTS 1000
GLboolean

visBuffer[NUMTESTS],
visstuff[2];

glVisibilityBufferHP(NUMTESTS,visBuffer,GL_TRUE);
glEnable(GL_VISIBILITY_TEST_HP);
// We don't actually want to touch the Color or Depth buffers...

glDepthMask(GL_FALSE);
glColorMask(GL_FALSE, GL_FALSE,GL_FALSE,GL_FALSE);

for ( [Each object to be tested] )
{
<Render Object's bounding box>

// Move on to the next test
glNextVisibilityTestHP();

}
glDisable(GL_VISIBILITY_TEST_HP);

glGetBooleanv(GL_VISIBILITY_TEST_HP, visstuff);
// Turn these back on for rendering the objects
glDepthMask(GL_TRUE);

glColorMask(GL_TRUE, GL_TRUE,GL_TRUE,GL_TRUE);
for ( i=0; i < [Num Objects Tested] )

{
if (visBuffer[i] )
{
[ Render the ith Object ]
}
}

OpenGL implementation guide 1–15

overview of OpenGL

texture autogen MIPmap extension

The autogen MIPmap extension introduces a side effect to the modification of the base level
texture map. When enabled, any change to the base-lev el te xture map will cause the computation
of a complete MIPmap stack form for that base level. The internal formats and border widths of
the derived MIPmap will match those of the base map, and the dimensions of the derived
MIPmap follow the requirements set forth in OpenGL for a valid MIPmap. A simple 2 x 2 box
filter is used to generate the MIPmap levels.

Enumerated Types for Autogen MIPmap

Extended Area Enumerated Type Description

Texture Parameter GL_GENERATE_MIPMAP_EXT

Default: GL_FALSE

Enables autogen MIPmap

To use the autogen MIPmap extension, set GL_GENERATE_MIPMAP_EXT to GL_TRUE in
glTexParameter. For example, here is a code fragment that uses this extension:

glTexParameter[if](GL_TEXTURE_2D,GL_GENERATE_MIPMAP_EXT,
GL_TRUE);

For related information on this extension, see the function: glTexParameter.

X Window extensions for hp’s implementation of OpenGL

HP’s implementation of OpenGL includes two GLX extensions that deal with extended GLX
visual information that is not included in the OpenGL 1.1 Standard. These extensions are both
supported by HP’s implementation of the OpenGL API library, but, prior to using them,
glXQueryExtensionsString should be called to verify that the extensions are supported
on the target display.

GLX visual information extension

The GLX_EXT_visual_info extension provides additional GLX visual information and
enhanced control of GLX Visual selection. The enumerated types listed below can be passed to
either glXChooseVisual or glXGetConfig to specify or inquire the visual type or
transparency capabilities.

1–16 OpenGL implementation guide

Enumerated Types for GLX Visual Information

Extended Area Enumerated Types Description

overview of OpenGL

Visual Type GLX_TRUE_COLOR_EXT,

GLX_DIRECT_COLOR_EXT,
GLX_PSEUDO_COLOR_EXT,

Values associated with the
GLX_X_VISUAL_TYPE_EXT

eumerated type
GLX_STATIC_COLOR_EXT*
GLX_GRAY_SCALE_EXT*
GLX_STATIC_GRAY_EXT*
Default: N/A

Visual Transparency
Capabilities

GLX_NONE__EXT,
GLX_TRANSPARENT_RGB_EXT*
GLX_TRANSPARENT_INDEX_EXT

Values associated with the

GLX_TRANSPARENT_TYPE_EXT

enumerated type
Default: GLX_NONE_EXT

*These enumerated types are supported through the GLX client-side API library, but there are currently no HP X Server GLX
visuals with these capabilities. They can still be used to query any Server and will operate properly if connected to a
non-HP server with GLX support for these visual capabilities.

The enumerated types listed below can be used only through glXGetConfig when it is known
that the GLX visual being queried supports transparency or in other words, has a
GLX_TRANSPARENT_TYPE_EXT property other than GLX_NONE_EXT.

Enumerated Types for GLX Visual Transparency

Extended Area Enumerated Types Description

Transparency Index
for PseudoColor
Visuals

GLX_TRANSPARENT_INDEX_VALUE_EXT,
Default: N/A

Returns the Pixel Index for the
transparent color in a
GLX_TRANSPARENT_INDEX_
EXT visual

Transparency
Values for RGBA
Visuals

OpenGL implementation guide 1–17

GLX_TRANSPARENT_RED_VALUE_EXT
GLX_TRANSPARENT_GREEN_VALUE_EXT
GLX_TRANSPARENT_BLUE_VALUE_EXT
GLX_TRANSPARENT_ALPHA_VALUE_EXT
Default: N/A

Returns the RGBA data values
for the transparent color in a
GLX_TRANSPARENT_RGB_EXT
GLX visual (not supported on
HP servers)

overview of OpenGL

GLX_EXT_visual_info program fragments

Note that both of the following segments assume that the GLX_EXT_visual_info extension
exists for dpy, which is a pre-existing display connection to an X Server.

Here is a sample code segment that forces selection of a TrueColor visual.

Display *dpy;
XVisualInfo *vInfo;
int attrList[] = {GL_USE_GL,
GLX_X_VISUAL_TYPE_EXT,
GLX_TRUE_COLOR_EXT,
None};
vinfo = glXChooseVisual(dpy, XDefaultScreen(dpy), &attrList);

The following sample is a code segment that selects an overlay visual with index transparency,
and then obtains the Pixel index for the transparent color.

Display *dpy;
XVisualInfo *visInfo;
int transparentPixel;
int attrList[] = {GL_USE_GL,
GLX_LEVEL, 1,
GLX_TRANSPARENT_TYPE_EXT,
GLX_TRANSPARENT_INDEX_EXT,
None};
visInfo = glXChooseVisual(dpy, XDefaultScreen(dpy), &attrList);
if (visInfo!= NULL) {
glXGetConfig(dpy, visInfo, GLX_TRANSPARENT_INDEX_VALUE_EXT,
&transparentPixel);
}

GLX visual rating extension

The GLX_EXT_visual_rating extension provides additional GLX visual information which
applies rating properties to GLX visuals. The enumerated types listed below can be passed to
either glXChooseVisual, or glXGetConfig to specify or inquire visual rating
information.

Enumerated Types for GLX Visual Rating

Extended Area Enumerated Types Description

Visual rating GLX_NONE_EXT

GLX_SLOW_VISUAL_EXT
GLX_NON_CONFORMANT_VISUAL_EXT
Default: N/A

Note that all current HP GLX visuals are rated as GLX_NONE_EXT. This extension is
implemented for possible future visual support and for use with non-HP servers. Coding to use
the GLX_EXT_visual_rating extension is similar to the segments listed above for the
GLX_EXT_visual_info extension.

1–18 OpenGL implementation guide

Values associated with the
GLX_VISUAL_CAVEAT_EXT
enumerated type

rendering details

This section provides the details for several of HP’s rendering capabilities. These rendering
capabilities range from the way HP implements its default visuals to the way HP deals with the
decomposition of concave quadrilaterals.

default visuals

Instead of placing the default visual in the deepest image buffer, HP puts the default visual in the
overlay planes.

EXP and EXP2 fogging

The V irtual Memory Dri v er’s implementation of fog applies fog per fragment. Hardware devices
implement EXP and EXP2 fog per fragment and linear fog per vertex.

vertices outside of a begin/end pair

HP’s implementation of this specification is indeterminate as defined by the OpenGL standard.

index mode dithering

overview of OpenGL

If dithering is enabled in indexed visuals, 2D functions such as glDrawPixels() and
glBitmap() will not be dithered.

OpenGL implementation guide 1–19

overview of OpenGL

environment variables

Here is a list of environment variables used by HP’s implementation of OpenGL.
HPOGL_FORCE_VGL
This variable can be set to force HP’s Virtual GL (VGL) rendering mode using VMD. This

differs from HPOGL_FORCE_VMD in that the GLX Visual list and other GLX extension
information is not retrieved from the GLX Server extension, but is rather synthesized from
standard X Vi sual information and the capabilities known to exist in VMD.

HPOGL_FORCE_VMD

This variable forces clients to render through the VMD. This variable can be used as a temporary
fix and/or a diagnostic. You should set this variable when a rendering defect in the hardware
device driv er is suspected. When this variable is set, rendering speed will slo w do wn. If rendering
is identical in both hardware and software, then this may indicate a problem in the application
code.

HPOGL_PROMOTE_INDIRECT_CONTEXTS

This variable may be set to force the OpenGL contexts to be direct, if possible, even if the
application specifies indirect contexts. This behavior is similar to some previous HP graphics
devices. Direct contexts generally provide better performance than indirect ones.

HPOGL_LOG_FRAME_RATE

This variable may be set to print the frame rate once every second for double-buffered
applications.

HPOGL_DISABLE_TRANSPARENT_VISUALS

This variable may be set to turn off transparent visuals.

1–20 OpenGL implementation guide

installation and setup

If you are setting up a new workstation, all software is preloaded for you if you purchased the
Instant Ignition option. A subsequent section will explain how to determine if OpenGL has been
installed. If you did not order Instant Ignition, then you will need to install the OpenGL filesets.

For HP-UX 11.X, the box containing the “HP-UX 11.0 Install and Core OS” CD-ROM will also
hold a second CD-ROM entitled “HP-UX 11.0 Core Operating Systems Options.” The OpenGL
run time and developer’s products are both available on the HP-UX 11.X Core Operating
Systems Options CD-ROM in the “Graphics and Technical Computing Software” bundle.

verification instructions

This section provides you with the necessary information for determining if your OpenGL
product has been installed.

is your system software preloaded with instant ignition?

Your workstation is preloaded with software, which may include OpenGL, if it was ordered with
the Instant Ignition option. A label attached to the workstation in its shipping carton confirms the
workstation is preloaded:

2

Important

This product contains preloaded software.

Do not initialize internal hard disk drive.

verify that OpenGL is on your workstation

To verify that OpenGL is installed correctly on your system, execute:

/usr/sbin/swlist -l product

This gives you a list of all of the products on the system, and in that product list you will see lines
similar to the following if HP OpenGL has been installed on your system.

OpenGLRun B.11.23.01 HP-UX OpenGL Run Time Environment and
Developers Kit

If OpenGL is not preloaded, you will need to install it by following the steps in the subsequent
sections.

OpenGL implementation guide 2–1

installation and setup

installing OpenGL

Installing the software involves the following steps:

1. Read this entire procedure.

2. Install OpenGL.

3. Check log file.

4. Verify the product.

Each step is described on the subsequent sections.

1. read this entire procedure

Read all of this procedure to ensure the proper installation of your OpenGL product.

2. install OpenGL

After you have installed HP-UX, you can install the OpenGL programming environment.
The X Server is bundled with the HP-UX 11.23 Technical Computing Operating Environment

(TCOE).
If your system is Instantly Ignited, your OpenGL product is already installed. To verify that the

OpenGL developer’s programming environment has been installed on your system, read the
section “Verify that OpenGL is on Your Workstation” above.

If OpenGL is installed, you are done with this section. If OpenGL is not installed, execute this
command (as root):

/usr/sbin/swinstall

...and follow the installation instructions provided in the document Managing HP-UX Software
with SD-UX located at

http://docs.hp.com. OpenGLRunKit and OpenGLDe vKit are the products

to install.
The OpenGL development and run time environment product includes the filesets shown in the

GraphicsOpenGL Run Time Environment Filesets for 11.23 table that follows. To list these

filesets, execute:

/usr/sbin/swlist -l fileset GraphicsOpenGL

GraphicsOpenGL Run Time Environment Filesets for 11.23

GraphicsOpenGL Fileset contains

COMMON-RUN Shared Libraries

OPENGL-DK OpenGL Developer’s Kit

OPENGL-PA OpenGL PA Shared Libraries and Executables

OPENGL-RUN OpenGL Run Time Support Files

2–2 OpenGL implementation guide

3. check log file

After you have completed the installation process, look at /var/adm/sw/swinstall.log.
This file lists the filesets loaded, the customize scripts that ran during the installation process, and
informative messages. Error messages that resulted from attempts to write across an NFS mount
point may appear in this file and, if present, may be ignored.

4. verify the product

Use one of these methods to determine if you have correctly installed OpenGL on your system.

■ Run the program:

/opt/graphics/OpenGL/demos/verify_install-32

or

/opt/graphics/OpenGL/demos/verify_install-64

If OpenGL has been correctly installed on your system, running verify_install will cause a
window containing a 3D rendering of the text “OpenGL” to open on your monitor.

■ Run any of the demos located in the directory:

/opt/graphics/OpenGL/demos

installation and setup

This directory is installed with the OPENGL-DK fileset.
The README file in the exa mpl es directory contains instructions on how to set up and run the

examples.

■ Compile, link and run one of your existing OpenGL programs.

the OpenGL file structure

The OpenGL file structure is compliant with the file structure of the 11.X file systems. Here is a
list of files and directories that are a part of the OpenGL file structure.

/opt/graphics/OpenGL/contrib/libwidget

This directory contains a Motif widget library and source code.

/opt/graphics/OpenGL/include/GL

This directory contains header files needed for OpenGL development.

/opt/graphics/OpenGL/contrib/glut_samples

This directory contains example OpenGL programs that are referenced in the OpenGL
Programming Guide, Second Edition published by Addison-Wesley.

/opt/graphics/OpenGL/contrib/libglut

This directory contains Mark Kilgard’s OpenGL Utility ToolKit (GLUT). This is a
window-system-independent toolkit for writing simple OpenGL programs.

/opt/graphics/OpenGL/lib/hpux32
/opt/graphics/OpenGL/lib/hpux64

These directories contain the run time OpenGL shared libraries.

/usr/lib/hpux32/X11/Xserver/modules/xf86/extensions
/usr/lib/hpux64/X11/Xserver/modules/xf86/extensions

OpenGL implementation guide 2–3

installation and setup

These directories contain extension libraries that are needed to run OpenGL with the X
Server.

/opt/graphics/common/lib/hpux32
/opt/graphics/common/lib/hpux64

These directories contain run time shared libraries that are needed to run OpenGL.

The other libraries you will see in these directories are all drivers for specific graphics devices.
All libdd... are loaded automatically at execution time, contingent upon device type.

2–4 OpenGL implementation guide

running OpenGL programs

This chapter describes V irtual GLX mode, Virtual Memory Driver (VMD), and support of stereo
applications.

virtual GLX (VGL) mode

Virtual GLX (VGL) defines a special transparent mode within HP's implementation of OpenGL
that allows an HP client to render through OpenGL to X Servers and/or X terminals that do not
support OpenGL or the X Server extension for GLX.

This mode is implemented by emulating the X Server extension within the OpenGL API
client-side library and using the hp Virtual Memory Driver (VMD) to perform Xlib rendering.

VGL provides flexibility for OpenGL users, but does not provide the same level of performance
as is available to servers supporting GLX.

visual support for the VGL mode

In VGL mode, the visual capabilities incorporated in glXChooseVisual() and
glXGetConfig() are synthesized from the list of X Visuals supported on the target X Server

and the capabilities of the Virtual Memory Driver (VMD). “supported visuals” on page 1-3 lists
the X V isuals that are supported through the OpenGL Extension to the X W indo w System (GLX)
in the Virtual GLX (VGL) mode.

3

special considerations

When you are in the VGL mode, you will notice the following differences between it and the
GLX mode.

■ VGL deals with X Servers that do not support replicated X visuals that provide extended

GLX capabilities. This results in a GLX visual list that is synthesized from available X
visuals. This list is assigned the maximum set of capabilities supported by the Virtual
Memory Driver (VMD) for each particular visual. For example, if a visual is found to be
supported by the Double-Buffered Extension (DBE), then it will be reported as having the
capability of doing double buffering. Note that there will not be a counterpart for the GLX
visual with the same type and depth that is single buffered. Such visuals are locked to either
single buffer or double b uffer mode, based upon the first access. In V GL, to utilize one visual
for both single and double buffered operation, two separate X display connections must be
opened.

■ OpenGL and Xlib rendering when mixed and sent to the same drawable in VGL mode may

behave diff erently than if a GLX capable X Server were used. This is because in VGL mode
OpenGL rendering is not strictly bounded by the limits of primitives rendered as is the case
when a GLX Server is used. In fact, rendering a single GLX primitiv e can result in repainting
the entire drawable. This means that in the VGL mode it may not be safe to rely upon the fact
that Xlib and OpenGL render to different regions of the draw able. The best way to avoid this
issue is to always perform Xlib rendering after OpenGL rendering.

OpenGL implementation guide 3–1

running OpenGL programs

■ The glReadPixels routine when used in the VGL mode will return only pixel data

rendered via OpenGL. Xlib rendering will not be included.

■ Because of the way VMD works (rendering to a VM buffer and then displaying the images

through X11 protocol), it will behave a bit differently than hardware devices. In particular,
since VMD renders to VM buffers, changes to the X11 windo w will not appear until a b uffer
swap or a glFlush/glFinish.

■ A call to glXSwapBuffers is the only approved way to achieve double buffering for

VGL visuals. Note that calls made to XdbeSwapBuffers will not work correctly.

■ A call can be made to:

Bool hpglXDisplayIsVGL(Display *dpy, int screen)

to determine if a particular display connection is operating in VGL mode. The return value is
"True" if dpy is VGL; otherwise, the v alue returned is "F alse." This is an HP function that is
not available on other implementations of OpenGL.

running hp's implementation of the OpenGL stereo
application

With HP's implementation of OpenGL and the ATI Fire GL4 graphics devices, it is now possible
to run HP's implementation of OpenGL "stereo in a window" mode. The initial release of driv ers
for the ATI FireGL X1 and Z1 graphics devices do not support stereo visuals. The ATI FireGL
X1 and Z1 devices are capable of stereo and support for this functionality will be added in a
future release. "Stereo in a window" affects only OpenGL windows that have been created with
"stereo capable" GLX visuals. The remainder of the X Server screen is rendered in nonstereo
mode without any flickering or color artifacts.

The following steps are required to run HP's implementation of OpenGL "stereo in a window"
mode:

1. Find out if your monitor is currently configured in a mode that supports stereo. This can be
done by running the command:

export DISPLAY=myhost:x.y
/opt/graphics/OpenGL/contrib/xglinfo/xglinfo

The output from xglinfo lists the OpenGL capabilities of the specified X Display, and
includes all GLX visuals that are supported. If one or more of the listed GLX visuals are
marked as stereo capable, then you can proceed to step three.

2. If none of the GLX visuals support stereo, you will need to reconfigure your monitor to a
configuration that supports stereo. Note that you can use the "Monitor Configuration"
component of SAM to reconfigure you monitor.

After successfully reconfiguring your monitor, the X Server needs to be restarted, and you
can verify the availability of GLX stereo visuals by running the xglinfo command again.

3. To select one of the stereo capable GLX visuals through OpenGL, the GLX_STEREO
enumerated type should be passed to either glXChooseVisual() or
glXGetConfig(). Once a stereo visual has been selected, it can be used to create a stereo
window, and glDrawBuffer() can then be called to utilize both the right and left buffers
for rendering stereo images.

3–2 OpenGL implementation guide

This chapter provides information for including header files in your program, linking shared
libraries, compiling 32-bit and 64-bit applications for OpenGL and OpenGL procedure calls.

overview

The table below contains a list of the subdirectories in the directory

/opt/graphics/OpenGL

These subdirectories contain header files and libraries which may be used when compiling and
linking your programs.

Subdirectory Contents

4

compiling and linking programs

include/GL

lib/hpux32

lib/hpux64

lbin

doc

contrib/libwidget

contrib/libglut

contrib/xglinfo

demos

Header files needed for OpenGL development.

32-bit run-time shared libraries.

64-bit run-time shared libraries.

Run-time executables.

OpenGL documentation including reference pages.

A Motif widget library and source code.

Utilities found in the OpenGL Utility Toolkit as mentioned in the
OpenGL Programming for the X Window System manual.

Utility to print display and visual information for OpenGL with the X
Window system.

Sample OpenGL programs, including source code.

OpenGL implementation guide 4–1

compiling and linking programs

including header files

Most OpenGL programs and applications that use only the standard OpenGL data types,
definitions, and function declarations, need include only the header file gl.h. To include this
file, use the following syntax:

#include <GL/gl.h>

Still other header files may be needed by your program, depending on your application. For
example, in order to use the OpenGL extension to X W i ndows (GLX) you must include glx.h,
as shown below.

#include <GL/glx.h>

Instructions for including various additional header files are usually provided with the README
file that accompanies a utility or function. The README also includes instructions for using or
operating the utilities.

Your header file declarations at the beginning of your program should look similar to this:

#include <sys/types.h>
#include <stdio.h>
#include <string.h>
#include <X11/X.h>
#include <X11/Xlib.h>
#include <X11/Xutil.h>
#include <GL/gl.h>
#include <GL/glx.h>

linking shared libraries

OpenGL is supported using shared libraries that must be linked with the application program.
When you compile your OpenGL programs, you must link the application with the OpenGL

library libGL. Notice that the OpenGL library is dependent on the HP X extensions library
(libXext).

An ANSI C compile line will typically look similar to this:

cc -Ae -I/opt/graphics/OpenGL/include \

-I/usr/include/X11R6 -o cube.32 cube.c \

-L/opt/graphics/OpenGL/lib/hpux32 \

-L/usr/lib/hpux32/X11R6 -lGLU -lGL -lXhp11 -lXext -lX11 -lm

To compile your application using ANSI C, you can also use the cc command with either of the
command line options -Aa or -Ae.

If you are going to compile your application using HP’s ANSI C++ compiler, use the aCC
compiler.

See the HP Graphics Administration Guide for more information on compiling.

4–2 OpenGL implementation guide

compiling and linking programs

This table summarizes the shared libraries that are linked on the command line example above.

Shared Libraries

Library Description

libGL OpenGL loader library

libGLU OpenGL utility library

libX11 X11 routines

libXext X11 extensions

libXhp11 HP X11 extension

compiling 32-bit and 64-bit applications for OpenGL

Sample 32-bit compile and link:

cc -Ae -I/opt/graphics/OpenGL/include \

-I/usr/include/X11R6 -o cube.32 cube.c \

-L/opt/graphics/OpenGL/lib/hpux32 \

-L/usr/lib/hpux32/X11R6 -lGLU -lGL -lXhp11 -lXext -lX11 -lm

Sample 64-bit compile and link:

cc -Ae +DD64

-I/opt/graphics/OpenGL/include -I/usr/include/X11R6 \

-o cube.64 cube.c -L/opt/graphics/OpenGL/lib/hpux64 \

-L/usr/lib/hpux64/X11R6 -L/usr/lib/hpux64 -L/usr/lib \

-lGLU -lGL -lXhp11 -lXext -lX11 -lm

OpenGL procedure calls

In order to facilitate maximum performance, the OpenGL library uses a unique procedure calling
convention.

To get the best performance, you must include the gl.h header file supplied with HP’s
implementation of OpenGL in any source code that makes OpenGL calls. Any gl.h files from
other vendors or other sources will produce reduced performance and may not work correctly.

OpenGL implementation guide 4–3

compiling and linking programs

4–4 OpenGL implementation guide

The topics covered in this chapter are intended to give you some helpful programming hints as
you begin to develop your OpenGL applications. Note that these hints are specific to HP’s
implementation of OpenGL. For further information on OpenGL programming hints that are not
HP specific, see Appendix G in the OpenGL Programming Guide and section 6.6 “Maximizing
OpenGL Performance” in the OpenGL Programming for the X Window System manual.

The programming hints in this chapter are covered in these sections:

■ OpenGL correctness hints

■ OpenGL performance hints

OpenGL correctness hints

Hints provided in this section are intended to help you correctly use HP’s implementation of
OpenGL.

4D values

5

programming hints

When specifying 4D values, such as vertices, light positions, and so on, if possible supply a w
value that is not near the floating point limits of MINFLOAT or MAXFLOAT. Using w v alues near
the floating point limits increases the likelihood of floating point precision errors in calculations
such as lighting, transformations, and perspective division.

Also, for best accuracy and performance, normalize your 4D positions such that w is 1.0. For
example, instead of specifying a 4D position like (0.0, 0.0, 5e10, 1.5e38) use the equivalent
normalized position (0.0, 0.0, 3.33e-28, 1.0).

texture coordinates

When using non-orthographic projection, keep in mind the texture coordinates will be divided b y
w as an intermediate calculation. HP’s implementation of OpenGL estimates that for VMD, the
texture coordinates used in perspective projections will have only five significant digits of
precision. Therefore, when you have texturing close to a window edge and the decomposition of
the primitive causes the vertices to ha ve v ery closely-spaced texture coordinates after perspecti v e
projection, you may see loss of texturing precision. This loss of precision may make the texture
primitive seem locally smeared.

OpenGL performance hints

Hints provided in this section are intended to help improve your applications performance when
using HP’s implementation of OpenGL.

OpenGL implementation guide 5–1

programming hints

display list performance

The topics covered here are areas where you can gain substantial improvements in program
performance when using OpenGL display lists. Here is a list of the topics that are covered:

■ geometric primitives

■ GL_COMPILE_AND_EXECUTE mode

■ draw array set extensions

■ textures

■ state changes and their effects on display lists

■ regular primitive data

geometric primitives

Geometric primitives will typically be faster in a display list than by using immediate mode.
Each display list should have numerous primitives to ensure good performance. As a general
rule, larger primitives will be faster than smaller ones. Performance gains here can be dramatic.
For example, it is possible that a single GL_TRIANGLES primitive with 20 or so triangles will
render three times faster than 20 GL_TRIANGLES primitives with a single triangle in each one.

GL_COMPILE_AND_EXECUTE mode

Due to the pre-processing of the display list, and execution performance enhancements, creating
a display list using the GL_COMPILE_AND_EXECUTE mode will reduce program performance.
If you need to improve your programs performance, do not create a display list using the
GL_COMPILE_AND_EXECUTE mode. You will find that it is easier and faster to create the
display list using the GL_COMPILE mode, and then execute the list after it is created.

draw array set extensions

glDrawArraySetHP is a HP OpenGL 1.1 extension to vertex arrays which provides a
high-speed mechanism for rendering multiple primitives. Use of glDrawArraySetHP will be
easy for applications which currently store geometry in vertex arrays and use multiple calls to

glDrawArrays for rendering primitives from the arrays.
glDrawArraySetHP is especially useful when multiple connected primitives, such as

GL_LINE_STRIP, GL_TRIANGLE_STRIP, and so on, are consecutively drawn from a vertex

array. However all OpenGL primitive types are supported.
Since only glDrawArray calls are made while rendering the vertex array set, primitive

attributes, such as material colors, must be established for the entire array set or changed per
vertex. If OpenGL library calls other than glDrawArrays are required during rendering the set
to properly draw the array set, then glDrawArraySetHP is not appropriate.

benefits of glDrawArraySetHP

glDrawArrays and glDrawArraySetHP provide basically the same programmatic
benefits, that is reduced function calls and less user code. Note that glDrawArraySetHP’s
major benefit is performance. glDrawArraySetHP provides from 10%-55% performance
advantage over using glDrawArrays alone.

5–2 OpenGL implementation guide

programming hints

The amount of performance benefit depends upon several factors, including the number of
primitives in the set, the length of the primiti ves in the set, and maximum rendering speed of the
graphics device.

To achieve optimum glDrawArraySetHP rendering performance, group as many primitives
in each set as possible.

using glDrawArraySetHP

To use glDrawArraySetHP, the current vertex array must be set and enabled. This is done
using glNormalPointer, glVertexPointer, glEnableClientState, and so on, or

glInterleavedArrays. After the vertex array is established and enabled,
glDrawArraySetHP may be used.

The C declaration of glDrawArraySetHP is:

void glDrawArraySetHP(GLenum mode,
const GLint* list, GLsizei count);

where:

❏ mode specifies the primitive or primitives that will be created from the vertices. Ten

symbolic constants are accepted: GL_POINTS, GL_LINES, GL_LINE_STRIP,

GL_LINE_LOOP, GL_TRIANGLES, GL_TRIANGLE_STRIP, GL_TRIANGLE_FAN,
GL_QUADS, GL_QUAD_STRIP, and GL_POLYGON.

textures

❏ list is a sequence of starting indices in the enabled arrays. Each index is the start of a

primitive in the set. The final value in the sequence indexes the end of the set. The total
number of indices is count+1.

❏ count is the number of primitives in the set to render.

When glDrawArraySetHP is called, it iterates over count + 1 vertex array indices from list.
Each index uses list[i+1] - list[i] sequential elements from each enabled array to
construct a sequence of geometric primitives, beginning with element list[i].

Calling glDrawArraySetHP(mode, list, count) is functionally equivalent to:

for (i = 0; i < count; i++)
glDrawArrays(mode, list[i], list[i+1]- list[i]);

If calls to glTexImage are put into a display list, they may be cached. In general, for best
performance, use Array Sets and Arrays, Display, and Immediate Mode (Vertex API). Note that
if you are going to use the same texture multiple times, you may gain better performance if you
put the texture in a display list. Another solution would be to use texture objects. Since 3D
textures can potentially become very large, they are not cached.

OpenGL implementation guide 5–3

programming hints

state changes and their effects on display lists

If there are several state changes in a row, it is possible, in some circumstances, for the display
list to optimize them.

It is more efficient to put a state change before a glBegin, than after it. For example, this is
always more efficient:

glColor3f(1,2,3);
glBegin(GL_TRIANGLES);
glVertex3f(...);
... many more vertices...
glEnd();

than this:

glBegin(GL_TRIANGLES);
glColor3f(1,2,3);
glVertex3f(...);
... many more vertices...
glEnd();

For performance efficiency avoid glMaterial state changes, especially within a
glBegin/glEnd pair.

regular primitive data

If the vertex data that you give to a display list is regular (that is, every vertex has the same data
associated with it), it is possible for the display list to optimize the primitive much more
effectively than if the data is not regular.

For example if you wanted to give only a single normal for each face in a GL_TRIANGLES
primitive, the most intuitive way to get the best performance would look like this:

glBegin(GL_TRIANGLES);
glNormal3fv(&v1);
glVertex3fv(&p1); glVertex3fv(&p2); glVertex3fv(&p3);
glNormal3fv(&v2);
glVertex3fv(&p4); glVertex3fv(&p5); glVertex3fv(&p6);
...
glEnd();

In immediate mode, this would give you the best performance. However, if you are putting these
calls into a display list, you will get much better performance by duplicating the normal for each
vertex, thereby giving regular data to the display list:

glBegin(GL_TRIANGLES);
glNormal3fv(&v1); glVertex3fv(&p1);
glNormal3fv(&v1); glVertex3fv(&p2);
glNormal3fv(&v1); glVertex3fv(&p3);
glNormal3fv(&v2); glVertex3fv(&p4);
glNormal3fv(&v2); glVertex3fv(&p5);
glNormal3fv(&v2); glVertex3fv(&p6);
...
glEnd();

The reason this is faster is the display list can optimize this type of primitive into a single, very
efficient structure. The small cost of adding extra data is offset by this optimization.

5–4 OpenGL implementation guide

Performance is increased by maximizing the number of vertices per Begin/End pair. If your
vertex data in memory is organized in a linear, rather than a random manner, performance is
enhanced by taking advantage of vertex pre-fetch. It is most efficient to use 32-bit float data,
which avoids the need to convert data.

texture downloading performance

This section includes some helpful hints for improving the performance of your program when
downloading textures.

■ If you are downloading MIPmaps, always begin with the base level (level 0) first.

■ If it is possible, you should use texture objects to store and bind textures.

■ If you are doing dynamic downloading of texture maps, you will get better performance by

replacing the current texture with a texture of the same width, height, border size, and
format. This should be done instead of deleting the old texture and creating a new one.

selection performance

T o increase the performance of selection (glRenderMode GL_SELECTION) it is recommended
that the following capabilities be disabled before entering the selection mode.

programming hints

GL_TEXTURE_*
GL_TEXTURE_GEN_*
GL_FOG
GL_LIGHTING

state change

OpenGL state setting commands can be classified into two different categories. The first
category is vertex-data commands. These are the calls that can occur between a

glBegin/glEnd pair:

glVertex
glColor
glIndex
glNormal
glEdgeFlag
glMaterial
glTexCoord

The processing of these calls is very fast. Restructuring a program to eliminate some vertex data
commands will not significantly improve performance.

The second category is modal state-setting commands, or sometimes referred to as “mode
changes.” These are the commands that:

■ turn on/off capabilities

■ change attribute settings for capabilities

■ define lights

■ change matrices

OpenGL implementation guide 5–5

programming hints

These calls cannot occur between a glBegin/glEnd pair. Examples of such commands are:

glEnable(GL_LIGHTING);
glFogf(GL_FOG_MODE, GL_LINEAR);
glLightf(..);
glLoadMatrixf(..);

Changes to the modal state are significantly more expensive to process than simple vertex-data
commands. Also, application performance can be optimized by grouping modal-state changes,
and by minimizing the number of modal-state changes:

■ Grouping your state changes together (that is, several modal state changes at one time), and

then rendering primitives, will provide better performance than doing the modal state
changes one by one and intermixing them with primitives.

■ Grouping primitives that require the same modal state together to minimize modal state

changes. For example, if only part of a scene’s primitives are lighted, draw all the lighted
primitives, then turn off lighting and draw all the unlighted primitives, rather than
enabling/disabling lighting many times.

Some states negatively impact performance, such as two-sided lighting, polygon mode
GL_LINE, and wide lines.

optimization of lighting

HP’s implementation of OpenGL optimizes the lighting case such that the performance
degradation from one light to two or more lights is linear . Lighting performance does not de grade
noticeably when you enable a second light. In addition, the GL_SHININESS material parameter
is not particularly expensive to change.

occlusion culling

The proper use of HP’s occlusion culling extension can dramatically improve rendering
performance. This extension defines a mechanism for determining the non-visibility of complex
geometry based on the non-visibility of a bounding geometry . This feature can greatly reduce the
amount of geometry processing and rendering required by an application, thereby, increasing the
applications performance. For more information on occlusion culling, see the section “occlusion

extension” on page 1-12.

high frame rate applications

To achieve maximum performance for buffer swap and clear operations, avoid the following:

■ depth 8 visuals

■ stereo

5–6 OpenGL implementation guide

rescaling normals

When normal rescaling is enabled, a new operation is added to the transformation of the normal
vector into eye coordinates. The normal vector is rescaled after it is multiplied by the inverse
modelview matrix and before it is normalized.

The rescale factor is chosen so that in many cases, normal vectors with unit length in object
coordinates will not need to be normalized as they are transformed into eye coordinates.

HP’s implementation of OpenGL 1.1 supports the GL_RESCALE_NORMAL_EXT token. It is
accepted by the <cap> parameter of glEnable, glDisable, and glIsEnabled, and by
the <pname> parameter of glGetBooleanv, glGetIntegerv, glGetFloatv, and
glGetDoublev.

Normals that have unit length when sent to the OpenGL, hav e their length changed by the inverse
of the scaling factor after transformation by the model-view inverse matrix when the model-view
matrix represents a uniform scale. If rescaling is enabled, then normals specified with the Normal
command are rescaled after transformation by the ModelView Inverse.

Normals sent to the OpenGL may or may not have unit length. In addition, the length of the
normals after transformation might be altered due to transformation by the model-view inverse
matrix. If normalization is enabled, then normals specified with the glNormal3 command are
normalized after transformation by the model-view in v erse matrix and after rescaling if rescaling
is enabled. Normalization and rescaling are controlled with glEnable and glDisable with
the target equal to NORMALIZE or RESCALE_NORMAL. This requires two bits of state. The
initial state is for normals not to be normalized or rescaled.

programming hints

Therefore, if the modelview matrix is M, the transformed plane equation is:

the rescaled normal is:

and the fully transformed normal is:

OpenGL implementation guide 5–7

programming hints

If rescaling is disabled, f is 1, otherwise f is computed as follows:
Let m

denote the matrix element in row i and column j of M-1, numbering the topmost row of

ij

the matrix as row 1, and the left most column as column 1. Then

Alternatively, an implementation may choose to normalize the normal instead of rescaling the
normal. Then:

If normalization is disabled, then the square root in the previous fully transformed normal
equation is replaced with 1; otherwise, it is calculated as dictated by the OpenGL Spec. If both
normalize and rescale are enabled, HP’s implementation skips the rescale and does only the
normalize.

5–8 OpenGL implementation guide