The OpenGL Graphics System: A Specification · 9/23/2008 · The OpenGL R Graphics System: A...

The OpenGLR©

Graphics System:A Specification

(Version 3.0 - September 23, 2008)

Mark SegalKurt Akeley

Editor (version 1.1): Chris FrazierEditor (versions 1.2-3.0): Jon Leech

Editor (version 2.0): Pat Brown

Copyright c© 2006-2008 The Khronos Group Inc. All Rights Reserved.

This specification is protected by copyright laws and contains material proprietaryto the Khronos Group, Inc. It or any components may not be reproduced, repub-lished, distributed, transmitted, displayed, broadcast or otherwise exploited in anymanner without the express prior written permission of Khronos Group. You mayuse this specification for implementing the functionality therein, without altering orremoving any trademark, copyright or other notice from the specification, but thereceipt or possession of this specification does not convey any rights to reproduce,disclose, or distribute its contents, or to manufacture, use, or sell anything that itmay describe, in whole or in part.

Khronos Group grants express permission to any current Promoter, Contributoror Adopter member of Khronos to copy and redistribute UNMODIFIED versionsof this specification in any fashion, provided that NO CHARGE is made for thespecification and the latest available update of the specification for any versionof the API is used whenever possible. Such distributed specification may be re-formatted AS LONG AS the contents of the specification are not changed in anyway. The specification may be incorporated into a product that is sold as long assuch product includes significant independent work developed by the seller. A linkto the current version of this specification on the Khronos Group web-site shouldbe included whenever possible with specification distributions.

Khronos Group makes no, and expressly disclaims any, representations or war-ranties, express or implied, regarding this specification, including, without limita-tion, any implied warranties of merchantability or fitness for a particular purposeor non-infringement of any intellectual property. Khronos Group makes no, andexpressly disclaims any, warranties, express or implied, regarding the correctness,accuracy, completeness, timeliness, and reliability of the specification. Under nocircumstances will the Khronos Group, or any of its Promoters, Contributors orMembers or their respective partners, officers, directors, employees, agents or rep-resentatives be liable for any damages, whether direct, indirect, special or conse-quential damages for lost revenues, lost profits, or otherwise, arising from or inconnection with these materials.

Khronos is a trademark of The Khronos Group Inc. OpenGL is a registered trade-mark, and OpenGL ES is a trademark, of Silicon Graphics, Inc.

Contents

1 Introduction 11.1 Formatting of Optional Features . . . . . . . . . . . . . . . . . . 11.2 What is the OpenGL Graphics System? . . . . . . . . . . . . . . 11.3 Programmer’s View of OpenGL . . . . . . . . . . . . . . . . . . 21.4 Implementor’s View of OpenGL . . . . . . . . . . . . . . . . . . 21.5 Our View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.6 The Deprecation Model . . . . . . . . . . . . . . . . . . . . . . . 31.7 Companion Documents . . . . . . . . . . . . . . . . . . . . . . . 3

1.7.1 OpenGL Shading Language . . . . . . . . . . . . . . . . 31.7.2 Window System Bindings . . . . . . . . . . . . . . . . . 3

2 OpenGL Operation 52.1 OpenGL Fundamentals . . . . . . . . . . . . . . . . . . . . . . . 5

2.1.1 Floating-Point Computation . . . . . . . . . . . . . . . . 72.1.2 16-Bit Floating-Point Numbers . . . . . . . . . . . . . . 82.1.3 Unsigned 11-Bit Floating-Point Numbers . . . . . . . . . 92.1.4 Unsigned 10-Bit Floating-Point Numbers . . . . . . . . . 9

2.2 GL State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.2.1 Shared Object State . . . . . . . . . . . . . . . . . . . . . 11

2.3 GL Command Syntax . . . . . . . . . . . . . . . . . . . . . . . . 112.4 Basic GL Operation . . . . . . . . . . . . . . . . . . . . . . . . . 132.5 GL Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.6 Begin/End Paradigm . . . . . . . . . . . . . . . . . . . . . . . . 16

2.6.1 Begin and End . . . . . . . . . . . . . . . . . . . . . . . 192.6.2 Polygon Edges . . . . . . . . . . . . . . . . . . . . . . . 232.6.3 GL Commands within Begin/End . . . . . . . . . . . . . 24

2.7 Vertex Specification . . . . . . . . . . . . . . . . . . . . . . . . . 242.8 Vertex Arrays . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282.9 Buffer Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

i

CONTENTS ii

2.9.1 Mapping and Unmapping Buffer Data . . . . . . . . . . . 422.9.2 Vertex Arrays in Buffer Objects . . . . . . . . . . . . . . 462.9.3 Array Indices in Buffer Objects . . . . . . . . . . . . . . 472.9.4 Buffer Object State . . . . . . . . . . . . . . . . . . . . . 47

2.10 Vertex Array Objects . . . . . . . . . . . . . . . . . . . . . . . . 482.11 Rectangles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 492.12 Coordinate Transformations . . . . . . . . . . . . . . . . . . . . 49

2.12.1 Controlling the Viewport . . . . . . . . . . . . . . . . . . 512.12.2 Matrices . . . . . . . . . . . . . . . . . . . . . . . . . . . 522.12.3 Normal Transformation . . . . . . . . . . . . . . . . . . . 572.12.4 Generating Texture Coordinates . . . . . . . . . . . . . . 59

2.13 Asynchronous Queries . . . . . . . . . . . . . . . . . . . . . . . 612.14 Conditional Rendering . . . . . . . . . . . . . . . . . . . . . . . 632.15 Transform Feedback . . . . . . . . . . . . . . . . . . . . . . . . 642.16 Primitive Queries . . . . . . . . . . . . . . . . . . . . . . . . . . 672.17 Clipping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 682.18 Current Raster Position . . . . . . . . . . . . . . . . . . . . . . . 702.19 Colors and Coloring . . . . . . . . . . . . . . . . . . . . . . . . . 73

2.19.1 Lighting . . . . . . . . . . . . . . . . . . . . . . . . . . . 752.19.2 Lighting Parameter Specification . . . . . . . . . . . . . . 802.19.3 ColorMaterial . . . . . . . . . . . . . . . . . . . . . . . 842.19.4 Lighting State . . . . . . . . . . . . . . . . . . . . . . . . 842.19.5 Color Index Lighting . . . . . . . . . . . . . . . . . . . . 852.19.6 Clamping or Masking . . . . . . . . . . . . . . . . . . . 862.19.7 Flatshading . . . . . . . . . . . . . . . . . . . . . . . . . 862.19.8 Color and Associated Data Clipping . . . . . . . . . . . . 872.19.9 Final Color Processing . . . . . . . . . . . . . . . . . . . 88

2.20 Vertex Shaders . . . . . . . . . . . . . . . . . . . . . . . . . . . 882.20.1 Shader Objects . . . . . . . . . . . . . . . . . . . . . . . 892.20.2 Program Objects . . . . . . . . . . . . . . . . . . . . . . 902.20.3 Shader Variables . . . . . . . . . . . . . . . . . . . . . . 922.20.4 Shader Execution . . . . . . . . . . . . . . . . . . . . . . 1042.20.5 Required State . . . . . . . . . . . . . . . . . . . . . . . 110

3 Rasterization 1123.1 Discarding Primitives Before Rasterization . . . . . . . . . . . . 1143.2 Invariance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1143.3 Antialiasing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

3.3.1 Multisampling . . . . . . . . . . . . . . . . . . . . . . . 1153.4 Points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

Version 3.0 (September 23, 2008)

CONTENTS iii

3.4.1 Basic Point Rasterization . . . . . . . . . . . . . . . . . . 1193.4.2 Point Rasterization State . . . . . . . . . . . . . . . . . . 1233.4.3 Point Multisample Rasterization . . . . . . . . . . . . . . 123

3.5 Line Segments . . . . . . . . . . . . . . . . . . . . . . . . . . . 1233.5.1 Basic Line Segment Rasterization . . . . . . . . . . . . . 1243.5.2 Other Line Segment Features . . . . . . . . . . . . . . . . 1263.5.3 Line Rasterization State . . . . . . . . . . . . . . . . . . 1293.5.4 Line Multisample Rasterization . . . . . . . . . . . . . . 129

3.6 Polygons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1303.6.1 Basic Polygon Rasterization . . . . . . . . . . . . . . . . 1303.6.2 Stippling . . . . . . . . . . . . . . . . . . . . . . . . . . 1323.6.3 Antialiasing . . . . . . . . . . . . . . . . . . . . . . . . . 1333.6.4 Options Controlling Polygon Rasterization . . . . . . . . 1333.6.5 Depth Offset . . . . . . . . . . . . . . . . . . . . . . . . 1343.6.6 Polygon Multisample Rasterization . . . . . . . . . . . . 1353.6.7 Polygon Rasterization State . . . . . . . . . . . . . . . . 136

3.7 Pixel Rectangles . . . . . . . . . . . . . . . . . . . . . . . . . . . 1363.7.1 Pixel Storage Modes and Pixel Buffer Objects . . . . . . . 1363.7.2 The Imaging Subset . . . . . . . . . . . . . . . . . . . . 1383.7.3 Pixel Transfer Modes . . . . . . . . . . . . . . . . . . . . 1383.7.4 Rasterization of Pixel Rectangles . . . . . . . . . . . . . 1493.7.5 Pixel Transfer Operations . . . . . . . . . . . . . . . . . 1633.7.6 Pixel Rectangle Multisample Rasterization . . . . . . . . 173

3.8 Bitmaps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1743.9 Texturing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176

