OpenGL Insights

(1)

(2)

(3)

(4)

OpenGL Insights

Edited by

Patrick Cozzi and Christophe Riccio

(5)

CRC Press

Taylor & Francis Group

6000 Broken Sound Parkway NW, Suite 300 Boca Raton, FL 33487-2742

CRC Press is an imprint of Taylor & Francis Group, an Informa business No claim to original U.S. Government works

Version Date: 20120508

International Standard Book Number-13: 978-1-4398-9377-7 (eBook - PDF)

This book contains information obtained from authentic and highly regarded sources. Reasonable efforts have been made to publish reliable data and information, but the author and publisher cannot assume responsibility for the validity of all materials or the consequences of their use. The authors and publishers have attempted to trace the copyright holders of all material reproduced in this publication and apologize to copyright holders if permission to publish in this form has not been obtained.

If any copyright material has not been acknowledged please write and let us know so we may rectify in any future reprint.

Except as permitted under U.S. Copyright Law, no part of this book may be reprinted, reproduced, transmitted, or utilized in any form by any electronic, mechanical, or other means, now known or hereafter invented, including photocopying, microfilming, and recording, or in any information storage or retrieval system, without written permission from the publishers.

For permission to photocopy or use material electronically from this work, please access www.copyright.com (http://www.copyright.com/) or contact the Copyright Clearance Center, Inc. (CCC), 222 Rosewood Drive, Danvers, MA 01923, 978-750-8400. CCC is a not-for-profit organization that provides licenses and registration for a variety of users. For organizations that have been granted a photocopy license by the CCC, a separate system of payment has been arranged.

Trademark Notice: Product or corporate names may be trademarks or registered trademarks, and are used only for identification and explanation without intent to infringe.

Visit the Taylor & Francis Web site at http://www.taylorandfrancis.com and the CRC Press Web site at

(6)

Boca Raton, FL 33487-2742

CRC Press is an imprint of Taylor & Francis Group, an Informa business No claim to original U.S. Government works

Printed in the United States of America on acid-free paper Version Date: 20120508

International Standard Book Number: 978-1-4398-9376-0 (Hardback)

This book contains information obtained from authentic and highly regarded sources. Reasonable efforts have been made to publish reliable data and information, but the author and publisher cannot assume responsibility for the validity of all materials or the consequences of their use. The authors and publishers have attempted to trace the copyright holders of all material reproduced in this publication and apologize to copyright holders if permission to publish in this form has not been obtained.

If any copyright material has not been acknowledged please write and let us know so we may rectify in any future reprint.

Except as permitted under U.S. Copyright Law, no part of this book may be reprinted, reproduced, transmitted, or utilized in any form by any electronic, mechanical, or other means, now known or hereafter invented, including photocopying, microfilming, and recording, or in any information storage or retrieval system, without written permission from the publishers.

For permission to photocopy or use material electronically from this work, please access www.copyright.com (http://www.copyright.com/) or contact the Copyright Clearance Center, Inc. (CCC), 222 Rosewood Drive, Danvers, MA 01923, 978-750-8400. CCC is a not-for-profit organization that provides licenses and registration for a variety of users. For organizations that have been granted a photocopy license by the CCC, a separate system of payment has been arranged.

(7)

To Jilda.

—Patrick

To my personal stylist

for unleashing my passion for graphics with her passion for style.

—Christophe

(8)

(9)

I Discovering 1

1 Teaching Computer Graphics Starting with Shader-Based

OpenGL 3 OpenGL

Edward Angel

1.1 Introduction . . . 3

1.2 A Basic Course . . . 4

1.3 Hello World in OpenGL: Old Style . . . 4

1.4 Starting with Programmable Pipelines . . . 6

1.5 Hello World: New Style . . . 8

1.6 The Rest of the Course . . . 10

1.7 Conclusion . . . 15

Bibliography . . . 16

2 Transitioning Students to Post-Deprecation OpenGL 17 OpenGL Mike Bailey 2.1 Introduction . . . 17

2.2 Naming Shader Variables: Introduction . . . 18

2.3 Naming Shader Variables: Details . . . 18

2.4 Indexed Vertex Buffer Object C++ Class . . . 20

2.5 GLSLProgram C++ Class . . . 23

(10)

3 WebGL for OpenGL Developers 27

OpenGL

WebGL Patrick Cozzi and Scott Hunter

3.2 The Benefits of WebGL . . . 28

3.3 Security . . . 34

3.4 Deploying Shaders . . . 36

3.5 The JavaScript Language . . . 37

3.6 Resources . . . 45

4 Porting Mobile Apps to WebGL 47 WebGL OpenGL ES Ashraf Samy Hegab 4.1 Introduction . . . 47

4.2 OpenGL across Platforms . . . 47

4.3 Getting Started . . . 48

4.4 Loading Textures . . . 51

4.5 Camera and Matrices . . . 53

4.6 Controls . . . 54

4.7 Other Considerations . . . 56

4.8 Maintenance . . . 57

5 The GLSL Shader Interfaces 61 OpenGL Christophe Riccio 5.1 Introduction . . . 61

5.2 Variables and Blocks . . . 62

5.3 Locations . . . 64

5.4 Matching Interfaces . . . 68

5.5 Working with Semantics . . . 77

5.6 Application-Side Validations for Debug Build Only . . . 82

6 An Introduction to Tessellation Shaders 87 OpenGL Philip Rideout and Dirk Van Gelder 6.1 Introduction . . . 87

6.2 The New Shading Pipeline . . . 90

6.3 Tessellating a Teapot . . . 99

6.4 Isolines and Spirals . . . 102

6.5 Incorporating Other OpenGL Features . . . 103

(11)

Contents ix

7 Procedural Textures in GLSL 105 OpenGL

WebGL OpenGL ES

Stefan Gustavson

7.2 Simple Functions . . . 107

7.3 Antialiasing . . . 108

7.4 Perlin Noise . . . 110

7.5 Worley Noise . . . 113

7.6 Animation . . . 115

7.7 Texture Images . . . 115

7.8 Performance . . . 118

8 OpenGL SC Emulation Based on OpenGL and OpenGL ES 121 OpenGL OpenGL ES OpenGL SC Hwanyong Lee and Nakhoon Baek 8.1 Introduction . . . 121

8.2 OpenGL SC Implementations . . . 123

8.3 Design and Implementation . . . 125

8.4 Results . . . 129

9 Mixing Graphics and Compute with Multiple GPUs 133 OpenGL Alina Alt 9.1 Introduction . . . 133

9.2 Graphics and Compute Interoperability on an API Level . . . . 134

9.3 Graphics and Compute Interoperability on a System Level . . . 138

II Rendering Techniques 143

10 GPU Tessellation: We Still Have a LOD of Terrain to Cover 145 OpenGL Ant ´onio Ramires Fernandes and Bruno Oliveira 10.1 Introduction . . . 145

10.2 Rendering Terrains with OpenGL GPU Tessellation . . . 146

10.3 A Simple Approach to Dynamic Level of Detail . . . 149

10.4 Roughness: When Detail Matters . . . 152

10.5 Crunching Numbers, or Is This All That Matters? . . . 153

(12)

11 Antialiased Volumetric Lines Using Shader-Based Extrusion 163

OpenGL WebGL OpenGL ES

S ´ebastien Hillaire

11.2 Antialiased Lines Using Postprocess Antialiasing . . . 164

11.3 Antialiased Volumetric Lines Using Geometry Extrusion . . . . 165

12 2D Shape Rendering by Distance Fields 173 OpenGL WebGL OpenGL ES Stefan Gustavson 12.1 Introduction . . . 173

12.2 Method Overview . . . 174

12.3 Better Distance Fields . . . 176

12.4 Distance Textures . . . 176

12.5 Hardware Accelerated Distance Transform . . . 177

12.6 Fragment Rendering . . . 177

12.7 Special Effects . . . 179

12.9 Shortcomings . . . 180

12.10Conclusion . . . 181

13 Efficient Text Rendering in WebGL 183 WebGL Benjamin Encz 13.1 Introduction . . . 183

13.2 Canvas-Based Font Rendering . . . 184

13.3 Bitmap Font Rendering . . . 187

13.4 Comparison . . . 190

14 Layered Textures Rendering Pipeline 195 OpenGL Dzmitry Malyshau 14.1 Introduction . . . 195

14.2 Layered Pipeline . . . 197

14.3 Results . . . 202

(13)

Contents xi

15 Depth of Field with Bokeh Rendering 205 OpenGL

Charles de Rousiers and Matt Pettineo

15.2 Depth of Field Phenomemon . . . 206

15.3 Related Work . . . 208

15.4 Algorithm . . . 209

15.5 Results . . . 214

15.6 Discussion . . . 216

16 Shadow Proxies 219 OpenGL Jochem van der Spek 16.1 Introduction . . . 219

16.2 Anatomy of a Shadow Proxy . . . 221

16.3 Setting Up the Pipeline . . . 223

16.4 The ShadowProxy-Enabled Fragment Shader . . . 224

16.5 Modulating the Shadow Volume . . . 226

16.7 Conclusion and Future Work . . . 228

III Bending the Pipeline 229

17 Real-Time Physically Based Deformation Using Transform Feedback 231 OpenGL Muhammad Mobeen Movania and Lin Feng 17.1 Introduction . . . 231

17.2 Hardware Support and Evolution of Transform Feedback . . . . 232

17.3 The Mechanism of Transform Feedback . . . 233

17.4 Mathematical Model . . . 234

17.5 Implementation . . . 238

17.6 Experimental Results and Comparisons . . . 244

18 Hierarchical Depth Culling and Bounding-Box Management on the GPU 247 OpenGL Dzmitry Malyshau 18.1 Introduction . . . 247

18.2 Pipeline . . . 248

(14)

18.3 Order of Operations . . . 254

18.4 Experimental Results . . . 255

18.5 Conclusion and Future Work . . . 257

19 Massive Number of Shadow-Casting Lights with Layered Rendering 259 OpenGL Daniel R ´akos 19.1 Introduction . . . 259

19.2 Traditional Shadow Map Rendering in OpenGL . . . 260

19.3 Our Shadow Map Generation Algorithm . . . 263

19.5 Advanced Techniques . . . 275

19.6 Limitations . . . 276

20 Efficient Layered Fragment Buffer Techniques 279 OpenGL Pyarelal Knowles, Geoff Leach, and Fabio Zambetta 20.1 Introduction . . . 279

20.2 Related Work . . . 281

20.3 The Linked-List LFB . . . 282

20.4 The Linearized LFB . . . 283

20.5 Performance Results . . . 286

21 Programmable Vertex Pulling 293 OpenGL Daniel R ´akos 21.1 Introduction . . . 293

21.4 Application . . . 298

21.5 Limitations . . . 299

22 Octree-Based Sparse Voxelization Using the GPU Hardware Rasterizer 303 OpenGL Cyril Crassin and Simon Green 22.1 Introduction . . . 303

22.2 Previous Work . . . 304

(15)

Contents xiii

22.3 Unrestricted Memory Access in GLSL . . . 305

22.4 Simple Voxelization Pipeline . . . 306

22.5 Sparse Voxelization into an Octree . . . 312

IV Performance 321

23 Performance Tuning for Tile-Based Architectures 323 WebGL OpenGL ES Bruce Merry 23.1 Introduction . . . 323

23.2 Background . . . 324

23.3 Clearing and Discarding the Framebuffer . . . 326

23.4 Incremental Frame Updates . . . 328

23.5 Flushing . . . 329

23.6 Latency . . . 330

23.7 Hidden Surface Removal . . . 332

23.8 Blending . . . 333

23.9 Multisampling . . . 333

23.10Performance Profiling . . . 334

23.11Summary . . . 335

24 Exploring Mobile vs. Desktop OpenGL Performance 337 OpenGL WebGL OpenGL ES Jon McCaffrey 24.1 Introduction . . . 337

24.2 Important Differences and Constraints . . . 338

24.3 Reducing Memory Bandwidth . . . 341

24.4 Reducing Fragment Workload . . . 345

24.5 Vertex Shading . . . 349

25 Improving Performance by Reducing Calls to the Driver 353 OpenGL S ´ebastien Hillaire 25.1 Introduction . . . 353

25.2 Efficient OpenGL States Usage . . . 354

25.3 Batching and Instancing . . . 357

(16)

26 Indexing Multiple Vertex Arrays 365

Arnaud Masserann

26.2 The Problem . . . 365

26.3 An Algorithm . . . 368

26.4 Vertex Comparison Methods . . . 369

27 Multi-GPU Rendering on NVIDIA Quadro 375 OpenGL Shalini Venkataraman 27.1 Introduction . . . 375

27.2 Previous Scaling Approaches . . . 376

27.3 Targeting a Specific GPU for Rendering . . . 377

27.4 Optimized Data Transfer between GPUs . . . 382

27.5 Application Structure for Multi-GPU . . . 383

27.6 Parallel Rendering Methodologies . . . 385

V Transfers 389

28 Asynchronous Buffer Transfers 391 OpenGL Ladislav Hrabcak and Arnaud Masserann 28.1 Introduction . . . 391

28.2 Buffer Objects . . . 392

28.3 Upload . . . 398

28.4 Download . . . 402

28.5 Copy . . . 405

28.6 Multithreading and Shared Contexts . . . 405

28.7 Usage Scenario . . . 408

29 Fermi Asynchronous Texture Transfers 415 OpenGL Shalini Venkataraman 29.1 Introduction . . . 415

29.2 OpenGL Command Buffer Execution . . . 417

(17)

Contents xv

29.3 Current Texture Transfer Approaches . . . 418

29.4 GPU Asynchronous Texture Transfers . . . 421

29.5 Implementation Details . . . 423

29.6 Results and Analysis . . . 425

30 WebGL Models: End-to-End 431 WebGL Won Chun 30.1 Introduction . . . 431

30.2 Life of a 3D Model . . . 432

30.3 A Coherent Whole . . . 441

30.4 Key Improvements . . . 447

31 In-Game Video Capture with Real-Time Texture Compression 455 OpenGL Brano Kemen 31.1 Introduction . . . 455

31.2 Overview of DXT Compression . . . 456

31.3 DXT Compression Algorithms . . . 456

31.4 Transformation to YUV Style Color Spaces . . . 458

31.5 Comparison . . . 460

31.6 Using Real-Time DXT Compression for Procedural Content and Video Capture . . . 462

32 An OpenGL-Friendly Geometry File Format and Its Maya Exporter 467 OpenGL OpenGL ES Adrien Herubel and Venceslas Biri 32.1 Introduction . . . 467

32.2 Manifesto . . . 468

32.3 The Drone Format . . . 469

32.4 Writing a Maya File Translator . . . 474

32.5 Results . . . 477

(18)

VI Debugging and Profiling 481

33 ARB debug output: A Helping Hand for Desperate

Developers 483

OpenGL

Ant ´onio Ramires Fernandes and Bruno Oliveira

33.2 Exposing the Extension . . . 484

33.3 Using a Callback Function . . . 484

33.4 Sorting Through the Cause of Events . . . 485

33.5 Accessing the Message Log . . . 486

33.6 Adding Custom User Events to the Log . . . 487

33.7 Controlling the Event Output Volume . . . 488

33.8 Preventing Impact on the Final Release . . . 488

33.9 Clash of the Titans: Implementation Strategies . . . 489

33.10Further Thoughts on Debugging . . . 491

33.11Conclusion . . . 491

34 The OpenGL Timer Query 493 OpenGL Christopher Lux 34.1 Introduction . . . 493

34.2 Measuring OpenGL Execution Times . . . 495

35 A Real-Time Profiling Tool 503 OpenGL Lionel Fuentes 35.1 Introduction . . . 503

35.2 Scope and Requirements . . . 504

35.3 Design of the Tool . . . 505

35.5 Using the Profiler . . . 510

35.6 Conclusions . . . 512

36 Browser Graphics Analysis and Optimizations 513 WebGL Chris Dirks and Omar A. Rodriguez 36.1 Introduction . . . 513

36.2 The Stages of Bloom . . . 514

36.3 Overhead of Bloom . . . 515

36.4 Analyzing WebGL Applications . . . 516

36.5 Analysis Workflow on Windows . . . 519

(19)

Contents xvii

36.6 Optimized Bloom . . . 522

37 Performance State Tracking 527 OpenGL Aleksandar Dimitrijevi´c 37.1 Introduction . . . 527

37.2 Power Consumption Policies . . . 528

37.3 P-State Tracking Using NVAPI . . . 528

37.4 P-State Tracking Using ADL . . . 532

38 Monitoring Graphics Memory Usage 535 OpenGL Aleksandar Dimitrijevi´c 38.1 Introduction . . . 535

38.2 Graphics Memory Allocation . . . 536

38.3 Querying Memory Status on NVIDIA Cards . . . 537

38.4 Querying Memory Status on AMD Cards . . . 538

VII Software Design 541

39 The ANGLE Project: Implementing OpenGL ES 2.0 on Direct3D 543 WebGL OpenGL ES Daniel Koch and Nicolas Capens 39.1 Introduction . . . 543

39.2 Background . . . 543

39.4 Future Work . . . 568

39.6 Source Code . . . 569

40 SceneJS: A WebGL-Based Scene Graph Engine 571 WebGL Lindsay Kay 40.1 Introduction . . . 571

40.2 Efficiently Abstracting WebGL . . . 572

40.3 Optimizing the Scene . . . 578

(20)

40.4 Picking . . . 580

41 Features and Design Choices in SpiderGL 583 WebGL Marco Di Benedetto, Fabio Ganovelli, and Francesco Banterle 41.1 Introduction . . . 583

41.2 Library Architecture . . . 584

41.3 Representing 3D Objects . . . 585

41.4 Direct Access to WebGL Object State . . . 590

41.5 WebGLObject Wrappers . . . 598

42 Multimodal Interactive Simulations on the Web 605 WebGL Tansel Halic, Woojin Ahn, Suvranu De 42.1 Introduction . . . 605

42.2 Π-SoFMIS Design and Definitions of Modules . . . 606

42.3 Framework Implementation . . . 607

42.4 Rendering Module . . . 609

42.5 Simulation Module . . . 611

42.6 Hardware Module . . . 613

42.7 Case Study: LAGB Simulator . . . 614

43 A Subset Approach to Using OpenGL and OpenGL ES 621 OpenGL OpenGL ES Jesse Barker and Alexandros Frantzis 43.1 Introduction . . . 621

43.2 Making Legacy Code Modern . . . 622

43.3 Keeping Code Maintainable across API Variants . . . 626

43.4 What if I Need a Specific Piece of Functionality? . . . 633

44 The Build Syndrome 635 OpenGL OpenGL ES Jochem van der Spek and Daniel Dekkers 44.1 Introduction . . . 635

44.2 Using Utility Libraries . . . 637

44.3 OpenGL Agnosticism . . . 640

44.4 Configuration Spaces . . . 642

44.5 Metabuilds and CMake . . . 643

(21)

Contents xix

44.6 CMake and the Configuration Space . . . 644

44.7 CMake and Platform Specifics . . . 648

About the Contributors 657

Index 673

(22)

(23)

Foreword

Barthold Lichtenbelt

OpenGL is not a single API anymore. OpenGL has involved into a family of APIs, with OpenGL, OpenGL ES, and WebGL being closely related siblings that enable application developers to write and deploy graphics applications on a wide variety of platforms and operating systems. OpenGL has become an ecosystem; 3D graphics is truly everywhere now. OpenGL is the cross platform 3D API for desktop machines and work stations. OpenGL ES is the 3D API for mobile devices, like tablets and cell phones, and embedded platforms from settop boxes to cars. WebGL ties this all together by providing a pervasive 3D API in browsers, based on OpenGL ES, that run on any platform. It doesn’t stop with graphics. Combining the use of OpenGL with a compute API like OpenCL or CUDA enables the creation of amazing visual computing applications on the desktop.

It is Khronos’ job to provide APIs that serve their targeted developers, their mar- kets, and their platforms, while encouraging silicon vendors to innovate underneath the API. Because the power consumption budget, hardware gate budget, and cost budget is larger for desktop GPUs than it is for mobile GPUs, the 3D API reflects this. Hence, OpenGL will generally be the first to expose leading edge functionality, on desktop platforms. The focus for OpenGL ES is to provide maximum functionality with the most optimal hardware and power budget for mobile and embedded devices. WebGL has a unifying focus; the goal for WebGL is to provide the same functionality everywhere, regardless of whether the underlying platform is capable of OpenGL 4.2 or OpenGL ES 2.0. This is fundamental to achieving the browser vision of “write once, deploy everywhere.” It is exciting to see WebGL provide access to the GPU, and therefore hardware accelerated 3D rendering, everywhere. The HTML5 standard provides a rich set of APIs to develop web applications. WebGL is leading the way to do so in a hardware accelerated way within HTML5. This will truly transform the type of web applications that will be available to us to enjoy, precisely because WebGL integrates into the HTML5 standard.

(24)

Given the widespread adoption of OpenGL and OpenGL ES across all flavors of Linux and Windows, as well as iOS and Android, these APIs are serving a real need.

The adoption of WebGL by almost all browser vendors underscores its importance as a web API for 3D graphics. Exquisite graphics applications have been developed using the OpenGL family of APIs. Of course there is much more to developing a great graphics application than the API. The ability to debug GPU code, to measure and optimize performance of graphics code to push the GPU to its limits, to use the right rendering technique given the underlying GPU, and to deploy that code to a wide variety of devices, are all critical factors to success.

This book explores the OpenGL ecosystem in depth. It provides debugging and performance tips, rendering techniques, clever tricks, software development, and porting advice, as well as best practices written by experts in various areas of the OpenGL ecosystem, to help you build the perfect graphics application. These experts have put in effort and time to share their OpenGL insights with us because they passionately believe in the OpenGL ecosystem and want to share that passion with us. This includes Patrick Cozzi and Christophe Riccio, who have done an amazing job editing and puttingOpenGL Insightstogether. Thank you for sharing!

—Barthold Lichtenbelt Khronos OpenGL ARB working group chair Director of Tegra graphics software for NVIDIA

(25)

Preface

Sometimes I wish I had been involved in computer graphics 40 years ago when the field was unfolding with early research in visible surfaces and shading. There were many fundamental problems to solve, and the forthcoming solutions would have a great impact.

However, I’m grateful for the time we live in; the foundations of modeling, rendering, and animation are well established. Hardware-accelerated rendering is available on practically all devices. As developers, we are now capable of reaching an immense number of users with captivating, real-time graphics.

In part, we have the swiftness and availability of rendering APIs, including OpenGL, OpenGL ES, and WebGL, to thank. Frequent OpenGL specification updates coupled with drivers exposing these new features make OpenGL the API of choice for cross-platform desktop developers seeking access to recent GPU capa- bilities. With the explosion of smartphones and tablets, OpenGL ES istheAPI for hardware-accelerated rendering on iOS and Android. Even more recently, WebGL has rapidly emerged to provide truly zero-footprint hardware-accelerated 3D graphics on web pages.

With the widespread use of OpenGL, OpenGL ES, and WebGL, we recognize the need for developers using these APIs to learn from each other and go well beyond the basics. To this end, we have created theOpenGL Insightsseries, with this first volume containing contributions from developers, vendors, researchers, and educators.

It is both a celebration of the breadth of the OpenGL family of APIs and a collection of deep, experienced-backed articles on practical and future-looking techniques.

Breadth is demonstrated through the diversity of topics—from using OpenGL in the classroom to recent extensions, optimizing for mobile devices, and designing WebGL libraries. Depth is realized by the deep corners into which many chapters take us, for example, asynchronous buffer and texture transfers, performance state tracking, and programmable vertex pulling.

(26)

It is our passion for these APIs and the passionate surrounding developer community that motivated us to start this series. In our day, there may be fewer fundamental problems to solve, but the breadth and complexity of the problems we solve is astonishing. It is an outstanding time to be an OpenGL developer.

—Patrick Cozzi February 2012 First of all, I would like to thank Patrick, who asked me to join him on this project. I still remember that night when, after seeing a great movie at the cinema,Somewhere, I received his email. There was really only one answer I could possibly give, but I certainly tried to fool myself that it could be otherwise: “Oh, let’s think this through.”

That hesitation lasted no longer than five seconds. The rest was just a lot of work and a lot of learning in the process.

Despite our differences in culture and background, Patrick and I were connected by a shared vision: we wanted to make a good book revealing, without preconception, the views of the entire OpenGL community, embracing everyone who shares our passion for the graphics variety that the OpenGL ecosystem can provide.

The OpenGL specifications are the foundation of OpenGL, but they are far from enough to understand its potential and limitations. With a dictionary and a grammar manual we can know a lot about a language, but it is still not enough for us to write poetry. I hopeOpenGL Insights will bring a little bit of the secret ingredient—experience—so that we can improve the everyday life of the OpenGL programmer and lead to the creation of more efficient development and graphics software.

If you enjoy this book and share the belief that it takes the contribution of everyone to build real-time graphics, don’t hesitate to contact us. We look forward to hearing from you and learning from your experiences in a future volume.

—Christophe Riccio February 2012

Acknowledgments. Significant effort is required to get a community-based book like this off the ground. We are grateful to have had a lot of help on everything from our book proposal to getting the word out to authors. For these tasks, we thank Quarup Barreirinhas (Google), Henrik Bennetsen (Katalabs), Eric Haines (Au- todesk), Jon Leech (Khronos Group), Barthold Lichtenbelt (NVIDIA), Jon McCaf- frey (NVIDIA), Tom Olson (ARM), Kevin Ring (AGI), Ken Russell (Google), and Giles Thomas (Resolver Systems).

This book benefited from an open culture of reviews. As editors, we reviewed chapters, but this was only the beginning. Fellow contributors took initiative to do

(27)

Preface xxv

peer reviews, and many external reviewers volunteered their time. For this, we thank Guillaume Chevelereau (Intersec), Mikkel Gjoel (Splash Damage), Dimitri Kudelski (Aix-Marseille University), Eric Haines (Autodesk), Andreas Heumann (NVIDIA), Randall Hopper (L-3 Communications), Steve Nash (NVIDIA), Deron Ohlarik (AGI), Emil Persson (Avalanche Studios), Aras Pranckeviˇcius (Unity Technologies), Swaroop Rayudu (Autodesk), Kevin Ring (AGI), Mathieu Roumillac (e-on software), Kenneth Russell (Google), Graham Sellers (AMD), Giles Thomas (Resolver Systems), and Marco Weber (Imagination Technologies).

The value of this book is made possible by the many authors that contributed to it. We thank every author for their contribution, peer reviews, and enthusiasm.

We also thank Alice Peters, Sarah Chow, and Kara Ebrahim for their hard work in publishing this book.

The time requirements for preparing this book were often intense. We owe a great deal of our success to the flexibility provided by our employers. At Analyti- cal Graphics, Inc., we thank Paul Graziani, Frank Linsalata, Jimmy Tucholski, and Shashank Narayan. At the University of Pennsylvania, we thank Norm Badler, Steve Lane, and Joe Kider.

Creating a book on top of our full-time jobs was not just hard on us, it was hard on our friends and families who saw less of us during nights, weekends, and even holidays. For their understanding and support, we thank Anthony Cozzi, Margie Cozzi, Peg Cozzi, and Jilda Stowe.

Website

The companion OpenGL Insights website contains source code and other supple- ments:

www.openglinsights.com

Please email us with your comments or corrections:

[email protected]

(28)

(29)

Tips

OpenGL glCreateShaderProgram may provide faster build performance than a sequence of glCompilerShader and glLinkProgram. However, it only creates a single shader stage program.

Not all shader objects need amain()function. Multiple shader objects can be linked together in the same program to allow sharing the same code between different programs.

Build all GLSL shaders and programs first, and then query the results to hide build and query latency.

CallglDeleteShaderafter attaching a shader to a program to simplify cleanup later.

OpenGL Five OpenGL 4.2 functions generate info logs:

• glCompileShader

• glCreateShaderProgram

• glLinkProgram

• glValidateProgram

• glValidateProgramPipeline

OpenGL

OpenGL ES Functions likeglGenTexturesdo not create an object, they re- turn a name for use with a new object. Objects are typically created withglBind*unless they are based on direct state access, in which case any other function may actually create the object.

(30)

glGenerateMipmapmay execute on the CPU, and therefore may be especially slow. Generate mipmaps offline or profile this function.

When using the default texture scanline alignment, GL PACK ALIGNMENT, of four bytes, with glTexImage2D or glTexSubImage2D, the end of each row of pixel data may need to be padded to the next multiple of the alignment.

OpenGL Texture rectangle, texture multisample, and buffer textures can’t have mipmaps.

OpenGL Integer textures,GL EXT texture integer, do not support fil- tering.

OpenGL A buffer texture is a 1D texture with a buffer object as storage which can only be fetched, not sampled.

Unmap buffers as soon as possible to allow the driver to start the transfer or to schedule the transfer.

Use buffer usage flags appropriately:COPY, GL to GL;DRAW, APP to GL;READ, GL to APP;STREAM, update always,DYNAMIC, update often,STATIC, update rarely.

Set a GLSL sampler uniform to the texture unit number, not the OpenGL texture ID.

glGetUniformLocationreturns−1 but doesn’t generate an er- ror if the uniform name does not correspond to an active uniform.

All declared uniforms are not active; uniforms that do not contribute to the shader’s output can be optimized out by the com- piler.

OpenGL An OpenGL context must always be current for the duration of OpenGL/compute interoperability.

OpenGL An OpenGL object should not be accessed by OpenGL while it is mapped for usage within the compute portion.

Avoid extraneousglBindFramebuffercalls. Use multiple at- tachments to a FBO rather than managing multiple FBOs.

(31)

Tips xxix

FBOs must always be validated before use to ensure that the se- lected format is renderable.

OpenGL Only one OpenGL query per query type, e.g., timer or occlusion, can be active at a time.

OpenGL For occlusion queries, usingGL ANY SAMPLES PASSEDmay be more effective thanGL SAMPLES PASSED, as a rendering doesn’t have to continue as soon as one fragment passed.

For image-space rendering on GPUs with a large clipping guard band clipping, e.g., GeForce, Radeon, and PowerVR series 6 use a large clipped triangle instead of a quad. Measure both if in doubt.

To test vertex throughput, do not render to a 1×1 viewport because parallelism is lost; instead, render outside of the view frus- tum.

glGetError is particularly slow, especially in multi-process WebGL architectures. Only use it in debug builds or instead use GL ARB debug outputwhen available.

OpenGL Geometry shaders are usually output bound so spending ALU time to reduce the amount of data output is a performance win.

WebGL In addition to #defining GL OES standard derivatives before usingdFdx, dFdy, andfwidth, also remember to call context.getExtension("OES standard derivatives") in JavaScript.

To accurately compute the length of a gradient, avoid fwidth(v); instead use sqrt(dFdx(v) * dFdx(v) + dFdy(v) * dFdy(v)).

WebGL

OpenGL ES highp is only available in fragment shaders if GL FRAGMENT PRECISION HIGH is #defined. Beware of the performance implications of using highp in vertex or fragment shaders.

(32)

OpenGL In OpenGL, precision qualifiers were reserved in GLSL 1.20 and OpenGL 2.1 but actually introduced with GLSL 1.30 and OpenGL 3.0. From GLSL 1.40 and OpenGL 3.1, and for the purpose of convergence with OpenGL ES 2.0, GL FRAGMENT PRECISION HIGHis defined as 1 in a fragment shader.

OpenGL By default, precision for vertex, tessellation, and geometry shader stages is highpfor int types, and mediumpfor the fragment shader stageinttypes. This may lead to warnings on some implementations.floatis alwayshighpby default.

WebGL Given a WebGL contextgl,gl.TRUEis undefined. When porting OpenGL or OpenGL ES code, do not change GL TRUEto gl.TRUEbecause it will silently evaluate to false.

Depth writes only occur ifGL DEPTH TESTis enabled.

The noise functions are still unimplemented in GLSL. Chapter 7 fixes this.

OpenGL gl VertexIDget values in[first, first+count-1]when generated from a DrawArray* command, and not in [0, count-1]. Especially useful when using a zero input attributes vertex shader.

OpenGL There are two ways to work with point size: glPointSize in the client-side code or gl PointSizein the GLSL code if PROGRAM POINT SIZEis enabled.

(33)

Tips xxxi

The GLSL core profile and GLSL ES are different subsets of keywords of the GLSL compatibility profile. The GLSL core profile allows us to write GLSL code with a fully programmable pipeline approach. GLSL ES takes advantage of the precision qualifiers, but GLSL doesn’t.

(34)

(35)

I Discovering

In this section, we discover many facets of OpenGL: teaching modern OpenGL in academia; using OpenGL on the web with WebGL; tessellation shaders in OpenGL 4.0; procedural textures; the safety critical variant, OpenGL SC; and multi-GPU OpenGL and CUDA interop.

OpenGL enjoys widespread use in computer graphics courses around the world.

Now-depreciated OpenGL features such as fixed-function lighting, immediate mode, and built-in transforms made the barrier to entry low. However, modern OpenGL has removed many of these features, resulting in a lean API that exposes the functionality of the underlying hardware. Academia has taken these changes in stride, updating their graphics courses to modern OpenGL. In Chapter 1, “Teaching Com- puter Graphics Starting With Shader-Based OpenGL,” Edward Angel discusses how an introductory computer graphics course can be taught using modern OpenGL.

In Chapter 2, “Transitioning Students to Post-Deprecation OpenGL,” Mike Bailey presents C++ abstractions and GLSL naming conventions to bridge the gap between depreciated and modern OpenGL for use in course assignments.

When we announced our call for authors forOpenGL Insightsin May 2011, we included WebGL as a desired topic. Since then, WebGL has gained such traction that an entire book could easily be justified. In Chapter 3, “WebGL for OpenGL Developers,” Patrick Cozzi and Scott Hunter present WebGL for those who already know OpenGL. In the following chapter, “Porting Mobile Apps to WebGL,” Ashraf Samy Hegab shows the benefits, differences, and trade-offs of using WebGL for mobile applications. Several chapters in later sections continue our WebGL exploration.

Christophe Riccio takes a rigorous look at communication between the OpenGL API and GLSL and different shader stages in Chapter 5, “The GLSL Shader Inter- faces.” He carefully examines using varying blocks; attribute, varying, and fragment

(36)

output variable locations; linked and separated programs; using semantics in our designs; and more.

Today, one of the differences between movie-quality rendering and real-time rendering is geometric complexity; movies generally have much higher geometric detail.

To improve geometric detail in real-time rendering, tessellation can be done in hardware. Although this has been available on ATI cards since the ATI Radeon 8500 in 2001, tessellation shaders were recently standardized and made part of OpenGL 4.0.

In Chapter 6, “An Introduction to Tessellation Shaders,” Philip Rideout and Dirk Van Gelder introduce the new fixed and programmable tessellation stages.

As the gap between compute power and memory bandwidth continues to widen, procedural techniques become increasingly important. Small size is speed. Procedu- ral textures not only have trivial memory requirements, but can also have excellent visual quality, allowing for analytic derivatives and anisotropic antialiasing. Stefan Gustavson introduces procedural textures, including antialiasing and using Perlin and Worley noise in Chapter 7, “Procedural Textures in GLSL.” Best of all, he provides GLSL noise functions for OpenGL, OpenGL ES, and WebGL.

OpenGL SC, for safety critical, may be one of the lesser-known OpenGL variants. In Chapter 8, “OpenGL SC Emulation Based on OpenGL and OpenGL ES,”

Hwanyong Lee and Nakhoon Baek explain the motivation for OpenGL SC and de- scribe the benefits of implementing it based on other OpenGL variants, instead of creating custom drivers or a software implementation.

In the past 15 years, consumer GPUs have transformed from dedicated fixed- function graphics processors to general-purpose massively-parallel processors. Tech- nologies like CUDA and OpenCL have emerged for developing general data-parallel algorithms on the GPU. There is, of course, a need for these general algorithms, like particle systems and physical simulation, to interop efficiently with OpenGL for rendering. In the final chapter of this section, “Mixing Graphics and Compute with Multiple GPUs,” Alina Alt reviews interoperability between CUDA and OpenGL and presents interoperability between multiple GPUs where one GPU is used for CUDA and another for OpenGL.

(37)

Teaching Computer Graphics Starting with Shader-Based OpenGL

Edward Angel

1.1 Introduction

For at least ten years, OpenGL has been used in the first computer graphics course taught to students in computer science and engineering, other branches of engineering, mathematics, and the sciences. Whether the course stresses basic graphics principles or takes a programming approach, OpenGL provides students with an API to support their learning. One of the many features of the OpenGL API that makes it popular for teaching is its stability and backward compatibility. Hence, instructors needed to make only minor changes in their courses as OpenGL evolved. At least that used to be true: over the last few years, OpenGL has changed rapidly and dramatically.

Starting with version 3.1, the fixed function pipeline was eliminated, an action that deprecated immediate mode and many of the familiar OpenGL functions and state variables. Every application must provide at least a vertex shader and a fragment shader. For those of us who use OpenGL to teach our graphics courses, these changes and the introduction of three additional shader stages in subsequent releases of OpenGL have led to a reexamination of how we can best teach computer graphics. As the authors of a popular textbook [Angel 09] used for the first course, we realized that this reexamination was both urgent and deep, requiring input from instructors at a variety of institutions. In the end, we wrote a new edition [Angel and Shreiner 12] that was entirely shader-based. Some of the key issues were addressed briefly in [Angel and Shreiner 11] but this chapter will not only discuss the reasons for the change but will also include practical observations and issues based on the actual teaching of a fully shader-based course.

1

(38)

I start with a historical overview, stressing how the software used in the first computer graphics course has changed over the years while the concepts we teach have remained largely unchanged. I review the key elements of a first course in computer graphics. Then I present a typical first Hello World program using the fixed-function pipeline. Next, the reader will see how we have to change that first program when moving to a shader-based course. Finally, I examine how each of the major topics in our standard course is affected by use of a shader-based OpenGL.

1.2 A Basic Course

Computer graphics has been taught in most colleges and universities since the 1970s.

A comparison between what was taught then and what is taught now leads to some interesting observations. The first textbook that took the modern approach to graphics was Newman and Sproull’s [Newman and Sproull 79]. Subsequently, Foley, van Dam, et al. [Foley et al. 96] became the standard. Not only do these two clas- sic works agree as to the key topics, but so do all the recent textbooks [Angel and Shreiner 12, Hearn et al. 11]. These topics include

• modeling,

• geometry,

• transformations,

• lighting and shading,

• texture mapping and pixel processing.

A major theme of this chapter is that using a shader-based OpenGL in the introductory course not only is possible but actually reinforces these key concepts. I will examine each area individually, but first one of the major worries confronting instructors needs to be addressed, namely, the perception that it is much harder to get started with a version of OpenGL that not only requires the application to provide its own shaders but also forces the programmer to use new constructs, such as vertex buffer objects, that were not required previously.

1.3 Hello World in OpenGL: Old Style

Let’s start with a simple example (shown in Listing 1.1) that we might teach in the first week of a typical class using pre-3.1 OpenGL: drawing a white rectangle on a black background using default values for most variables and, to delay any discussion of coordinate systems and transformations, giving vertex positions in clip coordi- nates.

(39)

1. Teaching Computer Graphics Starting with Shader-Based OpenGL 5

# i n c l u d e < GL / g l u t . h >

v o i d d i s p l a y (v o i d) {

g l C l e a r(G L _ C O L O R _ B U F F E R _ B I T) ; g l B e g i n(G L _ P O L Y G O N) ;

g l V e r t e x 2 f( -0.5 , -0.5) ; g l V e r t e x 2 f( -0.5 , 0 . 5 ) ; g l V e r t e x 2 f(0.5 , 0 . 5 ) ; g l V e r t e x 2 f(0.5 , -0.5) ; g l E n d() ;

g l u t S w a p B u f f e r s () ; }

i n t m a i n (i n t argc , c h a r ** a r g v ) {

g l u t I n i t (& argc , a r g v ) ;

g l u t I n i t D i s p l a y M o d e( G L U T _ R G B A | G L U T _ D O U B L E) ; g l u t C r e a t e W i n d o w(" H e l l o W o r l d ") ;

g l u t D i s p l a y F u n c( d i s p l a y ) ; g l u t M a i n L o o p () ;

}

Listing 1.1.Hello World. Figure 1.1.Hello World output.

As trivial as this program is, it possesses many of the features that instructors have built on.¹ For example, it is easy to add colors, normals, and texture coor- dinates between theglBeginandglEnd. Adding transformations and viewing is straightforward. Note that although we use GLUT in this example to interface with the window system and input devices and will use it in our other examples, its use is not crucial to the discussion. The output is shown in Figure 1.1.

There are three major issues with this code and all its extensions:

1. Use of immediate mode.

2. Reliance on the fixed-function pipeline.

3. Use of default values for state variables.

First, with a shader-based OpenGL, all the OpenGL functions in this example except glClear have been deprecated. Understanding why these functions have been deprecated is key to understanding why we have switched to a more recent OpenGL. The pipeline model (see a simplified version in Figure 1.2), that underlies OpenGL stresses immediate-mode graphics. As soon as each vertex is generated, it triggers an execution of the vertex shader. Because this geometry processing is carried out on the GPU by the vertex shader, this simple program requires four separate vertex positions to be sent to the GPU each time we want to display the rectangle.

1We could eliminate the double buffering to make the example even simpler. However, some systems would then require aglFlushinstead ofglutSwapBuffersto reliably display the output.

(40)

Vertex shader Vertices

Clipper and

primitive assembly Rasterizer Fragment shader

Pixels

Application Frame

Buffer Fragments

GPU State

CPU

Figure 1.2.Simplified pipeline.

Such a program masks the bottleneck between the CPU and GPU and hides the parallelism available on the GPU. Hence, although it is not the kind of program we want our students to write, the reasons are not apparent from the code.

Second, although it seems nice to be able to rely on the fact that our data will be processed in a known way, students tend to think the use of the immediate mode is the only way to display their geometric models. Later, when they process more complex geometry, they wonder why their applications run so slowly.

Third, this type of program leads to a somewhat outdated view of OpenGL as a state machine. Although state is important, the use of the fixed-function pipeline and default values hides a multitude of state variables within OpenGL that control how the geometry is rendered. As the simple program is expanded, students tend to get lost in the multitude of state variables and have great difficulty with unintended side effects of state variable changes. With recent versions of OpenGL, most state variables have been deprecated, and the application creates its own state variables.

1.4 Starting with Programmable Pipelines

Now, let’s review some of the issues with programmable pipelines starting with OpenGL 3.0. Although programmable pipelines have been in OpenGL since version 2.0, not only was their use optional, but an application programmer still had access to all the functions that are now deprecated. An application could have its own shaders and also use immediate mode. The shaders had access to most OpenGL state variables, which simplified writing applications with shaders. Hence, an instructor could start with our trivial application and introduce shaders later. However, in a first course that starts with immediate mode and the fixed-function pipeline, very few instructors actually get to programmable shaders. At best, shaders are given a short introduction at the end of the course.

OpenGL 3.0 announced that starting with OpenGL 3.1, backward compatibility would no longer be required of an implementation. OpenGL 3.1 has a core that is shader-based and a compatibility extension that supports the deprecated functions.

Later versions introduced core and compatibility profiles. Implementors could sup- ply either or both profiles. The option we took was to design a first course that

(41)

was totally shader based, consistent with the OpenGL 3.1 core.² To develop a first program, we had to examine what was absolutely required.

A shader-based program requires at least a vertex shader and a fragment shader.

Hence, the instructor must introduce a minimal amount of the OpenGL Shading Language (GLSL). Because GLSL is semantically close to C with a few C++-style enhancements, we can present the almost trivial shaders required for a Hello World program without going into an in-depth discussion of GLSL. The instructor must introduce some concepts such as program objects and, of course, what the shaders do.

Although these concepts take some time to present, they are core to understanding how modern graphics systems work, and introducing them early in the course should be viewed as a benefit of our approach.

The biggest problem in introducing shaders is that the application must read, compile, and link the shaders with the application. These operations require a set of OpenGL functions that contribute little to the student’s understanding of basic graphics concepts. Consequently, we decided to give the students a function, InitShaders, that reads in the shader files, compiles them, links them, and, if successful, returns a program object, as in the code fragment

G L u i n t p r o g r a m = I n i t S h a d e r s (" v e r t e x _ s h a d e r _ f i l e" , " f r a g m e n t _ s h a d e r _ f i l e ") ;

The source code was made available, and the individual functions used in it were discussed later or assigned as a reading exercise. As seemingly trivial as this decision appears, it was a departure from previous courses in which we never gave the students any code without a detailed presentation of its contents.

A second, perhaps more controversial, decision along these lines was to give the students a small C++ package with two-, three-, and four-dimensional matrix and vector classes. Although an OpenGL application can be written in C and use programmable shaders, GLSL relies on some additional matrix and vector types, uses C++-style constructors, and employs operator overloading. Consequently, if we’re going to teach a shader-based course, our students have to know a little bit of C++. In practice, this is not a problem as most students have already used an object-oriented programming language, and even for those who haven’t, the required parts of C++

are simple and take little time to introduce.

Although we could just use the C++ features required by GLSL in shader code only, there are two major advantages to having a C++ matrix/vector package that mirrors the types and operations in GLSL. One advantage is that the application code is a lot cleaner and clearer, eliminating mostforloops. The second is that many algorithms that are studied in a typical class, such as lighting, can be applied either in the application or in one of the shaders. By using application code with similar types and operations, such algorithms can be applied in any of the possible

2Most OpenGL 2.0 implementations support all the functionality needed for our course, either di- rectly or with a few OpenGL extensions. Hence, OpenGL 3.1 or any later version is not a requirement for using our approach.

(42)

ways with almost identical code. We have found this feature to be extremely helpful in teaching some of the more difficult parts of a course. These advantages override the potential objections that, once again, we are giving students code instead of having them write their own and also acknowledge that we really are using some C++ to teach the introductory course.

1.5 Hello World: New Style

Even the simplest application program can be divided into three parts: an initialization that sets up the shaders and the interface with the window system, a stage that forms the data and sends the data to the GPU, and a stage that renders the data on the GPU. In the shader-based approach, the first stage is no more difficult than with the traditional approach if we useInitShaders. For beginning examples, the third stage requires only a clearing of some buffers and a call to glDrawArrays. The middle stage is fundamentally different from immediate-mode programming. We have to introduce vertex buffer objects and perhaps vertex array objects for even the simplest program. Let’s examine all of these issues with a new Hello World program.

A program that produces the same output as our first Hello World program is shown in Listing 1.2. The corresponding vertex shader is in Listing 1.3, and the fragment shader is in Listing 1.4.

The include fileAngel.hbrings in theInitShaderscode and the matrix and vector classes. The next thing we notice about the program is that the data are for two triangles with shared vertices rather than for a single quadrilateral. Starting with OpenGL 3.1, triangles are the only filled type that is supported. This single initialization of an array, which uses ourvec2data type, leads to a good discussion of why we are restricted to triangles. We can also discuss the alternative of using either a triangle strip or a triangle fan.

Next comes the most difficult part to explain (although it’s only five lines of code). We allocate a vertex array object (VAO) and a vertex buffer object (VBO).

The three lines of code for setting up the vertex array data should follow from the discussion of VBOs. The basic idea that we are setting up storage is clear but why we need a VBO and a VAO in such a simple program is a tough one since we probably don’t want to spend a lot of time on that issue early in a course.³

The rest of the program is almost identical to the immediate-mode version with the exception of the use ofglDrawArrays, but that function presents no problems to students, and the display callback is almost trivial to explain.

Not much time is necessary to discuss the shaders; they don’t require much knowledge of GLSL. One nice aspect of the use of shaders is that even these simple shaders can be changed in interesting ways without going any deeper into GLSL.

3Alternately, some instructors may choose to leave out any discussion of VAOs by removing these two lines of code. The program will still run and at this point in the course, the potential efficiency of using a VAO is not of crucial importance.

(43)

# i n c l u d e " A n g e l . h "

v o i d i n i t ( v o i d ) {

v e c 2 p o i n t s [ 6 ] = {

v e c 2 ( -0.5 , -0.5 ) , v e c 2 ( 0.5 , -0.5 ) , v e c 2 ( 0.5 , 0 . 5 ) , v e c 2 ( 0.5 , 0 . 5 ) , v e c 2 ( -0.5 , 0 . 5 ) , v e c 2 ( -0.5 , -0.5 ) };

G L u i n t vao , b u f f e r ;

G L u i n t g l G e n V e r t e x A r r a y s(1 , & v a o ) ; g l B i n d V e r t e x A r r a y( v a o ) ;

G L u i n t g l G e n B u f f e r s(1 , & b u f f e r ) ; g l B i n d B u f f e r(G L _ A R R A Y _ B U F F E R, b u f f e r ) ;

g l B u f f e r D a t a(G L _ A R R A Y _ B U F F E R, s i z e o f( p o i n t s ) , p o i n t s , G L _ S T A T I C _ D R A W) ; G L u i n t p r o g r a m = I n i t S h a d e r(" v s i m p l e . g l s l ", " f s i m p l e . g l s l ") ;

g l U s e P r o g r a m( p r o g r a m ) ;

G L u i n t l o c = g l G e t A t t r i b L o c a t i o n( p r o g r a m , " v P o s i t i o n") ; g l E n a b l e V e r t e x A t t r i b A r r a y( l o c ) ;

g l V e r t e x A t t r i b P o i n t e r( loc , 2 , G L _ F L O A T, G L _ F A L S E, 0 , 0) ; g l C l e a r C o l o r(0.0 , 0.0 , 0.0 , 1 . 0 ) ;

}

v o i d d i s p l a y (v o i d) {

g l C l e a r(G L _ C O L O R _ B U F F E R _ B I T) ; g l D r a w A r r a y s(G L _ T R I A N G L E S, 0 , 6) ; g u t S w a p B u f f e r s () ;

}

i n t m a i n (i n t argc , c h a r ** a r g v ) {

g l u t I n i t (& argc , a r g v ) ;

g l u t I n i t D i s p l a y M o d e( G L U T _ R G B A | G L U T _ D O U B L E) ; g l u t C r e a t e W i n d o w(" H e l l o W o r l d ") ;

i n i t () ;

g l u t D i s p l a y F u n c( d i s p l a y ) ; g l u t M a i n L o o p () ;

}

Listing 1.2.Hello World redux.

in v e c 4 v P o s i t i o n;

v o i d m a i n () {

g l _ P o s i t i o n = v P o s i t i o n;

}

Listing 1.3.Hello World vertex shader.

o u t v e c 4 F r a g C o l o r;

v o i d m a i n () {

F r a g C o l o r = v e c 4(1.0 , 1.0 , 1.0 , 1 . 0 ) ; }

Listing 1.4.Hello World fragment shader.

(44)

1.5.1 OpenGL ES and WebGL

In my classes, students have always been free to choose to use Macs, PCs, or Linux computers. With OpenGL, that flexibility has never been a problem. The advent of OpenGL ES 2.0 and WebGL opens up even more possibilities. OpenGL ES 2.0 is totally shader-based and is supported on a variety of devices, including iPhones.

WebGL is a JavaScript implementation of OpenGL ES 2.0 that runs on the lat- est browsers. Last semester, students in our class used all five options. Although JavaScript is usually not part of the standard CS curriculum at most schools, it’s pretty easy for upper-class and graduate students to pick up the basics. The ability to share their work via a URL was an enormous benefit to students.

1.5.2 The First Assignment

Once we get past the Hello World example, students are ready for their first programming assignment. We like to give a three-dimensional project to start. Because one of the goals of the first assignment is to check whether students have the programming skills to handle later projects, it’s important to assign this type of project early. One possibility is to base the assignment on modeling and rendering a cube. Although without transformations, the axis-aligned cube will look like a square, students can change the vertex data, either to show more than one face of the cube or to create more interesting objects. Another possibility is an extension of some simple fractal to three dimensions. Other possibilities are morphing one simple object into another, twists, and two- or three-dimensional maze generation. You can also focus on shader code by starting with either a simple model or giving the class the data for a more complex model and having the students manipulate the model in the vertex shader.

At this point in a typical course, it is better to focus on an assignment using vertex shaders rather than fragment shaders since the major topics an instructor will likely be covering in class at that time are geometry and transformations.

1.6 The Rest of the Course

In most courses that have a programming component, instructors want to get their students programming as soon as possible so they can move on to the core topics.

Comparing our experience with the two Hello World examples, it takes about an extra week to get students to write their first assignment using the shader-based approach. This extra time comes back to the instructor because the details of using shader-based code that we needed to explain for the Hello World example would have been introduced later in a traditional course. Let’s look at each part of what we claim is core to all senior-level graphics courses and discuss how a shader-based OpenGL fits into each one.

(45)

1.6.1 Geometry

Computer graphics is built on some basic geometric concepts. Every introductory computer graphics class introduces the basic types (scalars, points, vectors), simple objects (triangles, planes, polylines), and methods of representation (coordinate systems, frames). Our approach has been to spend some time on building geometric models through vertex buffers. This section of most courses need not change with a shader-based OpenGL. Nevertheless, there are some interesting ways in which shaders can be used.

Consider modeling a cube. It’s a very useful object to have available as we develop transformations, viewing, lighting, and texture mapping. Because we can only render triangles, we have multiple ways we can build a model for the cube. Since we have already introduced vertex buffers for the Hello World program, an extension to using simple data structures andglDrawElementsis a nice topic. Color is usually added at this point in the course. Since the old built-in state variables, including the current color and the vertex position, are no longer part of the OpenGL state, these and other state variables must be defined in the application and their values sent to the GPU. Courses that are programming-oriented can use the flexibility of how data are organized and transferred to the GPU to experiment with various strategies, such as using uniform variables versus vertex attributes or various ways to mix geometric and color data in the application and on the GPU.

More generally, the issue of efficiency is often a neglected topic. With the standard immediate-mode approach, when students are asked to see how close their programs come to the advertised ratings of their graphics card, they are amazed and perplexed with how poorly their programs perform. With the flexibility of newer versions of OpenGL, students can try various strategies and achieve performances close to spec. In addition, if they use a compatibility profile, they can compare immediate-mode and retained-mode performance.

1.6.2 Transformations and Viewing

This part of the course is fairly standard and takes the most time. We introduce the standard affine transformations—translation, rotation, scaling, shear—and how to build them. We then move on to projective transformations and derive from them the standard orthographic and perspective transformations. Courses differ in how an instructor divides between theory and application. Before OpenGL 3.1, the API provided support through some simple matrix functions (glMatrixMode, glLoadMatrix, glLoadIdentity, glMultMatrix), the standard transformation functions (glTranslate, glRotate, glScale), matrix stacks (glPush Matrix,glPopMatrix), and the projection functions (glOrtho,glFrustum). All these functions have been deprecated. Moreover, because most state variables have been eliminated, the notion of a current matrix is gone, and thus the concept of a