alexm_notabenoid: переводы

→Click here to view code image
void glBufferSubData(GLenum target,
GLintptr offset,
GLsizeiptr size,
const GLvoid * data);

→After the code in Listing 5.1 has executed, buffer contains the name of a buffer object that has been
initialized to represent one megabyte of storage for whatever data we choose. Using the GL_ARRAY_BUFFER
target to refer to the buffer object suggests to OpenGL that we’re planning to use this buffer to store
vertex data, but we’ll still be able to take that buffer and bind it to some other target later. There are a
handful of ways to get data into the buffer object. You may have noticed the NULL pointer that we pass
as the third argument to glBufferData() in Listing 5.1. Had we instead supplied a pointer to some
data, that data would have been used to initialize the buffer object. Another way to get data into a
buffer is to give it to OpenGL and tell it to copy data there. To do this, we call glBufferSubData(),
passing the size of the data we want to put into the buffer, the offset in the buffer where we want it to
go, and a pointer to the data in memory that should be put into the buffer. glBufferSubData() is
declared as

→Click here to view code image
// The type used for names in OpenGL is GLuint
GLuint buffer;
// Generate a name for the buffer
glGenBuffers(1, &buffer);
// Now bind it to the context using the GL_ARRAY_BUFFER binding point
glBindBuffer(GL_ARRAY_BUFFER, buffer);
// Specify the amount of storage we want to use for the buffer
glBufferData(GL_ARRAY_BUFFER, 1024 * 1024, NULL, GL_STATIC_DRAW);
Listing 5.1: Generating, binding, and initializing a buffer

→Table 5.1. Buffer Object Usage Models
Listing 5.1 shows how a name for a buffer is reserved by calling glGenBuffers(), how it is
bound to the context using glBindBuffer(), and how storage for it is allocated by calling
glBufferData().

→The target parameter tells OpenGL which target the buffer you want to allocate storage for is bound
to. For example, the binding point that is used when you want to use a buffer to store data that
OpenGL can put into your vertex attributes is called the GL_ARRAY_BUFFER binding point. Although you
may hear the term vertex buffer or uniform buffer, unlike some graphics libraries, OpenGL doesn’t
really assign types to buffers — a buffer is just a buffer and can be used for any purpose at any time
(and even multiple purposes at the same time, if you like). The size parameter tells OpenGL how big
the buffer should be, and data is a pointer to some initial data for the buffer (it can be NULL if you don’t
have data to put in the buffer right away). Finally, usage tells OpenGL how you plan to use the buffer.
There are a number of possible values for usage, which are listed in Table 5.1.

→Click here to view code image
void glBufferData(GLenum target,
GLsizeiptr size,
const GLvoid * data,
GLenum usage);

→Allocating Memory using Buffers
The function that is used to allocate memory using a buffer object is glBufferData(), whose
prototype is

→Buffers
In OpenGL, buffers are linear allocations of memory that can be used for a number of purposes.
They are represented by names, which are essentially opaque handles that OpenGL uses to identify
them. Before you can start using buffers, you have to ask OpenGL to reserve some names for you and
then use them to allocate memory and put data into that memory. The memory allocated for a buffer
object is called its data store. Once you have the name of a buffer, you can attach it to the OpenGL
context by binding it to a buffer binding point. Binding points are sometimes referred to as targets,1
and the terms may be used interchangeably. There are a large number of buffer binding points in
OpenGL, and each has a different use. For example, you can use the contents of a buffer to
automatically supply the inputs of a vertex shader, to store the values of variables that will be used by
your shaders, or as a place for shaders to store the data they produce.
1. It’s not technically correct to conflate target and binding point as a single target may have multiple binding points. However,
for most use cases, it is well understood what is meant.

→In the examples you’ve seen so far, we have either used hard-coded data directly in our shaders, or we have passed values to shaders one at a time. While sufficient to demonstrate the configuration of the OpenGL pipeline, this is hardly representative of modern graphics programming. Recent graphics processors are designed as streaming processors that consume and produce huge amounts of data.
Passing a few values to OpenGL at a time is extremely inefficient. To allow data to be stored and accessed by OpenGL, we include two main forms of data storage — buffers and textures. In this chapter, we first introduce buffers, which are linear blocks of un-typed data and can be seen as generic memory allocations. Next, we introduce textures, which are normally used to store multidimensional data, such as images or other data types.

→Chapter 5. Data
What You’ll Learn in This Chapter
• How to create buffers and textures that you can use to store data that your program can access
• How to get OpenGL to supply the values of your vertex attributes automatically
• How to access textures from your shaders for both reading and writing

→Click here to view code image
void glPatchParameteri(GLenum pname,
GLint value);

→Tessellation
Tessellation is the process of breaking a high-order primitive (which is known as a patch in OpenGL) into many smaller, simpler primitives such as triangles for rendering. OpenGL includes a fixed-function, configurable tessellation engine that is able to break up quadrilaterals, triangles, and lines into a potentially large number of smaller points, lines, or triangles that can be directly consumed by the normal rasterization hardware further down the pipeline. Logically, the tessellation phase sits directly after the vertex shading stage in the OpenGL pipeline and is made up of three parts: the tessellation control shader, the fixed-function tessellation engine, and the tessellation evaluation shader.