3.9.1 Texture Image Specification . . . . . . . . . . . . . . . . 1773.9.2 Alternate Texture Image Specification Commands . . . . 1923.9.3 Compressed Texture Images . . . . . . . . . . . . . . . . 1973.9.4 Texture Parameters . . . . . . . . . . . . . . . . . . . . . 2013.9.5 Depth Component Textures . . . . . . . . . . . . . . . . 2033.9.6 Cube Map Texture Selection . . . . . . . . . . . . . . . . 2033.9.7 Texture Minification . . . . . . . . . . . . . . . . . . . . 2043.9.8 Texture Magnification . . . . . . . . . . . . . . . . . . . 2133.9.9 Combined Depth/Stencil Textures . . . . . . . . . . . . . 2133.9.10 Texture Completeness . . . . . . . . . . . . . . . . . . . 2133.9.11 Texture State and Proxy State . . . . . . . . . . . . . . . 2153.9.12 Texture Objects . . . . . . . . . . . . . . . . . . . . . . . 2163.9.13 Texture Environments and Texture Functions . . . . . . . 2193.9.14 Texture Comparison Modes . . . . . . . . . . . . . . . . 2223.9.15 sRGB Texture Color Conversion . . . . . . . . . . . . . . 225


CONTENTS iv

3.9.16 Shared Exponent Texture Color Conversion . . . . . . . . 2273.9.17 Texture Application . . . . . . . . . . . . . . . . . . . . . 227

3.10 Color Sum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2283.11 Fog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2303.12 Fragment Shaders . . . . . . . . . . . . . . . . . . . . . . . . . . 231

3.12.1 Shader Variables . . . . . . . . . . . . . . . . . . . . . . 2323.12.2 Shader Execution . . . . . . . . . . . . . . . . . . . . . . 233

3.13 Antialiasing Application . . . . . . . . . . . . . . . . . . . . . . 2373.14 Multisample Point Fade . . . . . . . . . . . . . . . . . . . . . . . 237

4 Per-Fragment Operations and the Framebuffer 2394.1 Per-Fragment Operations . . . . . . . . . . . . . . . . . . . . . . 241

4.1.1 Pixel Ownership Test . . . . . . . . . . . . . . . . . . . . 2414.1.2 Scissor Test . . . . . . . . . . . . . . . . . . . . . . . . . 2424.1.3 Multisample Fragment Operations . . . . . . . . . . . . . 2424.1.4 Alpha Test . . . . . . . . . . . . . . . . . . . . . . . . . 2434.1.5 Stencil Test . . . . . . . . . . . . . . . . . . . . . . . . . 2444.1.6 Depth Buffer Test . . . . . . . . . . . . . . . . . . . . . . 2464.1.7 Occlusion Queries . . . . . . . . . . . . . . . . . . . . . 2464.1.8 Blending . . . . . . . . . . . . . . . . . . . . . . . . . . 2474.1.9 sRGB Conversion . . . . . . . . . . . . . . . . . . . . . 2524.1.10 Dithering . . . . . . . . . . . . . . . . . . . . . . . . . . 2524.1.11 Logical Operation . . . . . . . . . . . . . . . . . . . . . 2534.1.12 Additional Multisample Fragment Operations . . . . . . . 254

4.2 Whole Framebuffer Operations . . . . . . . . . . . . . . . . . . . 2554.2.1 Selecting a Buffer for Writing . . . . . . . . . . . . . . . 2554.2.2 Fine Control of Buffer Updates . . . . . . . . . . . . . . 2604.2.3 Clearing the Buffers . . . . . . . . . . . . . . . . . . . . 2614.2.4 The Accumulation Buffer . . . . . . . . . . . . . . . . . 264

4.3 Drawing, Reading, and Copying Pixels . . . . . . . . . . . . . . . 2664.3.1 Writing to the Stencil or Depth/Stencil Buffers . . . . . . 2664.3.2 Reading Pixels . . . . . . . . . . . . . . . . . . . . . . . 2664.3.3 Copying Pixels . . . . . . . . . . . . . . . . . . . . . . . 2744.3.4 Pixel Draw/Read State . . . . . . . . . . . . . . . . . . . 278

4.4 Framebuffer Objects . . . . . . . . . . . . . . . . . . . . . . . . 2784.4.1 Binding and Managing Framebuffer Objects . . . . . . . . 2794.4.2 Attaching Images to Framebuffer Objects . . . . . . . . . 2824.4.3 Rendering When an Image of a Bound Texture Object is

Also Attached to the Framebuffer . . . . . . . . . . . . . 2894.4.4 Framebuffer Completeness . . . . . . . . . . . . . . . . . 290


CONTENTS v

4.4.5 Effects of Framebuffer State on Framebuffer DependentValues . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295

4.4.6 Mapping between Pixel and Element in Attached Image . 296

5 Special Functions 2975.1 Evaluators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2975.2 Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3035.3 Feedback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3055.4 Display Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3075.5 Commands Not Usable In Display Lists . . . . . . . . . . . . . . 3115.6 Flush and Finish . . . . . . . . . . . . . . . . . . . . . . . . . . . 3125.7 Hints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313

6 State and State Requests 3156.1 Querying GL State . . . . . . . . . . . . . . . . . . . . . . . . . 315

6.1.1 Simple Queries . . . . . . . . . . . . . . . . . . . . . . . 3156.1.2 Data Conversions . . . . . . . . . . . . . . . . . . . . . . 3166.1.3 Enumerated Queries . . . . . . . . . . . . . . . . . . . . 3176.1.4 Texture Queries . . . . . . . . . . . . . . . . . . . . . . . 3206.1.5 Stipple Query . . . . . . . . . . . . . . . . . . . . . . . . 3236.1.6 Color Matrix Query . . . . . . . . . . . . . . . . . . . . . 3236.1.7 Color Table Query . . . . . . . . . . . . . . . . . . . . . 3236.1.8 Convolution Query . . . . . . . . . . . . . . . . . . . . . 3246.1.9 Histogram Query . . . . . . . . . . . . . . . . . . . . . . 3256.1.10 Minmax Query . . . . . . . . . . . . . . . . . . . . . . . 3266.1.11 Pointer and String Queries . . . . . . . . . . . . . . . . . 3276.1.12 Asynchronous Queries . . . . . . . . . . . . . . . . . . . 3286.1.13 Buffer Object Queries . . . . . . . . . . . . . . . . . . . 3306.1.14 Vertex Array Object Queries . . . . . . . . . . . . . . . . 3316.1.15 Shader and Program Queries . . . . . . . . . . . . . . . . 3316.1.16 Framebuffer Object Queries . . . . . . . . . . . . . . . . 3366.1.17 Renderbuffer Object Queries . . . . . . . . . . . . . . . . 3386.1.18 Saving and Restoring State . . . . . . . . . . . . . . . . . 339

6.2 State Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343

A Invariance 393A.1 Repeatability . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393A.2 Multi-pass Algorithms . . . . . . . . . . . . . . . . . . . . . . . 394A.3 Invariance Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . 394A.4 What All This Means . . . . . . . . . . . . . . . . . . . . . . . . 396


CONTENTS vi

B Corollaries 397

C Compressed Texture Image Formats 400C.1 RGTC Compressed Texture Image Formats . . . . . . . . . . . . 400

C.1.1 Format COMPRESSED RED RGTC1 . . . . . . . . . . . . . 401C.1.2 Format COMPRESSED SIGNED RED RGTC1 . . . . . . . . 402C.1.3 Format COMPRESSED RG RGTC2 . . . . . . . . . . . . . . 403C.1.4 Format COMPRESSED SIGNED RG RGTC2 . . . . . . . . . 403

D Shared Objects and Multiple Contexts 404D.1 Object Deletion Behavior . . . . . . . . . . . . . . . . . . . . . . 404

E The Deprecation Model 405E.1 Profiles and Deprecated Features of OpenGL 3.0 . . . . . . . . . 405

F Version 1.1 411F.1 Vertex Array . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411F.2 Polygon Offset . . . . . . . . . . . . . . . . . . . . . . . . . . . 412F.3 Logical Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 412F.4 Texture Image Formats . . . . . . . . . . . . . . . . . . . . . . . 412F.5 Texture Replace Environment . . . . . . . . . . . . . . . . . . . . 412F.6 Texture Proxies . . . . . . . . . . . . . . . . . . . . . . . . . . . 413F.7 Copy Texture and Subtexture . . . . . . . . . . . . . . . . . . . . 413F.8 Texture Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . 413F.9 Other Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 413F.10 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 414

G Version 1.2 416G.1 Three-Dimensional Texturing . . . . . . . . . . . . . . . . . . . . 416G.2 BGRA Pixel Formats . . . . . . . . . . . . . . . . . . . . . . . . 416G.3 Packed Pixel Formats . . . . . . . . . . . . . . . . . . . . . . . . 417G.4 Normal Rescaling . . . . . . . . . . . . . . . . . . . . . . . . . . 417G.5 Separate Specular Color . . . . . . . . . . . . . . . . . . . . . . 417G.6 Texture Coordinate Edge Clamping . . . . . . . . . . . . . . . . 417G.7 Texture Level of Detail Control . . . . . . . . . . . . . . . . . . . 418G.8 Vertex Array Draw Element Range . . . . . . . . . . . . . . . . . 418G.9 Imaging Subset . . . . . . . . . . . . . . . . . . . . . . . . . . . 418

G.9.1 Color Tables . . . . . . . . . . . . . . . . . . . . . . . . 418G.9.2 Convolution . . . . . . . . . . . . . . . . . . . . . . . . . 419G.9.3 Color Matrix . . . . . . . . . . . . . . . . . . . . . . . . 419


CONTENTS vii

G.9.4 Pixel Pipeline Statistics . . . . . . . . . . . . . . . . . . . 420G.9.5 Constant Blend Color . . . . . . . . . . . . . . . . . . . . 420G.9.6 New Blending Equations . . . . . . . . . . . . . . . . . . 420

G.10 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 420

H Version 1.2.1 424

I Version 1.3 425I.1 Compressed Textures . . . . . . . . . . . . . . . . . . . . . . . . 425I.2 Cube Map Textures . . . . . . . . . . . . . . . . . . . . . . . . . 425I.3 Multisample . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426I.4 Multitexture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426I.5 Texture Add Environment Mode . . . . . . . . . . . . . . . . . . 427I.6 Texture Combine Environment Mode . . . . . . . . . . . . . . . 427I.7 Texture Dot3 Environment Mode . . . . . . . . . . . . . . . . . . 427I.8 Texture Border Clamp . . . . . . . . . . . . . . . . . . . . . . . 427I.9 Transpose Matrix . . . . . . . . . . . . . . . . . . . . . . . . . . 428I.10 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 428

