opengl superbible 5 edition chapter 11——Advanced Shader Usage

In this chapter, we cover some more advanced shader topics that will allow you to use your programmable graphics hardware for more than simple polygon rendering. We present a detailed example of using the GPU for physical simulation by recirculating data through transform feedback. We introduce an entirely new shader stage—the geometry shader, which can process entire primitives and even generate new primitives on the fly. We also discuss using the fragment shader to perform advanced per-pixel operations, including image processing and generating fractals. 分形

layout qualifiers are introduced, allowing u to control storage, interpolation, and other parameters affecting inputs and outputs of shaders. we also introduce a method of throwing work away in the fragment shader.

by the end of the chapter, the shaders u will be capable of writing will be so complex that u might get sick of 厌倦 using shader uniforms! we introuduce the uniform buffer object, which allows u to share large blocks of uniforms between different program objects.

advanced vertex shaders
until now, the vertex shader has been used to transform vertices from object space into world or view space. it has been viewed as a fairly simple one-in, one-out shader stage that simply does geometric transformations. however, the vertex shader is very powerful——on most modern hardware it has acess to all of the resources that the fragment shader does. it can be put to work on tasks that are not necessarily geometric in nature. combined with tranform feedback (which is discussed in detail in chapter 12, “advanced geometry management”), the vertex shader can circulate 循环 results around in a loop, iterating and updating them on each pass. the data does not need to be positions, and the results of the vertex shader do not necessarily need to be rendered directly. this section covers a few examples of some nonobvious usages for vertex shaders.

Physical Simulation in the Vertex Shader
In this example, we build a physical simulation of a mesh of springs and masses. Each vertex represents a weight, connected to up to four neighbors by elastic tethers. The example iterates over the vertices, processing each one with a vertex shader. A number of advanced features are used in this example. We use a texture buffer object (TBO) to hold vertex position data in addition to a regular attribute array. The same buffer is bound to both the TBO and the VBO associated with the position input to the vertex shader. This allows us to arbitrarily access the current position of other vertices in the system. We also use an integer vertex attribute to hold indices of neighboring vertices. Furthermore, we use transform feedback to store the positions and velocities of each of the masses between each iteration of the algorithm.

For each vertex, we need a position, velocity, and mass. We can pack the positions and masses into one vertex array and pack the velocities into another. Each element of the position array is actually a vec4, with x, y, and z being the three-dimensional coordinate of the vertex, and w containing the weight of the vertex. The velocity array can simply be an array of vec3. Additionally, we use an array of ivec4s to store information about the springs connecting the weights together. There is one ivec4 for each vertex, and each of the four components of the vector contains the index of the vertex that is connected to the other end of the spring. We call this the connection vector. This means that we can connect each mass to up to four other masses. To record that there is no connection, we point the element of the connection back at the same vertex (see Figure 11.1).

Consider vertex 12. It has associated with it an ivec4 connection vector containing <7, 13, 17, 11>—the indices of the vertices to which it is connected. Likewise, the connection vector for vertex 13 contains <8, 14, 18, 12>. There is a bidirectional connection between vertex 12 and 13. The vertices at the edges of the mesh don’t have all of their springs attached. So vertex 14 has a connection vector containing <9, 14, 19, 13>. Notice that the y component of the vector points back at vertex 14, indicating that there is no spring there.

In addition to the indices of the vertices to which it is connected (using a self reference to notate no connection), we define a special values to mean other things. The index -1 is used to mean that the vertex is held in position. No matter what the forces acting on it, its position won’t be updated. This allows us to fix the position of some of the vertices. If the x component of the connection vector is -1, then the calculations for updating the position and velocity of the vertex will be skipped.

at each vertex, our vertex shader runs and obtains its own position and connection vector using shader vertex attributes. it then looks up the current positions of the vertices it is connected to by indexing into the tbo using the elements of the connection vector (which is also a regular vertex attribute).For each connected vertex, it can calculate the distance to it and thus the extension of the virtual spring between them. From this, it can calculate the force exerted upon it by the spring, calculate the acceleration this produces given the mass of the vertex, and produce a new position and velocity to use in the next iteration. it sounds complex, but it is not——it is just Newtonian physics and hooke’s law.

Hooke’s law is
F = −kx