Tessellation Control Shaders
The first of the three tessellation phases is the tessellation control shader (sometimes known as simply the control shader, or abbreviated to TCS). This shader takes its input from the vertex shader and is primarily responsible for two things: the first being the determination of the level of tessellation that will be sent to the tessellation engine, and the second being the generation of data that
will be sent to the tessellation evaluation shader that is run after tessellation has occurred.

Tessellation in OpenGL works by breaking down high-order surfaces known as patches into
points, lines, or triangles. Each patch is formed from a number of control points. The number of control points per patch is configurable and set by calling glPatchParameteri() with pname set to
GL_PATCH_VERTICES and value set to the number of control points that will be used to construct each patch. The prototype of glPatchParameteri() is

→Click here to view code image

#version 430 core

// Declare VS_OUT as an input interface block
in VS_OUT
{
vec4 color; // Send color to the next stage
} fs_in;

// Output to the framebuffer
out vec4 color;

void main(void)
{
// Simply assign the color we were given by the vertex shader
// to our output
color = fs_in.color;
}

Listing 3.6: Fragment shader with an input interface block

→Note that the interface block in Listing 3.5 has both a block name (VS_OUT, upper case) and an instance name (vs_out, lower case). Interface blocks are matched between stages using the block name (VS_OUT in this case), but are referenced in shaders using the instance name. Thus, modifying our fragment shader to use an interface block gives the code shown in Listing 3.6.

→Click here to view code image

#version 430 core

// "offset" is an input vertex attribute
layout (location = 0) in vec4 offset;
layout (location = 1) in vec4 color;

// Declare VS_OUT as an output interface block
out VS_OUT
{
vec4 color; // Send color to the next stage
} vs_out;

void main(void)
{
const vec4 vertices[3] = vec4[3](vec4( 0.25, -0.25, 0.5, 1.0),
vec4(-0.25, -0.25, 0.5, 1.0),
vec4( 0.25, 0.25, 0.5, 1.0));

// Add "offset" to our hard-coded vertex position
gl_Position = vertices[gl_VertexID] + offset;

// Output a fixed value for vs_color
vs_out.color = color;
}

Listing 3.5: Vertex shader with an output interface block

→Interface Blocks

Declaring interface variables one at a time is possibly the simplest way to communicate data between shader stages. However, in most non-trivial applications, you may wish to communicate a number of different pieces of data between stages, and these may include arrays, structures, and other complex arrangements of variables. To achieve this, we can group together a number of variables into a n interface block. The declaration of an interface block looks a lot like a structure declaration, except that it is declared using the in or out keyword depending on whether it is an input to or output from the shader. An example interface block definition is shown in Listing 3.5.

→Click here to view code image

#version 430 core

// Input from the vertex shader
in vec4 vs_color;

// Output to the framebuffer
out vec4 color;
void main(void)
{
// Simply assign the color we were given by the vertex shader
// to our output
color = vs_color;
}

Listing 3.4: Fragment shader with an input

→As you can see in Listing 3.3, we declare a second input to our vertex shader, color (this time at location 1), and write its value to the vs_output output. This is picked up by the fragment shader of Listing 3.4 and written to the framebuffer. This allows us to pass a color all the way from a vertex attribute that we can set with glVertexAttrib*() through the vertex shader, into the fragment shader and out to the framebuffer, meaning that we can draw different colored triangles!

→Click here to view code image

#version 430 core

// "offset" and "color" are input vertex attributes
layout (location = 0) in vec4 offset;
layout (location = 1) in vec4 color;

// "vs_color" is an output that will be sent to the next shader stage
out vec4 vs_color;
void main(void)
{
const vec4 vertices[3] = vec4[3](vec4( 0.25, -0.25, 0.5, 1.0),
vec4(-0.25, -0.25, 0.5, 1.0),
vec4( 0.25, 0.25, 0.5, 1.0));

// Add "offset" to our hard-coded vertex position
gl_Position = vertices[gl_VertexID] + offset;

// Output a fixed value for vs_color
vs_color = color;
}

Listing 3.3: Vertex shader with an output

→When we run the program with the rendering function of Listing 3.2, the triangle will move in a smooth oval shape around the window.

Passing Data from Stage to Stage

So far, you have seen how to pass data into a vertex shader by creating a vertex attribute using the in keyword, how to communicate with fixed-function blocks by reading and writing built-in variables such as gl_VertexID and gl_Position, and how to output data from the fragment shader using the out keyword. However, it’s also possible to send your own data from shader stage to shader stage using the same in and out keywords. Just as you used the out keyword in the fragment shader to create the output variable that it writes its color values to, you can create an output variable in the vertex shader by using the out keyword as well. Anything you write to output variables in one shader get sent to similarly named variables declared with the in keyword in the subsequent stage. For example, if your vertex shader declares a variable called vs_color using the out keyword, it would match up with a variable named vs_color declared with the in keyword in the fragment shader stage (assuming no other stages were active in between).

If we modify our simple vertex shader as shown in Listing 3.3 to include vs_color as an output variable, and correspondingly modify our simple fragment shader to include vs_color as an input variable as shown in Listing 3.4, we can pass a value from the vertex shader to the fragment shader. Then, rather than outputting a hard-coded value, the fragment can simply output the color passed to it from the vertex shader.