J Version 1.4 433J.1 Automatic Mipmap Generation . . . . . . . . . . . . . . . . . . . 433J.2 Blend Squaring . . . . . . . . . . . . . . . . . . . . . . . . . . . 433J.3 Changes to the Imaging Subset . . . . . . . . . . . . . . . . . . . 434J.4 Depth Textures and Shadows . . . . . . . . . . . . . . . . . . . . 434J.5 Fog Coordinate . . . . . . . . . . . . . . . . . . . . . . . . . . . 434J.6 Multiple Draw Arrays . . . . . . . . . . . . . . . . . . . . . . . . 434J.7 Point Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . 435J.8 Secondary Color . . . . . . . . . . . . . . . . . . . . . . . . . . 435J.9 Separate Blend Functions . . . . . . . . . . . . . . . . . . . . . . 435J.10 Stencil Wrap . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435J.11 Texture Crossbar Environment Mode . . . . . . . . . . . . . . . . 435J.12 Texture LOD Bias . . . . . . . . . . . . . . . . . . . . . . . . . . 436J.13 Texture Mirrored Repeat . . . . . . . . . . . . . . . . . . . . . . 436J.14 Window Raster Position . . . . . . . . . . . . . . . . . . . . . . 436J.15 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 436

K Version 1.5 439K.1 Buffer Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . 439K.2 Occlusion Queries . . . . . . . . . . . . . . . . . . . . . . . . . . 440K.3 Shadow Functions . . . . . . . . . . . . . . . . . . . . . . . . . . 440


CONTENTS viii

K.4 Changed Tokens . . . . . . . . . . . . . . . . . . . . . . . . . . . 440K.5 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 440

L Version 2.0 445L.1 Programmable Shading . . . . . . . . . . . . . . . . . . . . . . . 445

L.1.1 Shader Objects . . . . . . . . . . . . . . . . . . . . . . . 445L.1.2 Shader Programs . . . . . . . . . . . . . . . . . . . . . . 445L.1.3 OpenGL Shading Language . . . . . . . . . . . . . . . . 446L.1.4 Changes To Shader APIs . . . . . . . . . . . . . . . . . . 446

L.2 Multiple Render Targets . . . . . . . . . . . . . . . . . . . . . . 446L.3 Non-Power-Of-Two Textures . . . . . . . . . . . . . . . . . . . . 446L.4 Point Sprites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 447L.5 Separate Blend Equation . . . . . . . . . . . . . . . . . . . . . . 447L.6 Separate Stencil . . . . . . . . . . . . . . . . . . . . . . . . . . . 447L.7 Other Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 447L.8 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 449

M Version 2.1 451M.1 OpenGL Shading Language . . . . . . . . . . . . . . . . . . . . 451M.2 Non-Square Matrices . . . . . . . . . . . . . . . . . . . . . . . . 451M.3 Pixel Buffer Objects . . . . . . . . . . . . . . . . . . . . . . . . . 451M.4 sRGB Textures . . . . . . . . . . . . . . . . . . . . . . . . . . . 452M.5 Other Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 452M.6 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 454

N Version 3.0 457N.1 New Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . 457N.2 Deprecation Model . . . . . . . . . . . . . . . . . . . . . . . . . 458N.3 Changed Tokens . . . . . . . . . . . . . . . . . . . . . . . . . . . 459N.4 Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 459N.5 Credits and Acknowledgements . . . . . . . . . . . . . . . . . . 461

O ARB Extensions 464O.1 Naming Conventions . . . . . . . . . . . . . . . . . . . . . . . . 464O.2 Promoting Extensions to Core Features . . . . . . . . . . . . . . 465O.3 Multitexture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465O.4 Transpose Matrix . . . . . . . . . . . . . . . . . . . . . . . . . . 465O.5 Multisample . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465O.6 Texture Add Environment Mode . . . . . . . . . . . . . . . . . . 466O.7 Cube Map Textures . . . . . . . . . . . . . . . . . . . . . . . . . 466


CONTENTS ix

O.8 Compressed Textures . . . . . . . . . . . . . . . . . . . . . . . . 466O.9 Texture Border Clamp . . . . . . . . . . . . . . . . . . . . . . . 466O.10 Point Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . 466O.11 Vertex Blend . . . . . . . . . . . . . . . . . . . . . . . . . . . . 466O.12 Matrix Palette . . . . . . . . . . . . . . . . . . . . . . . . . . . . 467O.13 Texture Combine Environment Mode . . . . . . . . . . . . . . . 467O.14 Texture Crossbar Environment Mode . . . . . . . . . . . . . . . . 467O.15 Texture Dot3 Environment Mode . . . . . . . . . . . . . . . . . . 467O.16 Texture Mirrored Repeat . . . . . . . . . . . . . . . . . . . . . . 467O.17 Depth Texture . . . . . . . . . . . . . . . . . . . . . . . . . . . . 467O.18 Shadow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 467O.19 Shadow Ambient . . . . . . . . . . . . . . . . . . . . . . . . . . 468O.20 Window Raster Position . . . . . . . . . . . . . . . . . . . . . . 468O.21 Low-Level Vertex Programming . . . . . . . . . . . . . . . . . . 468O.22 Low-Level Fragment Programming . . . . . . . . . . . . . . . . 468O.23 Buffer Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . 468O.24 Occlusion Queries . . . . . . . . . . . . . . . . . . . . . . . . . . 469O.25 Shader Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . 469O.26 High-Level Vertex Programming . . . . . . . . . . . . . . . . . . 469O.27 High-Level Fragment Programming . . . . . . . . . . . . . . . . 469O.28 OpenGL Shading Language . . . . . . . . . . . . . . . . . . . . 469O.29 Non-Power-Of-Two Textures . . . . . . . . . . . . . . . . . . . . 469O.30 Point Sprites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 470O.31 Fragment Program Shadow . . . . . . . . . . . . . . . . . . . . . 470O.32 Multiple Render Targets . . . . . . . . . . . . . . . . . . . . . . 470O.33 Rectangular Textures . . . . . . . . . . . . . . . . . . . . . . . . 470O.34 Floating-Point Color Buffers . . . . . . . . . . . . . . . . . . . . 470O.35 Half-Precision Floating Point . . . . . . . . . . . . . . . . . . . . 471O.36 Floating-Point Textures . . . . . . . . . . . . . . . . . . . . . . . 471O.37 Pixel Buffer Objects . . . . . . . . . . . . . . . . . . . . . . . . . 471

Index 472


List of Figures

2.1 Block diagram of the GL. . . . . . . . . . . . . . . . . . . . . . . 132.2 Creation of a processed vertex from a transformed vertex and cur-

rent values. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.3 Primitive assembly and processing. . . . . . . . . . . . . . . . . . 192.4 Triangle strips, fans, and independent triangles. . . . . . . . . . . 212.5 Quadrilateral strips and independent quadrilaterals. . . . . . . . . 222.6 Vertex transformation sequence. . . . . . . . . . . . . . . . . . . 502.7 Current raster position. . . . . . . . . . . . . . . . . . . . . . . . 712.8 Processing of RGBA colors. . . . . . . . . . . . . . . . . . . . . 732.9 Processing of color indices. . . . . . . . . . . . . . . . . . . . . . 732.10 ColorMaterial operation. . . . . . . . . . . . . . . . . . . . . . . 84

3.1 Rasterization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1123.2 Rasterization of non-antialiased wide points. . . . . . . . . . . . . 1193.3 Rasterization of antialiased wide points. . . . . . . . . . . . . . . 1193.4 Visualization of Bresenham’s algorithm. . . . . . . . . . . . . . . 1243.5 Rasterization of non-antialiased wide lines. . . . . . . . . . . . . 1273.6 The region used in rasterizing an antialiased line segment. . . . . 1283.7 Operation of DrawPixels. . . . . . . . . . . . . . . . . . . . . . 1493.8 Selecting a subimage from an image . . . . . . . . . . . . . . . . 1543.9 A bitmap and its associated parameters. . . . . . . . . . . . . . . 1743.10 A texture image and the coordinates used to access it. . . . . . . . 1903.11 Multitexture pipeline. . . . . . . . . . . . . . . . . . . . . . . . . 228

4.1 Per-fragment operations. . . . . . . . . . . . . . . . . . . . . . . 2414.2 Operation of ReadPixels. . . . . . . . . . . . . . . . . . . . . . . 2664.3 Operation of CopyPixels. . . . . . . . . . . . . . . . . . . . . . . 274

5.1 Map Evaluation. . . . . . . . . . . . . . . . . . . . . . . . . . . . 2995.2 Feedback syntax. . . . . . . . . . . . . . . . . . . . . . . . . . . 308

x

List of Tables

2.1 GL command suffixes . . . . . . . . . . . . . . . . . . . . . . . . 122.2 GL data types . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.3 Summary of GL errors . . . . . . . . . . . . . . . . . . . . . . . 172.4 Vertex array sizes (values per vertex) and data types . . . . . . . . 302.5 Variables that direct the execution of InterleavedArrays. . . . . . 372.6 Buffer object parameters and their values. . . . . . . . . . . . . . 392.7 Buffer object initial state. . . . . . . . . . . . . . . . . . . . . . . 412.8 Buffer object state set by MapBufferRange. . . . . . . . . . . . 442.9 Transform feedback modes . . . . . . . . . . . . . . . . . . . . . 652.10 Component conversions . . . . . . . . . . . . . . . . . . . . . . . 752.11 Summary of lighting parameters. . . . . . . . . . . . . . . . . . . 772.12 Correspondence of lighting parameter symbols to names. . . . . . 822.13 Polygon flatshading color selection. . . . . . . . . . . . . . . . . 87

