Real-Time Shader Programming

Ron Fosner

• Publisher: Morgan Kaufmann
• Year: 2003
• Print ISBN: 9781558608535
• eBook ISBN: 9780080515908
• Topic: Computer Science
• Subtopic: Computer Graphics
• Index: Computer Science

Now that PC users have entered the realm of programmable hardware, graphics programmers can create 3D images and animations comparable to those produced by RenderMan's procedural programs—-but in real time. Here is a book that will bring this cutting-edge technology to your computer.Beginning with the mathematical basics of vertex and pixel shaders, and building to detailed accounts of programmable shader operations, Real-Time Shader Programming provides the foundation and techniques necessary for replicating popular cinema-style 3D graphics as well as creating your own real-time procedural shaders.A compelling writing style, color illustrations throughout, and scores of online resources make Real-Time Shader Programming an indispensable tutorial/reference for the game developer, graphics programmer, game artist, or visualization programmer, to create countless real-time 3D effects. * Contains a complete reference of the low-level shader language for both DirectX 8 and DirectX 9* Provides an interactive shader demonstration tool (RenderMonkeyTM) for testing and experimenting* Maintains an updated version of the detailed shader reference section at www.directx.com* Teaches the latest shader programming techniques for high-performance real-time 3D graphics

CHAPTER 1

INTRODUCTION

GEORGE BERNARD SHAW

This is the true joy in life, being used for a purpose recognized by yourself as a mighty one. Being a force of nature instead of a feverish, selfish little clod of ailments and grievances complaining that the world will not devote itself to making you happy. I am of the opinion that my life belongs to the whole community and as I live it is my privilege—my privilege— to do for it whatever I can. I want to be thoroughly used up when I die, for the harder I work the more I love. I rejoice in life for its own sake. Life is no brief candle to me; it is a sort of splendid torch which I’ve got a hold of for the moment and I want to make it burn as brightly as possible before handing it on to future generations.

Shader: A custom shading and lighting procedure that allows the motivated artist or programmer to specify the rendering of a vertex or pixel.

“Shader” comes from Pixar’s RenderMan, which is a program that takes an entire description of a scene, from camera positions through object geometry, to a final rendering. RenderMan was introduced in 1989, but it wasn’t really until the 1995 release of the movie Toy Story that the general public was introduced to the power of RenderMan. About this same time, there was a revolution taking place on the graphics boards of PCs; the boards were evolving at a faster and faster clip, and the features that were showing up on “commodity” boards were rivaling those previously found only on workstations.

As Pixar continued to make hit after hit using RenderMan, soon other movie studios joined in. Meanwhile, the PC games community was finding new uses for the powerful graphics cards with which new PCs were now equipped. Light maps in particular were soon finding their way into games, followed by bump maps and procedural vertex generation. In fact, it was the games community that soon started clamoring for more features, and in order to differentiate themselves from the pack, some graphics card vendors heeded this call and soon started layering more and more features onto their cards. This had a snow-ball effect of creating a larger and larger installed base of fairly sophisticated PCs that had a good selection of graphics features.

The latter part of the century also saw the graphics API war—OpenGL (the “established” standard) vs. Direct3D (the “upstart” API from Microsoft). While two fractious camps sided off leaving many agnostics in the middle, it soon became clear that the committee-based architecture board that governs OpenGL’s evolution was too mired in the plodding workstation world, whereas the nimble and ferocious commodity PC graphics board industry was continually trying to outdo each other with every release, which was better suited to Direct3D’s sometimes annoying yearly release cycle.

With only a few graphics boards on the market, it was easy to program to OpenGL and ignore the many growing pains of Direct3D, but 1999 saw some accelerated graphics hardware dedicated only to games start to show up, and by 2001 that was the norm. By this time, the games development community had discovered the traditional graphics researchers (the “Siggraph crowd”) and vice-versa. The game developers discovered that many of the problems they faced had already been solved in the 1970s and 1980s as workstations were evolving and the graphics researchers liked the features that could be found on $100 video cards.

Thus we come into the era of the shading language. Both OpenGL and Direct3D use the “traditional” lighting equations, and these have served quite well for many years. But game programmers are continually striving to create the most gorgeous “eye candy” that they can (ignoring the actual game play for the moment). The traditional lighting equations are fine for common things, but if you are trying to create some stunning visual effects, Goraud-shaded objects are just not going to cut it. And here we turn full circle and return to Toy Story. For a number of years, it was bandied about in the graphics community that we were approaching Toy Story levels of real-time animation. Now Toy Story was emphatically not rendered in real time. Many months running on 117 Sun Sparc Stations grinding out over 130,000 frames of animation is what rendered Toy Story (plus 1300 unique shaders!). But both the computer’s CPU and the graphics card’s GPU (geometry processing unit) were getting continually more powerful. CPUs were becoming capable of offloading may of the things traditionally done by the CPU.

The first thing that GPUs took over from the CPU was some of the simple, repetitive math that the CPU used to have to do, the object transformation and lighting, or TnL [Fosner 2000]. This was a simple change, and in many cases, applications that used the graphics API for transformation and lighting saw a speedup with no code changes. On the other hand, there were many games—or games programmers who decided that they could do a better job than the API and did it themselves—and these games got no benefit from better hardware. But by this time, the writing was on the wall. No matter how good a programmer you were, your software implementation would never run as fast as the generic all-purpose hardware implementation.