3.1 PixelStore parameters. . . . . . . . . . . . . . . . . . . . . . . . 1373.2 PixelTransfer parameters. . . . . . . . . . . . . . . . . . . . . . 1393.3 PixelMap parameters. . . . . . . . . . . . . . . . . . . . . . . . 1403.4 Color table names. . . . . . . . . . . . . . . . . . . . . . . . . . 1413.5 DrawPixels and ReadPixels types. . . . . . . . . . . . . . . . . . 1523.6 DrawPixels and ReadPixels formats. . . . . . . . . . . . . . . . 1533.7 Swap Bytes bit ordering. . . . . . . . . . . . . . . . . . . . . . . 1543.8 Packed pixel formats. . . . . . . . . . . . . . . . . . . . . . . . . 1563.9 UNSIGNED BYTE formats. Bit numbers are indicated for each com-

ponent. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1573.10 UNSIGNED SHORT formats . . . . . . . . . . . . . . . . . . . . . 1583.11 UNSIGNED INT formats . . . . . . . . . . . . . . . . . . . . . . . 1593.12 Packed pixel field assignments. . . . . . . . . . . . . . . . . . . . 1603.13 Color table lookup. . . . . . . . . . . . . . . . . . . . . . . . . . 1663.14 Computation of filtered color components. . . . . . . . . . . . . . 167

xi

LIST OF TABLES xii

3.15 Conversion from RGBA, depth, and stencil pixel components tointernal texture, table, or filter components. . . . . . . . . . . . . 179

3.16 Sized internal color formats. . . . . . . . . . . . . . . . . . . . . 1843.18 Sized internal depth and stencil formats. . . . . . . . . . . . . . . 1853.17 Sized internal luminance and intensity formats. . . . . . . . . . . 1853.19 Generic and specific compressed internal formats. . . . . . . . . . 1863.20 Texture parameters and their values. . . . . . . . . . . . . . . . . 2023.21 Selection of cube map images. . . . . . . . . . . . . . . . . . . . 2033.22 Texel location wrap mode application. . . . . . . . . . . . . . . . 2073.23 Correspondence of filtered texture components to texture source

components. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2213.24 Texture functions REPLACE, MODULATE, and DECAL . . . . . . . . 2213.25 Texture functions BLEND and ADD. . . . . . . . . . . . . . . . . . 2223.26 COMBINE texture functions. . . . . . . . . . . . . . . . . . . . . . 2233.27 Arguments for COMBINE RGB functions. . . . . . . . . . . . . . . 2243.28 Arguments for COMBINE ALPHA functions. . . . . . . . . . . . . 2243.29 Depth texture comparison functions. . . . . . . . . . . . . . . . . 226

4.1 RGB and Alpha blend equations. . . . . . . . . . . . . . . . . . . 2504.2 Blending functions. . . . . . . . . . . . . . . . . . . . . . . . . . 2514.3 Arguments to LogicOp and their corresponding operations. . . . . 2544.4 Buffer selection for the default framebuffer . . . . . . . . . . . . 2574.5 Buffer selection for a framebuffer object . . . . . . . . . . . . . . 2574.6 DrawBuffers buffer selection for the default framebuffer . . . . . 2584.7 PixelStore parameters. . . . . . . . . . . . . . . . . . . . . . . . 2684.8 ReadPixels index masks. . . . . . . . . . . . . . . . . . . . . . . 2724.9 ReadPixels GL data types and reversed component conversion for-

mulas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2734.10 Effective ReadPixels format for DEPTH STENCIL CopyPixels op-

eration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2764.11 Correspondence of renderbuffer sized to base internal formats. . . 2844.12 Framebuffer attachment points. . . . . . . . . . . . . . . . . . . . 286

5.1 Values specified by the target to Map1. . . . . . . . . . . . . . . 2985.2 Correspondence of feedback type to number of values per vertex. . 3075.3 Hint targets and descriptions . . . . . . . . . . . . . . . . . . . . 314

6.1 Texture, table, and filter return values. . . . . . . . . . . . . . . . 3226.2 Attribute groups . . . . . . . . . . . . . . . . . . . . . . . . . . . 3416.3 State Variable Types . . . . . . . . . . . . . . . . . . . . . . . . . 342


LIST OF TABLES xiii

6.4 GL Internal begin-end state variables (inaccessible) . . . . . . . . 3446.5 Current Values and Associated Data . . . . . . . . . . . . . . . . 3456.6 Vertex Array Object State . . . . . . . . . . . . . . . . . . . . . . 3466.7 Vertex Array Object State (cont.) . . . . . . . . . . . . . . . . . . 3476.8 Vertex Array Object State (cont.) . . . . . . . . . . . . . . . . . . 3486.9 Vertex Array Object State (cont.) . . . . . . . . . . . . . . . . . . 3496.10 Vertex Array Data (not in Vertex Array objects) . . . . . . . . . . 3506.11 Buffer Object State . . . . . . . . . . . . . . . . . . . . . . . . . 3516.12 Transformation state . . . . . . . . . . . . . . . . . . . . . . . . 3526.13 Coloring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3536.14 Lighting (see also table 2.11 for defaults) . . . . . . . . . . . . . 3546.15 Lighting (cont.) . . . . . . . . . . . . . . . . . . . . . . . . . . . 3556.16 Rasterization . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3566.17 Rasterization (cont.) . . . . . . . . . . . . . . . . . . . . . . . . . 3576.18 Multisampling . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3586.19 Textures (state per texture unit and binding point) . . . . . . . . . 3596.20 Textures (state per texture object) . . . . . . . . . . . . . . . . . . 3606.21 Textures (state per texture image) . . . . . . . . . . . . . . . . . . 3616.22 Texture Environment and Generation . . . . . . . . . . . . . . . . 3626.23 Texture Environment and Generation (cont.) . . . . . . . . . . . . 3636.24 Pixel Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . 3646.25 Pixel Operations (cont.) . . . . . . . . . . . . . . . . . . . . . . . 3656.26 Framebuffer Control . . . . . . . . . . . . . . . . . . . . . . . . 3666.27 Framebuffer (state per target binding point) . . . . . . . . . . . . 3676.28 Framebuffer (state per framebuffer object) . . . . . . . . . . . . . 3686.29 Framebuffer (state per attachment point) . . . . . . . . . . . . . . 3696.30 Renderbuffer (state per target and binding point) . . . . . . . . . . 3706.31 Renderbuffer (state per renderbuffer object) . . . . . . . . . . . . 3716.32 Pixels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3726.33 Pixels (cont.) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3736.34 Pixels (cont.) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3746.35 Pixels (cont.) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3756.36 Pixels (cont.) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3766.37 Pixels (cont.) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3776.38 Evaluators (GetMap takes a map name) . . . . . . . . . . . . . . 3786.39 Shader Object State . . . . . . . . . . . . . . . . . . . . . . . . . 3796.40 Program Object State . . . . . . . . . . . . . . . . . . . . . . . . 3806.41 Program Object State (cont.) . . . . . . . . . . . . . . . . . . . . 3816.42 Vertex Shader State . . . . . . . . . . . . . . . . . . . . . . . . . 3826.43 Query Object State . . . . . . . . . . . . . . . . . . . . . . . . . 383


LIST OF TABLES xiv

6.44 Transform Feedback State . . . . . . . . . . . . . . . . . . . . . 3846.45 Hints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3856.46 Implementation Dependent Values . . . . . . . . . . . . . . . . . 3866.47 Implementation Dependent Values (cont.) . . . . . . . . . . . . . 3876.48 Implementation Dependent Values (cont.) . . . . . . . . . . . . . 3886.49 Implementation Dependent Values (cont.) . . . . . . . . . . . . . 3896.50 Implementation Dependent Values (cont.) . . . . . . . . . . . . . 3906.51 Framebuffer Dependent Values . . . . . . . . . . . . . . . . . . . 3916.52 Miscellaneous . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392

K.1 New token names . . . . . . . . . . . . . . . . . . . . . . . . . . 441

N.1 New token names . . . . . . . . . . . . . . . . . . . . . . . . . . 459


Chapter 1

Introduction

This document describes the OpenGL graphics system: what it is, how it acts, andwhat is required to implement it. We assume that the reader has at least a rudi-mentary understanding of computer graphics. This means familiarity with the es-sentials of computer graphics algorithms as well as familiarity with basic graphicshardware and associated terms.

1.1 Formatting of Optional Features

Starting with version 1.2 of OpenGL, some features in the specification are consid-ered optional; an OpenGL implementation may or may not choose to provide them(see section 3.7.2).

Portions of the specification which are optional are so described where theoptional features are first defined (see section 3.7.2). State table entries which areoptional are typeset against a gray background .

1.2 What is the OpenGL Graphics System?

OpenGL (for “Open Graphics Library”) is a software interface to graphics hard-ware. The interface consists of a set of several hundred procedures and functionsthat allow a programmer to specify the objects and operations involved in produc-ing high-quality graphical images, specifically color images of three-dimensionalobjects.

Most of OpenGL requires that the graphics hardware contain a framebuffer.Many OpenGL calls pertain to drawing objects such as points, lines, polygons, andbitmaps, but the way that some of this drawing occurs (such as when antialiasing

1

1.3. PROGRAMMER’S VIEW OF OPENGL 2

or texturing is enabled) relies on the existence of a framebuffer. Further, some ofOpenGL is specifically concerned with framebuffer manipulation.

1.3 Programmer’s View of OpenGL

To the programmer, OpenGL is a set of commands that allow the specification ofgeometric objects in two or three dimensions, together with commands that controlhow these objects are rendered into the framebuffer. For the most part, OpenGLprovides an immediate-mode interface, meaning that specifying an object causes itto be drawn.

A typical program that uses OpenGL begins with calls to open a window intothe framebuffer into which the program will draw. Then, calls are made to allocatea GL context and associate it with the window. Once a GL context is allocated,the programmer is free to issue OpenGL commands. Some calls are used to drawsimple geometric objects (i.e. points, line segments, and polygons), while othersaffect the rendering of these primitives including how they are lit or colored andhow they are mapped from the user’s two- or three-dimensional model space tothe two-dimensional screen. There are also calls to effect direct control of theframebuffer, such as reading and writing pixels.

1.4 Implementor’s View of OpenGL

To the implementor, OpenGL is a set of commands that affect the operation ofgraphics hardware. If the hardware consists only of an addressable framebuffer,then OpenGL must be implemented almost entirely on the host CPU. More typi-cally, the graphics hardware may comprise varying degrees of graphics accelera-tion, from a raster subsystem capable of rendering two-dimensional lines and poly-gons to sophisticated floating-point processors capable of transforming and com-puting on geometric data. The OpenGL implementor’s task is to provide the CPUsoftware interface while dividing the work for each OpenGL command betweenthe CPU and the graphics hardware. This division must be tailored to the availablegraphics hardware to obtain optimum performance in carrying out OpenGL calls.

OpenGL maintains a considerable amount of state information. This state con-trols how objects are drawn into the framebuffer. Some of this state is directlyavailable to the user: he or she can make calls to obtain its value. Some of it, how-ever, is visible only by the effect it has on what is drawn. One of the main goals ofthis specification is to make OpenGL state information explicit, to elucidate how itchanges, and to indicate what its effects are.


1.5. OUR VIEW 3

1.5 Our View

We view OpenGL as a pipeline having some programmable stages and some state-driven stages that control a set of specific drawing operations. This model shouldengender a specification that satisfies the needs of both programmers and imple-mentors. It does not, however, necessarily provide a model for implementation. Animplementation must produce results conforming to those produced by the speci-fied methods, but there may be ways to carry out a particular computation that aremore efficient than the one specified.

1.6 The Deprecation Model

GL features marked as deprecated in one version of the specification are expectedto be removed in a future version, allowing applications time to transition awayfrom use of deprecated features. The deprecation model is described in more detail,together with a summary of the commands and state deprecated from this versionof the API, in appendix E.

1.7 Companion Documents

1.7.1 OpenGL Shading Language

This specification should be read together with a companion document titled TheOpenGL Shading Language. The latter document (referred to as the OpenGL Shad-ing Language Specification hereafter) defines the syntax and semantics of the pro-gramming language used to write vertex and fragment shaders (see sections 2.20and 3.12). These sections may include references to concepts and terms (such asshading language variable types) defined in the companion document.

OpenGL 3.0 implementations are guaranteed to support at least versions 1.10,1.20, and 1.30 of the shading language, although versions 1.10 and 1.20 are dep-recated in a forward-compatible context. The actual version supported may bequeried as described in section 6.1.11.

1.7.2 Window System Bindings

OpenGL requires a companion API to create and manage graphics contexts, win-dows to render into, and other resources beyond the scope of this Specification.There are several such APIs supporting different operating and window systems.

OpenGL Graphics with the X Window System, also called the “GLX Specifica-tion”, describes the GLX API for use of OpenGL in the X Window System. It is


1.7. COMPANION DOCUMENTS 4

primarily directed at Linux and Unix systems, but GLX implementations also existfor Microsoft Windows, MacOS X, and some other platforms where X is avail-able. The GLX Specification is available in the OpenGL Extension Registry (seeappendix O).

The WGL API supports use of OpenGL with Microsoft Windows. WGL isdocumented in Microsoft’s MSDN system, although no full specification exists.

Several APIs exist supporting use of OpenGL with Quartz, the MacOS X win-dow system, including CGL, AGL, and NSGLView. These APIs are documentedon Apple’s developer website.

The Khronos Native Platform Graphics Interface or “EGL Specification” de-scribes the EGL API for use of OpenGL ES on mobile and embedded devices.EGL implementations may be available supporting OpenGL as well. The EGLSpecification is available in the Khronos Extension Registry at URL

http://www.khronos.org/registry/egl


http://www.khronos.org/registry/egl

Chapter 2

OpenGL Operation

2.1 OpenGL Fundamentals

OpenGL (henceforth, the “GL”) is concerned only with rendering into a frame-buffer (and reading values stored in that framebuffer). There is no support forother peripherals sometimes associated with graphics hardware, such as mice andkeyboards. Programmers must rely on other mechanisms to obtain user input.

The GL draws primitives subject to a number of selectable modes and shaderprograms. Each primitive is a point, line segment, polygon, or pixel rectangle.Each mode may be changed independently; the setting of one does not affect thesettings of others (although many modes may interact to determine what eventuallyends up in the framebuffer). Modes are set, primitives specified, and other GLoperations described by sending commands in the form of function or procedurecalls.

Primitives are defined by a group of one or more vertices. A vertex defines apoint, an endpoint of an edge, or a corner of a polygon where two edges meet. Data(consisting of positional coordinates, colors, normals, and texture coordinates) areassociated with a vertex and each vertex is processed independently, in order, andin the same way. The only exception to this rule is if the group of vertices mustbe clipped so that the indicated primitive fits within a specified region; in thiscase vertex data may be modified and new vertices created. The type of clippingdepends on which primitive the group of vertices represents.

Commands are always processed in the order in which they are received, al-though there may be an indeterminate delay before the effects of a command arerealized. This means, for example, that one primitive must be drawn completelybefore any subsequent one can affect the framebuffer. It also means that queriesand pixel read operations return state consistent with complete execution of all

5

2.1. OPENGL FUNDAMENTALS 6

previously invoked GL commands, except where explicitly specified otherwise. Ingeneral, the effects of a GL command on either GL modes or the framebuffer mustbe complete before any subsequent command can have any such effects.

In the GL, data binding occurs on call. This means that data passed to a com-mand are interpreted when that command is received. Even if the command re-quires a pointer to data, those data are interpreted when the call is made, and anysubsequent changes to the data have no effect on the GL (unless the same pointeris used in a subsequent command).

The GL provides direct control over the fundamental operations of 3D and2D graphics. This includes specification of such parameters as vertex and frag-ment shaders, transformation matrices, lighting equation coefficients, antialiasingmethods, and pixel update operators. It does not provide a means for describingor modeling complex geometric objects. Another way to describe this situation isto say that the GL provides mechanisms to describe how complex geometric ob-jects are to be rendered rather than mechanisms to describe the complex objectsthemselves.

The model for interpretation of GL commands is client-server. That is, a pro-gram (the client) issues commands, and these commands are interpreted and pro-cessed by the GL (the server). The server may or may not operate on the samecomputer as the client. In this sense, the GL is “network-transparent.” A servermay maintain a number of GL contexts, each of which is an encapsulation of cur-rent GL state. A client may choose to connect to any one of these contexts. IssuingGL commands when the program is not connected to a context results in undefinedbehavior.

The GL interacts with two classes of framebuffers: window system-providedand application-created. There is at most one window system-provided frame-buffer at any time, referred to as the default framebuffer. Application-createdframebuffers, referred to as framebuffer objects, may be created as desired. Thesetwo types of framebuffer are distinguished primarily by the interface for configur-ing and managing their state.

The effects of GL commands on the default framebuffer are ultimately con-trolled by the window system, which allocates framebuffer resources, determineswhich portions of the default framebuffer the GL may access at any given time, andcommunicates to the GL how those portions are structured. Therefore, there areno GL commands to initialize a GL context or configure the default framebuffer.Similarly, display of framebuffer contents on a physical display device (includingthe transformation of individual framebuffer values by such techniques as gammacorrection) is not addressed by the GL.

Allocation and configuration of the default framebuffer occurs outside of theGL in conjunction with the window system, using companion APIs such as GLX,



WGL, and CGL for GL implementations running on the X Window System, Mi-crosoft Windows, and MacOS X respectively.

Allocation and initialization of GL contexts is also done using these companionAPIs. GL contexts can typically be associated with different default framebuffers,and some context state is determined at the time this association is performed.

It is possible to use a GL context without a default framebuffer, in which casea framebuffer object must be used to perform all rendering. This is useful forapplications neeting to perform offscreen rendering.

The GL is designed to be run on a range of graphics platforms with varyinggraphics capabilities and performance. To accommodate this variety, we specifyideal behavior instead of actual behavior for certain GL operations. In cases wheredeviation from the ideal is allowed, we also specify the rules that an implemen-tation must obey if it is to approximate the ideal behavior usefully. This allowedvariation in GL behavior implies that two distinct GL implementations may notagree pixel for pixel when presented with the same input even when run on identi-cal framebuffer configurations.

Finally, command names, constants, and types are prefixed in the GL (by gl,GL , and GL, respectively in C) to reduce name clashes with other packages. Theprefixes are omitted in this document for clarity.

2.1.1 Floating-Point Computation

The GL must perform a number of floating-point operations during the course ofits operation. In some cases, the representation and/or precision of such oper-ations is defined or limited; by the OpenGL Shading Language Specification foroperations in shaders, and in some cases implicitly limited by the specified formatof vertex, texture, or renderbuffer data consumed by the GL. Otherwise, the rep-resentation of such floating-point numbers, and the details of how operations onthem are performed, is not specified. We require simply that numbers’ floating-point parts contain enough bits and that their exponent fields are large enough sothat individual results of floating-point operations are accurate to about 1 part in105. The maximum representable magnitude of a floating-point number used torepresent positional, normal, or texture coordinates must be at least 232; the max-imum representable magnitude for colors must be at least 210. The maximumrepresentable magnitude for all other floating-point values must be at least 232.x · 0 = 0 · x = 0 for any non-infinite and non-NaN x. 1 · x = x · 1 = x.x+ 0 = 0 + x = x. 00 = 1. (Occasionally further requirements will be specified.)Most single-precision floating-point formats meet these requirements.

The special values Inf and −Inf encode values with magnitudes too large tobe represented; the special value NaN encodes “Not A Number” values resulting



from undefined arithmetic operations such as 10 . Implementations are permitted,but not required, to support Inf s and NaN s in their floating-point computations.

Any representable floating-point value is legal as input to a GL command thatrequires floating-point data. The result of providing a value that is not a floating-point number to such a command is unspecified, but must not lead to GL interrup-tion or termination. In IEEE arithmetic, for example, providing a negative zero or adenormalized number to a GL command yields predictable results, while providinga NaN or an infinity yields unspecified results.