However, there was one mantra that graphics hardware developers were continually hearing from graphics software developers, and that was they wanted a bigger choice in deciding how pixels got rendered. Of course, it still had to be hardware accelerated, but they wanted a chance to put their own interpretation on the rendered object. In fact, they wanted something like RenderMan shaders.

RENDERMAN VS. REAL TIME

RenderMan is a continually evolving product, but it’s never been one that could be considered real time. A good reason for this is the flexibility needed by the artists. In 1989, there was no hardware that could render a complex ray-traced scene in real time. You can think of ray tracing as tracing each pixel through a scene—through transparent and translucent objects—back to the location where the pixel is saturated. This works nicely for scenes that have lots of complex behavior, such as scenes with reflecting surfaces, water, shadows, glass, smoke, etc. And while that is the direction 3D consumer graphics is heading, we’re not quite there yet.

In the consumer 3D graphics arena, we’re dealing with objects that reflect light, and we can deal with objects that are some degree of transparent. But there’s no support for the effect of other objects in a scene. There’s support for the concept of “lights,” but a “light” in OpenGL or Direct3D is just a source of light, not an object itself. An object only “knows” about the lights in a scene, but not if it’s occluded from these lights by anything else in a scene.

WHAT YOU’LL LEARN FROM THIS BOOK

This book is intended for someone familiar with 3D graphics who wants a better understanding about just how some math can turn a bunch of data into a photorealistic scene. This book not only covers the basics of setting up and using vertex and pixel shaders, it also discusses in depth the very equations (and simplifications) that were used in the default graphics pipeline. You’ll learn what the basic equations are for lighting and shading, what the standards are, and most important, how to toss them out and program your own.

The emphasis is on giving you the knowledge to understand the equations that are used in lighting and shading, what the alternatives are, and how you can write your own. The equations are discussed in detail, and a shader editing tool from ATI called RenderMonkey is included. RenderMonkey is a powerful tool with an easy to use interface with which you can dynamically edit vertex and pixel shaders and their parameters in real time and see the changes upon a variety of objects. Not only will you understand the differences between the standard Blinn-Phong lighting equations and others like Torrance-Sparrow and Oren-Nayar, but you’ll learn how to make real-time shaders that implement these models. Anisotropic lighting, cartoon shading, Fresnel effects; it’s all covered in this book.

CHAPTER 2

PRELIMINARY MATH

GILBERT and SULLIVAN, THE PIRATES OF PENZANCE

I’m very well acquainted too with matters mathematical, I understand equations, both the simple and quadratical. About binomial theorem I’m teeming with a lot of news— With many cheerful facts about the square of the hypotenuse.

Well, there’s no getting around it. If you want to really understand shader programming and be able to program some wicked shaders, you have to have a firm understanding of the basic math required for 3D graphics and how it ties together. Understanding the math is a prerequisite for setting up shaders. If you’re a programmer, you really should have a good grasp on the mathematics involved in taking a vertex from a file and getting it rendered as pixels on the screen. If you’re an artist, you might be able to slide on some of the math, but to fully use a shading language requires knowing what data is coming through in a particular coordinate system and knowing how to change it as needed. Expertise lies in knowing how to shift data from one range to another, how to maintain as much precision as possible, and how to spoof the system to do what you want it to do.

If you’ve already programmed your own 3D rendering engine, have written a tri-stripping routine, know what a projection matrix is, and understand the usefulness of negative color values, then you can probably skip this section. However, if you feel that a quick and painless refresher on the basics of useful 3D math, terminology, and the mathematics of color would be useful, read on!

CONVENTIONS AND NOTATION

First, let’s agree to some notation since in latter parts of the book I’ll be getting into some pretty heavy notation. Generally, any single-valued quantity is written in a normal, unbolded font, whereas any multivalued quantity like a vector or a matrix is written in bold font. It gets a little confusing since one of the things a shader is generally trying to compute is color and, in current graphics hardware, that means a three- or four-element value representing the rgb or rgba values t...

Table of contents

• Cover image
• Title page
• Table of Contents
• Dedication
• Copyright
• The Morgan Kaufmann Series in Computer Graphics and Geometric Modeling
• CRITICAL ACCLAIM FOR: Real-Time Shader Programming!
• PREFACE
• Chapter 1: INTRODUCTION
• Chapter 2: PRELIMINARY MATH
• Chapter 3: MATHEMATICS OF LIGHTING AND SHADING
• Chapter 4: INTRODUCTION TO SHADERS
• Chapter 5: SHADER SETUP IN DIRECTX
• Chapter 6: SHADER TOOLS AND RESOURCES
• Chapter 7: SHADER BUFFET
• Chapter 8: SHADER REFERENCE
• Part I: Vertex Shader Reference
• Part II: Pixel Shader Reference
• REFERENCES
• INDEX
• ABOUT THE AUTHOR
• ABOUT THE CD-ROM