Some calculations require division. In such cases (including implied divisionsrequired by vector normalizations), a division by zero produces an unspecified re-sult but must not lead to GL interruption or termination.

2.1.2 16-Bit Floating-Point Numbers

A 16-bit floating-point number has a 1-bit sign (S), a 5-bit exponent (E), and a10-bit mantissa (M ). The value V of a 16-bit floating-point number is determinedby the following:

V =

(−1)S × 0.0, E = 0,M = 0(−1)S × 2−14 × M

210, E = 0,M 6= 0

(−1)S × 2E−15 ×(1 + M

210

), 0 < E < 31

(−1)S × Inf , E = 31,M = 0NaN , E = 31,M 6= 0

If the floating-point number is interpreted as an unsigned 16-bit integerN , then

S =⌊N mod 65536

32768

⌋E =

⌊N mod 32768

1024

⌋M = N mod 1024.

Any representable 16-bit floating-point value is legal as input to a GL commandthat accepts 16-bit floating-point data. The result of providing a value that is not afloating-point number (such as Inf or NaN ) to such a command is unspecified, butmust not lead to GL interruption or termination. Providing a denormalized numberor negative zero to GL must yield predictable results.



2.1.3 Unsigned 11-Bit Floating-Point Numbers

An unsigned 11-bit floating-point number has no sign bit, a 5-bit exponent (E), anda 6-bit mantissa (M ). The value V of an unsigned 11-bit floating-point number isdetermined by the following:

V =

0.0, E = 0,M = 02−14 × M64 , E = 0,M 6= 02E−15 ×

(1 + M64

), 0 < E < 31

Inf , E = 31,M = 0NaN , E = 31,M 6= 0


E =⌊N

64

⌋M = N mod 64.

When a floating-point value is converted to an unsigned 11-bit floating-pointrepresentation, finite values are rounded to the closest representable finite value.While less accurate, implementations are allowed to always round in the directionof zero. This means negative values are converted to zero. Likewise, finite posi-tive values greater than 65024 (the maximum finite representable unsigned 11-bitfloating-point value) are converted to 65024. Additionally: negative infinity is con-verted to zero; positive infinity is converted to positive infinity; and both positiveand negative NaN are converted to positive NaN .

Any representable unsigned 11-bit floating-point value is legal as input to aGL command that accepts 11-bit floating-point data. The result of providing avalue that is not a floating-point number (such as Inf or NaN ) to such a commandis unspecified, but must not lead to GL interruption or termination. Providing adenormalized number to GL must yield predictable results.

2.1.4 Unsigned 10-Bit Floating-Point Numbers

An unsigned 10-bit floating-point number has no sign bit, a 5-bit exponent (E), anda 5-bit mantissa (M ). The value V of an unsigned 10-bit floating-point number isdetermined by the following:


2.2. GL STATE 10

V =

0.0, E = 0,M = 02−14 × M32 , E = 0,M 6= 02E−15 ×

(1 + M32

), 0 < E < 31

Inf , E = 31,M = 0NaN , E = 31,M 6= 0


E =⌊N

32

⌋M = N mod 32.

When a floating-point value is converted to an unsigned 10-bit floating-pointrepresentation, finite values are rounded to the closest representable finite value.While less accurate, implementations are allowed to always round in the directionof zero. This means negative values are converted to zero. Likewise, finite posi-tive values greater than 64512 (the maximum finite representable unsigned 10-bitfloating-point value) are converted to 64512. Additionally: negative infinity is con-verted to zero; positive infinity is converted to positive infinity; and both positiveand negative NaN are converted to positive NaN .

Any representable unsigned 10-bit floating-point value is legal as input to aGL command that accepts 10-bit floating-point data. The result of providing avalue that is not a floating-point number (such as Inf or NaN ) to such a commandis unspecified, but must not lead to GL interruption or termination. Providing adenormalized number to GL must yield predictable results.

2.2 GL State

The GL maintains considerable state. This document enumerates each state vari-able and describes how each variable can be changed. For purposes of discussion,state variables are categorized somewhat arbitrarily by their function. Although wedescribe the operations that the GL performs on the framebuffer, the framebufferis not a part of GL state.

We distinguish two types of state. The first type of state, called GL serverstate, resides in the GL server. The majority of GL state falls into this category.The second type of state, called GL client state, resides in the GL client. Unlessotherwise specified, all state referred to in this document is GL server state; GLclient state is specifically identified. Each instance of a GL context implies one


2.3. GL COMMAND SYNTAX 11

complete set of GL server state; each connection from a client to a server impliesa set of both GL client state and GL server state.

While an implementation of the GL may be hardware dependent, this discus-sion is independent of the specific hardware on which a GL is implemented. We aretherefore concerned with the state of graphics hardware only when it correspondsprecisely to GL state.

2.2.1 Shared Object State

It is possible for groups of contexts to share certain state. Enabling such sharingbetween contexts is done through window system binding APIs such as those de-scribed in section 1.7.2. These APIs are responsible for creation and managementof contexts, and not discussed further here. More detailed discussion of the behav-ior of shared objects is included in appendix D. Except as defined in this appendix,all state in a context is specific to that context only.

2.3 GL Command Syntax

GL commands are functions or procedures. Various groups of commands performthe same operation but differ in how arguments are supplied to them. To conve-niently accommodate this variation, we adopt a notation for describing commandsand their arguments.

GL commands are formed from a name followed, depending on the particularcommand, by up to 4 characters. The first character indicates the number of valuesof the indicated type that must be presented to the command. The second characteror character pair indicates the specific type of the arguments: 8-bit integer, 16-bitinteger, 32-bit integer, single-precision floating-point, or double-precision floating-point. The final character, if present, is v, indicating that the command takes apointer to an array (a vector) of values rather than a series of individual arguments.Two specific examples come from the Vertex command:

void Vertex3f( float x, float y, float z );

and

void Vertex2sv( short v[2] );

These examples show the ANSI C declarations for these commands. In general,a command declaration has the form1

1The declarations shown in this document apply to ANSI C. Languages such as C++ and Adathat allow passing of argument type information admit simpler declarations and fewer entry points.


2.3. GL COMMAND SYNTAX 12

Letter Corresponding GL Typeb bytes shorti intf floatd double

ub ubyteus ushortui uint

Table 2.1: Correspondence of command suffix letters to GL argument types. Referto table 2.2 for definitions of the GL types.

rtype Name{�1234}{� b s i f d ub us ui}{�v}( [args ,] T arg1 , . . . , T argN [, args] );

rtype is the return type of the function. The braces ({}) enclose a series of char-acters (or character pairs) of which one is selected. � indicates no character. Thearguments enclosed in brackets ([args ,] and [, args]) may or may not be present.TheN arguments arg1 through argN have type T, which corresponds to one of thetype letters or letter pairs as indicated in table 2.1 (if there are no letters, then thearguments’ type is given explicitly). If the final character is not v, then N is givenby the digit 1, 2, 3, or 4 (if there is no digit, then the number of arguments is fixed).If the final character is v, then only arg1 is present and it is an array of N valuesof the indicated type. Finally, we indicate an unsigned type by the shorthand ofprepending a u to the beginning of the type name (so that, for instance, unsignedchar is abbreviated uchar).

For example,

void Normal3{fd}( T arg );

indicates the two declarations

void Normal3f( float arg1, float arg2, float arg3 );void Normal3d( double arg1, double arg2, double arg3 );

while

void Normal3{fd}v( T arg );


2.4. BASIC GL OPERATION 13

means the two declarations

void Normal3fv( float arg[3] );void Normal3dv( double arg[3] );

Arguments whose type is fixed (i.e. not indicated by a suffix on the command)are of one of the GL data types summarized in table 2.2, or pointers to one of thesetypes.

2.4 Basic GL Operation

Figure 2.1 shows a schematic diagram of the GL. Commands enter the GL on theleft. Some commands specify geometric objects to be drawn while others controlhow the objects are handled by the various stages. Most commands may be ac-cumulated in a display list for processing by the GL at a later time. Otherwise,commands are effectively sent through a processing pipeline.

The first stage provides an efficient means for approximating curve and sur-face geometry by evaluating polynomial functions of input values. The next stageoperates on geometric primitives described by vertices: points, line segments, andpolygons. In this stage vertices are transformed and lit, and primitives are clippedto a viewing volume in preparation for the next stage, rasterization. The rasterizerproduces a series of framebuffer addresses and values using a two-dimensional de-scription of a point, line segment, or polygon. Each fragment so produced is fedto the next stage that performs operations on individual fragments before they fi-nally alter the framebuffer. These operations include conditional updates into theframebuffer based on incoming and previously stored depth values (to effect depthbuffering), blending of incoming fragment colors with stored colors, as well asmasking and other logical operations on fragment values.

Finally, there is a way to bypass the vertex processing portion of the pipeline tosend a block of fragments directly to the individual fragment operations, eventuallycausing a block of pixels to be written to the framebuffer; values may also be readback from the framebuffer or copied from one portion of the framebuffer to another.These transfers may include some type of decoding or encoding.

This ordering is meant only as a tool for describing the GL, not as a strict ruleof how the GL is implemented, and we present it only as a means to organize thevarious operations of the GL. Objects such as curved surfaces, for instance, maybe transformed before they are converted to polygons.


2.4. BASIC GL OPERATION 14

GL Type Minimum DescriptionBit Width

boolean 1 Booleanbyte 8 Signed 2’s complement binary integerubyte 8 Unsigned binary integerchar 8 Characters making up stringsshort 16 Signed 2’s complement binary integerushort 16 Unsigned binary integerint 32 Signed 2’s complement binary integeruint 32 Unsigned binary integersizei 32 Non-negative binary integer sizeenum 32 Enumerated binary integer valueintptr ptrbits Signed 2’s complement binary integersizeiptr ptrbits Non-negative binary integer sizebitfield 32 Bit fieldhalf 16 Half-precision floating-point value

encoded in an unsigned scalarfloat 32 Floating-point valueclampf 32 Floating-point value clamped to [0, 1]double 64 Floating-point valueclampd 64 Floating-point value clamped to [0, 1]time 64 Unsigned binary representing an ab-

solute absolute or relative time inter-val. Precision is nanoseconds but ac-curacy is implementation-dependent.

Table 2.2: GL data types. GL types are not C types. Thus, for example, GLtype int is referred to as GLint outside this document, and is not necessarilyequivalent to the C type int. An implementation may use more bits than thenumber indicated in the table to represent a GL type. Correct interpretation ofinteger values outside the minimum range is not required, however.ptrbits is the number of bits required to represent a pointer type; in other words,types intptr and sizeiptr must be sufficiently large as to store any address.


2.5. GL ERRORS 15

Display List

Evaluator

Per−VertexOperations Rasteriz−

ation

Per−FragmentOperations

Framebuffer

PixelOperations

PrimitiveAssembly

TextureMemory

Figure 2.1. Block diagram of the GL.

2.5 GL Errors

The GL detects only a subset of those conditions that could be considered errors.This is because in many cases error checking would adversely impact the perfor-mance of an error-free program.

The command

enum GetError( void );

is used to obtain error information. Each detectable error is assigned a numericcode. When an error is detected, a flag is set and the code is recorded. Furthererrors, if they occur, do not affect this recorded code. When GetError is called,the code is returned and the flag is cleared, so that a further error will again recordits code. If a call to GetError returns NO ERROR, then there has been no detectableerror since the last call to GetError (or since the GL was initialized).

To allow for distributed implementations, there may be several flag-code pairs.In this case, after a call to GetError returns a value other than NO ERROR eachsubsequent call returns the non-zero code of a distinct flag-code pair (in unspecifiedorder), until all non-NO ERROR codes have been returned. When there are no morenon-NO ERROR error codes, all flags are reset. This scheme requires some positivenumber of pairs of a flag bit and an integer. The initial state of all flags is clearedand the initial value of all codes is NO ERROR.


2.6. BEGIN/END PARADIGM 16

Table 2.3 summarizes GL errors. Currently, when an error flag is set, results ofGL operation are undefined only if OUT OF MEMORY has occurred. In other cases,the command generating the error is ignored so that it has no effect on GL state orframebuffer contents. If the generating command returns a value, it returns zero. Ifthe generating command modifies values through a pointer argument, no change ismade to these values. These error semantics apply only to GL errors, not to systemerrors such as memory access errors. This behavior is the current behavior; theaction of the GL in the presence of errors is subject to change.

Several error generation conditions are implicit in the description of every GLcommand:

• If a command that requires an enumerated value is passed a symbolic con-stant that is not one of those specified as allowable for that command, theerror INVALID ENUM is generated. This is the case even if the argument isa pointer to a symbolic constant, if the value pointed to is not allowable forthe given command.

• If a negative number is provided where an argument of type sizei orsizeiptr is specified, the error INVALID VALUE is generated.

• If memory is exhausted as a side effect of the execution of a command, theerror OUT OF MEMORY may be generated.

Otherwise, errors are generated only for conditions that are explicitly described inthis specification.

2.6 Begin/End Paradigm

In the GL, most geometric objects are drawn by enclosing a series of coordinatesets that specify vertices and optionally normals, texture coordinates, and colorsbetween Begin/End pairs. There are ten geometric objects that are drawn thisway: points, line segments, line segment loops, separated line segments, polygons,triangle strips, triangle fans, separated triangles, quadrilateral strips, and separatedquadrilaterals.

Each vertex is specified with two, three, or four coordinates. In addition, acurrent normal, multiple current texture coordinate sets, multiple current genericvertex attributes, current color, current secondary color, and current fog coor-dinate may be used in processing each vertex. Normals are used by the GL inlighting calculations; the current normal is a three-dimensional vector that may beset by sending three coordinates that specify it. Texture coordinates determine how



Error Description Offending com-mand ignored?

INVALID ENUM enum argument out of range YesINVALID VALUE Numeric argument out of range YesINVALID OPERATION Operation illegal in current state YesINVALID FRAMEBUFFER OPERATION Framebuffer object is not com-

pleteYes

STACK OVERFLOW Command would cause a stackoverflow

Yes

STACK UNDERFLOW Command would cause a stackunderflow

Yes

OUT OF MEMORY Not enough memory left to exe-cute command

Unknown

TABLE TOO LARGE The specified table is too large Yes

Table 2.3: Summary of GL errors

a texture image is mapped onto a primitive. Multiple sets of texture coordinatesmay be used to specify how multiple texture images are mapped onto a primitive.The number of texture units supported is implementation dependent but must beat least two. The number of texture units supported can be queried with the stateMAX TEXTURE UNITS. Generic vertex attributes can be accessed from within ver-tex shaders (section 2.20) and used to compute values for consumption by laterprocessing stages.

Primary and secondary colors are associated with each vertex (see sec-tion 3.10). These associated colors are either based on the current color and currentsecondary color or produced by lighting, depending on whether or not lighting isenabled. Texture and fog coordinates are similarly associated with each vertex.Multiple sets of texture coordinates may be associated with a vertex. Figure 2.2summarizes the association of auxiliary data with a transformed vertex to producea processed vertex.

The current values are part of GL state. Vertices and normals are transformed,colors may be affected or replaced by lighting, and texture coordinates are trans-formed and possibly affected by a texture coordinate generation function. Theprocessing indicated for each current value is applied for each vertex that is sent tothe GL.

The methods by which vertices, normals, texture coordinates, fog coordinate,generic attributes, and colors are sent to the GL, as well as how normals are trans-



CurrentEdge Flag & Fog Coord

lighting

vertex / normaltransformation

CurrentNormal

CurrentColors & Materials

AssociatedData

TransformedCoordinates

ProcessedVertex

Out

(Colors, Edge Flag,Fog and Texture

Coordinates)

VertexCoordinates In

texgen texturematrix 0

CurrentTexture

Coord Set 0


CurrentTexture

Coord Set 1


CurrentTexture

Coord Set 2


CurrentTexture

Coord Set 3

Figure 2.2. Association of current values with a vertex. The heavy lined boxes rep-resent GL state. Four texture units are shown; however, multitexturing may supporta different number of units depending on the implementation.



ProcessedVertices

Point,Line Segment, or

Polygon(Primitive)Assembly

Begin/EndState

Point culling;Line Segment or Polygon

Clipping

ColorProcessing

Rasterization

Coordinates

AssociatedData

Figure 2.3. Primitive assembly and processing.

formed and how vertices are mapped to the two-dimensional screen, are discussedlater.

Before colors have been assigned to a vertex, the state required by a vertexis the vertex’s coordinates, the current normal, the current edge flag (see sec-tion 2.6.2), the current material properties (see section 2.19.2), the current fog co-ordinate, the multiple generic vertex attribute sets, and the multiple current texturecoordinate sets. Because color assignment is done vertex-by-vertex, a processedvertex comprises the vertex’s coordinates, its edge flag, its fog coordinate, its as-signed colors, and its multiple texture coordinate sets.

Figure 2.3 shows the sequence of operations that builds a primitive (point, linesegment, or polygon) from a sequence of vertices. After a primitive is formed, itis clipped to a viewing volume. This may alter the primitive by altering vertexcoordinates, texture coordinates, and colors. In the case of line and polygon prim-itives, clipping may insert new vertices into the primitive. The vertices defining aprimitive to be rasterized have texture coordinates and colors associated with them.

2.6.1 Begin and End

Vertices making up one of the supported geometric object types are specified byenclosing commands defining those vertices between the two commands

void Begin( enum mode );void End( void );



There is no limit on the number of vertices that may be specified between a Beginand an End.

Points. A series of individual points may be specified by calling Begin with anargument value of POINTS. No special state need be kept between Begin and Endin this case, since each point is independent of previous and following points.

Line Strips. A series of one or more connected line segments is specified byenclosing a series of two or more endpoints within a Begin/End pair when Begin iscalled with LINE STRIP. In this case, the first vertex specifies the first segment’sstart point while the second vertex specifies the first segment’s endpoint and thesecond segment’s start point. In general, the ith vertex (for i > 1) specifies thebeginning of the ith segment and the end of the i − 1st. The last vertex specifiesthe end of the last segment. If only one vertex is specified between the Begin/Endpair, then no primitive is generated.

The required state consists of the processed vertex produced from the last ver-tex that was sent (so that a line segment can be generated from it to the currentvertex), and a boolean flag indicating if the current vertex is the first vertex.

Line Loops. Line loops, specified with the LINE LOOP argument value toBegin, are the same as line strips except that a final segment is added from the finalspecified vertex to the first vertex. The additional state consists of the processedfirst vertex.

Separate Lines. Individual line segments, each specified by a pair of vertices,are generated by surrounding vertex pairs with Begin and End when the valueof the argument to Begin is LINES. In this case, the first two vertices between aBegin and End pair define the first segment, with subsequent pairs of vertices eachdefining one more segment. If the number of specified vertices is odd, then the lastone is ignored. The state required is the same as for lines but it is used differently: avertex holding the first vertex of the current segment, and a boolean flag indicatingwhether the current vertex is odd or even (a segment start or end).

Polygons. A polygon is described by specifying its boundary as a series ofline segments. When Begin is called with POLYGON, the bounding line segmentsare specified in the same way as line loops. Depending on the current state of theGL, a polygon may be rendered in one of several ways such as outlining its borderor filling its interior. A polygon described with fewer than three vertices does notgenerate a primitive.

Only convex polygons are guaranteed to be drawn correctly by the GL. If aspecified polygon is nonconvex when projected onto the window, then the renderedpolygon need only lie within the convex hull of the projected vertices defining itsboundary.

The state required to support polygons consists of at least two processed ver-tices (more than two are never required, although an implementation may use



(a) (b) (c)

1

2

3

4

5 1

23

4

51

2

3

4

5

6

Figure 2.4. (a) A triangle strip. (b) A triangle fan. (c) Independent triangles. Thenumbers give the sequencing of the vertices between Begin and End. Note that in(a) and (b) triangle edge ordering is determined by the first triangle, while in (c) theorder of each triangle’s edges is independent of the other triangles.

more); this is because a convex polygon can be rasterized as its vertices arrive,before all of them have been specified. The order of the vertices is significant inlighting and polygon rasterization (see sections 2.19.1 and 3.6.1).

Triangle strips. A triangle strip is a series of triangles connected along sharededges. A triangle strip is specified by giving a series of defining vertices betweena Begin/End pair when Begin is called with TRIANGLE STRIP. In this case, thefirst three vertices define the first triangle (and their order is significant, just as forpolygons). Each subsequent vertex defines a new triangle using that point alongwith two vertices from the previous triangle. A Begin/End pair enclosing fewerthan three vertices, when TRIANGLE STRIP has been supplied to Begin, producesno primitive. See figure 2.4.

The state required to support triangle strips consists of a flag indicating if thefirst triangle has been completed, two stored processed vertices, (called vertex Aand vertex B), and a one bit pointer indicating which stored vertex will be replacedwith the next vertex. After a Begin(TRIANGLE STRIP), the pointer is initializedto point to vertex A. Each vertex sent between a Begin/End pair toggles the pointer.Therefore, the first vertex is stored as vertex A, the second stored as vertex B, thethird stored as vertex A, and so on. Any vertex after the second one sent forms atriangle from vertex A, vertex B, and the current vertex (in that order).

Triangle fans. A triangle fan is the same as a triangle strip with one exception:each vertex after the first always replaces vertex B of the two stored vertices. The



1

2

3

4

5

6

1

2 3

4 5

6 7

8

(a) (b)

Figure 2.5. (a) A quad strip. (b) Independent quads. The numbers give the sequenc-ing of the vertices between Begin and End.

vertices of a triangle fan are enclosed between Begin and End when the value ofthe argument to Begin is TRIANGLE FAN.

Separate Triangles. Separate triangles are specified by placing vertices be-tween Begin and End when the value of the argument to Begin is TRIANGLES. Inthis case, The 3i + 1st, 3i + 2nd, and 3i + 3rd vertices (in that order) determinea triangle for each i = 0, 1, . . . , n − 1, where there are 3n + k vertices betweenthe Begin and End. k is either 0, 1, or 2; if k is not zero, the final k vertices areignored. For each triangle, vertex A is vertex 3i and vertex B is vertex 3i + 1.Otherwise, separate triangles are the same as a triangle strip.

The rules given for polygons also apply to each triangle generated from a tri-angle strip, triangle fan or from separate triangles.

Quadrilateral (quad) strips. Quad strips generate a series of edge-sharingquadrilaterals from vertices appearing between Begin and End, when Begin iscalled with QUAD STRIP. If the m vertices between the Begin and End arev1, . . . , vm, where vj is the jth specified vertex, then quad i has vertices (in or-der) v2i, v2i+1, v2i+3, and v2i+2 with i = 0, . . . , bm/2c. The state required is thusthree processed vertices, to store the last two vertices of the previous quad alongwith the third vertex (the first new vertex) of the current quad, a flag to indicatewhen the first quad has been completed, and a one-bit counter to count membersof a vertex pair. See figure 2.5.

A quad strip with fewer than four vertices generates no primitive. If the numberof vertices specified for a quadrilateral strip between Begin and End is odd, thefinal vertex is ignored.



Separate Quadrilaterals Separate quads are just like quad strips except thateach group of four vertices, the 4j + 1st, the 4j + 2nd, the 4j + 3rd, and the4j + 4th, generate a single quad, for j = 0, 1, . . . , n − 1. The total number ofvertices between Begin and End is 4n+ k, where 0 ≤ k ≤ 3; if k is not zero, thefinal k vertices are ignored. Separate quads are generated by calling Begin withthe argument value QUADS.

The rules given for polygons also apply to each quad generated in a quad stripor from separate quads.

The state required for Begin and End consists of an eleven-valued integer indi-cating either one of the ten possible Begin/End modes, or that no Begin/End modeis being processed.

Calling Begin will result in an INVALID FRAMEBUFFER OPERATION error ifthe object bound to DRAW FRAMEBUFFER BINDING is not framebuffer complete(see section 4.4.4).

2.6.2 Polygon Edges

Each edge of each primitive generated from a polygon, triangle strip, triangle fan,separate triangle set, quadrilateral strip, or separate quadrilateral set, is flagged aseither boundary or non-boundary. These classifications are used during polygonrasterization; some modes affect the interpretation of polygon boundary edges (seesection 3.6.4). By default, all edges are boundary edges, but the flagging of poly-gons, separate triangles, or separate quadrilaterals may be altered by calling

void EdgeFlag( boolean flag );void EdgeFlagv( boolean *flag );

to change the value of a flag bit. If flag is zero, then the flag bit is set to FALSE; ifflag is non-zero, then the flag bit is set to TRUE.

When Begin is supplied with one of the argument values POLYGON,TRIANGLES, or QUADS, each vertex specified within a Begin and End pair be-gins an edge. If the edge flag bit is TRUE, then each specified vertex begins an edgethat is flagged as boundary. If the bit is FALSE, then induced edges are flagged asnon-boundary.

The state required for edge flagging consists of one current flag bit. Initially, thebit is TRUE. In addition, each processed vertex of an assembled polygonal primitivemust be augmented with a bit indicating whether or not the edge beginning on thatvertex is boundary or non-boundary.


2.7. VERTEX SPECIFICATION 24

2.6.3 GL Commands within Begin/End

The only GL commands that are allowed within any Begin/End pairs are the com-mands for specifying vertex coordinates, vertex colors, normal coordinates, texturecoordinates, generic vertex attributes, and fog coordinates (Vertex, Color, Sec-ondaryColor, Index, Normal, TexCoord and MultiTexCoord, VertexAttrib,FogCoord), the ArrayElement command (see section 2.8), the EvalCoord andEvalPoint commands (see section 5.1), commands for specifying lighting mate-rial parameters (Material commands; see section 2.19.2), display list invocationcommands (CallList and CallLists; see section 5.4), and the EdgeFlag command.Executing any other GL command between the execution of Begin and the corre-sponding execution of End results in the error INVALID OPERATION. ExecutingBegin after Begin has already been executed but before an End is executed gen-erates the INVALID OPERATION error, as does executing End without a previouscorresponding Begin.

Execution of the commands EnableClientState, DisableClientState, Push-ClientAttrib, PopClientAttrib, ColorPointer, FogCoordPointer, EdgeFlag-Pointer, IndexPointer, NormalPointer, TexCoordPointer, SecondaryCol-orPointer, VertexPointer, VertexAttribPointer, ClientActiveTexture, Inter-leavedArrays, and PixelStore is not allowed within any Begin/End pair, but anerror may or may not be generated if such execution occurs. If an error is not gen-erated, GL operation is undefined. (These commands are described in sections 2.8,3.7.1, and chapter 6.)

2.7 Vertex Specification

Vertices are specified by giving their coordinates in two, three, or four dimensions.This is done using one of several versions of the Vertex command:

void Vertex{234}{sifd}( T coords );void Vertex{234}{sifd}v( T coords );

A call to any Vertex command specifies four coordinates: x, y, z, and w. Thex coordinate is the first coordinate, y is second, z is third, and w is fourth. Acall to Vertex2 sets the x and y coordinates; the z coordinate is implicitly set tozero and the w coordinate to one. Vertex3 sets x, y, and z to the provided valuesand w to one. Vertex4 sets all four coordinates, allowing the specification of anarbitrary point in projective three-space. Invoking a Vertex command outside of aBegin/End pair results in undefined behavior.



Current values are used in associating auxiliary data with a vertex as describedin section 2.6. A current value may be changed at any time by issuing an appropri-ate command. The commands

void TexCoord{1234}{sifd}( T coords );void TexCoord{1234}{sifd}v( T coords );

specify the current homogeneous texture coordinates, named s, t, r, and q. TheTexCoord1 family of commands set the s coordinate to the provided single argu-ment while setting t and r to 0 and q to 1. Similarly, TexCoord2 sets s and t to thespecified values, r to 0 and q to 1; TexCoord3 sets s, t, and r, with q set to 1, andTexCoord4 sets all four texture coordinates.

Implementations must support at least two sets of texture coordinates. Thecommands

void MultiTexCoord{1234}{sifd}(enum texture,T coords)void MultiTexCoord{1234}{sifd}v(enum texture,T

coords)

take the coordinate set to be modified as the texture parameter. texture is a symbolicconstant of the form TEXTUREi, indicating that texture coordinate set i is to bemodified. The constants obey TEXTUREi = TEXTURE0 + i (i is in the range 0 tok− 1, where k is the implementation-dependent number of texture coordinate setsdefined by MAX TEXTURE COORDS).

The TexCoord commands are exactly equivalent to the corresponding Multi-TexCoord commands with texture set to TEXTURE0.

Gets of CURRENT TEXTURE COORDS return the texture coordinate set definedby the value of ACTIVE TEXTURE.

Specifying an invalid texture coordinate set for the texture argument of Multi-TexCoord results in undefined behavior.

The current normal is set using

void Normal3{bsifd}( T coords );void Normal3{bsifd}v( T coords );

Byte, short, or integer values passed to Normal are converted to floating-pointvalues as indicated for the corresponding (signed) type in table 2.10.

The current fog coordinate is set using

void FogCoord{fd}( T coord );void FogCoord{fd}v( T coord );



There are several ways to set the current color and secondary color. The GLstores a current single-valued color index, as well as a current four-valued RGBAcolor and secondary color. Either the index or the color and secondary color aresignificant depending as the GL is in color index mode or RGBA mode. The modeselection is made when the GL is initialized.

The commands to set RGBA colors are

void Color{34}{bsifd ubusui}( T components );void Color{34}{bsifd ubusui}v( T components );void

The OpenGL Graphics System: A Specification · 9/23/2008 · The OpenGL R Graphics System: A...

Documents

Transcript of The OpenGL Graphics System: A Specification · 9/23/2008 · The OpenGL R Graphics System: A...