-This tutorial provides a basic introduction to OpenGL and 3D computer graphics in general. It shows how to make use of Qt and its OpenGL related classes to create 3D graphics by using OpenGL's programmable pipeline. The tutorial provides many examples that go through the basic features of OpenGL programming like rendering, texture mapping, lighting etc. By the end of the tutorial, you will have a good understanding about how OpenGL works and you will also be able to write custom shader programs.

- :download:`Qt Help <qtopengltutorial/OpenGLTutorial.qch>` for Qt Assistant and Qt Creator. In Qt Assistant, in the :qt:`Preferences Dialog <assistant-details.html#preferences-dialog>` under the `Documentation` tab (in a collapsible menu for Mac users), you click on the `Add` button in order to add this guide in .qch format. We do the same in Qt Creator under the `Options` dialog in the `Help` section. Here you can add this guide in the `Documentation` tab.

- We hope you liked this tutorial and that we have made you even more curious about OpenGL and 3D programming. If you want to delve deeper into OpenGL, you should definitively think about getting a good book dedicated to this topic. `The OpenGL homepage <http://www.opengl.org>`_ lists quite a few recommendations. If you are looking for an even higher level approach, you may consider taking a look at `Qt/3D <http://doc.qt.nokia.com/qt3d-snapshot>`_ and/or `QtQuick3D <http://doc.qt.nokia.com/qt-quick3d-snapshot>`_.

- Since OpenGL is able to compute a lot of information really fast, you may have thoughts about using it for more than just computer graphics. A framework based on this approach is called `OpenCL` (which is also managed by the Khronos Group Inc.). There even is a Qt Module for this framework. It is called `QtOpenCL <http://doc.qt.nokia.com/opencl-snapshot>`_.

-Links:

- `http://www.opengl.org` - The OpenGL homepage

- `http://www.khronos.org/opengl` - The Khronos Group Inc. homepage regarding OpenGL

- `http://www.khronos.org/opengles` - The Khronos Group Inc. homepage regarding OpenGL ES

- `http://doc.qt.nokia.com/qt3d?snapshot` - Qt/3D Reference Documentation

- `http://doc.qt.nokia.com/qt?quick3d?snapshot` - QtQuick3D Reference Documentation

- u'Nokia, Qt Learning', 'manual'),

-This tutorial provides a basic introduction to OpenGL and 3D computer graphics in general. It shows how to make use of Qt and its OpenGL related classes to create 3D graphics.

-Chapter one gives an introduction to 3D computer graphics and the OpenGL API including the OpenGL Shading Language (GLSL) / OpenGL ES Shading Language (GLSL / ES). If you are already familiar with this topic and only want to see how to use OpenGL in your Qt programs, you can skip this introductory chapter and continue on to chapter two.

-In chapter two, we present examples which utilize the information covered in chapter one and show how to use OpenGL together with Qt's OpenGL related functionality.

-At the end of this tutorial you find some references and links which may come in handy especially when working through the examples. Please note that this tutorial is meant to get you started with this topic and can not go into the same depth as a decent OpenGL dedicated book. Also note that Qt's OpenGL-related classes do a lot of work for you by hiding some of the details which you would encounter if you wrote your programs using only OpenGL's API.

-In the example part, we will use Qt's high level functionality whenever possible and only briefly name the differences. So if you intend to get a complete understanding of how to use native, you should additionally consult a tutorial or book dedicated to this topic.

-OpenGL is a low level API which requires the programmer to tell it the exact steps needed to

-up to you to specify geometry primitives in a 3D space, apply coloring and lighting effects

-variety of new graphics effects.

-functionality for window management or for handling events like user input. This is what

-objects, smooth objects like spheres will look jagged. Of course you could use more

-triangles will need to be processed by your graphics card. Instead of simply increasing the

-To define the spatial properties of your objects, you set up a list of points, lines and/or

-To see those objects, you need to apply coloring to your primitives. Color values are often

-color. For more realistic applications, images (called textures) are placed on top of them. The

-appearance can be further adapted according to material properties or lighting.

-Since the computer screen is a two dimensional device, we need to project our objects onto a

-plane. This plane is then mapped to a region on our screen called the viewport*. To

-Since it is essential to have a basic understanding of linear algebra when writing OpenGL programs, this chapter will briefly state the most important concepts involved. Although we will mostly have Qt do the math, it is still good to know, what is going on in the background.

-A matrix is basically a table of coefficients that, when multiplied by a vector, yields a new vector with each element that is a linear combination of the multiplied vector's elements.

-Imagine two coordinate systems: `A` and `B`. Coordinate system `B` originates from coordinate system `A` via a translation and a rotation that can be described by the matrix

-can be calculated.

- In the design phase, every object's model (i.e. its set of vertices) can be specified in relation to an arbitrary coordinate system (for example its center point)

- The transformation process is divided into small steps, which as such are quite illustrative

- All the used transformation matrices can be calculated, stored and combined efficiently

-The OpenGL rendering pipeline is a high level model which describes the basic steps that OpenGL takes to render a picture on the screen. As the word `pipeline` suggests, all operations are applied in a particular order. Very simply put, the rendering pipeline has a state, takes some inputs and returns an image to the screen.

-The state of the rendering pipeline affects the behavior of its functions. As it is not practical to set options every time we want to draw something, we can set parameters beforehand. These parameters are then used in all subsequent function calls. For example, once you've defined a background color, that color is used to clear the screen until you change it to something else. You can also turn distinct capabilities like depth testing or multisampling on and off. Therefore, to draw an overlay image on top of your screen, you would first draw the scene with depth testing enabled, then disable depth testing, and after that, draw the overlay elements, which will then always be rendered on top of the screen regardless of their distance from the viewer.

-The figure below shows a simplified version of the pipeline. The elements that are not relevant to this tutorial were omitted (such as tesselation, geometry shading and transform feedback).

-The main program that resides inside the computer's memory, and is executed by the CPU, is displayed in the left column. The steps executed on the graphics card are listed in the column on the right.

-The graphics card has its own memory and a GPU just like a small, but powerful computer that is highly specialized in processing 3D data. Programs that run on the GPU are called shaders. Both the host computer and the graphics card can work independently. To take full advantage of hardware acceleration, you should keep both of them busy at the same time.

-During `vertex specification`, the ordered list of vertices that gets streamed to the next step is set up. This data can either be sent by the program that is executed on the CPU one vertex after the other or read from GPU memory directly using buffer objects. However, repeatedly getting data via the system bus should be avoided whenever possible since it is faster for the graphics card to access its own memory.

-The `rasterisation` stage yields so called `fragments`. These fragments correspond to pixels on the screen. Depending on the user's choice, for each primitive, a set of fragments may be created. You may either fill the whole primitive with (usually colored) fragments, or only generate its outlines (e.g. to render a wireframe model).

-The final stage, `per-sample operations`, applies several tests to decide which fragments should actually be written to the framebuffer (depth test, masking etc). After this, blending occurs and the final image is stored in the framebuffer.

-This chapter will explain the conventions used in OpenGL. Although we will try to use Qt's abstraction to the OpenGL API whenever possible, we will still need to call some of its functions directly. The examples will introduce you to the required functions.

-.. list-table::

- :widths: 20 80

- :header-rows: 1

- :stub-columns: 0

-

- - Type

- - Description

- - *GLenum*

- - Indicates that one of OpenGL's preprocessor definitions is expected.

- - *GLboolean*

- - Used for boolean values.

- - *GLbitfield*

- - Used for bitfields.

- - *GLvoid*

- - sed to pass pointers.

- - *GLbyte*

- - 1-byte signed integer.

- - *GLshort*

- - GLshort 2-byte signed integer.

- - *GLint*

- - 4-byte signed integer.

- - *GLubyte*

- - 1-byte unsigned integer.

- - *GLushort*

- - 2-byte unsigned integer.

- - *GLuint*

- - 4-byte unsigned integer.

- - *GLsizei*

- - Used for sizes.

- - *GLfloat*

- - Single precision floating point number.

- - *GLclampf*

- - Single precision floating point number ranging from 0 to 1.

- - *GLdouble*

- - Double precision floating point number.

- - *GLclampd*

- - Double precision floating point number ranging from 0 to 1.

-

-OpenGL's various preprocessor definitions are prefixed with GL_*. Its functions begin with *gl*.

-

-A function that triggers the rendering process for example is declared as void glDrawArrays(GLenum mode, GLint first, GLsizei count)*.

-As we have already learned, programming shaders is one of the core requirements when using OpenGL. Shader programs are written in a high level language called `The OpenGL Shading Language (GLSL)`, which is a language very similar to C. To install a shader program, the shader source code has to be sent to the graphics card as a string, where the program then needs to be compiled and linked.

- - Type

- - Description

- - *void*

- - No `function return` value or `empty parameter` list.

- - *float*

- - Floating point value.

- - *int*

- - Signed integer.

- - *bool*

- - Boolean value.

- - *vec2, vec3, vec4*

- - Floating point vector.

- - *ivec2, ivec3, ivec4*

- - Signed integer vector.

- - *bvec2, bvec3, bvec4*

- - Boolean vector.

- - *mat2, mat3, mat4*

- - 2x2, 3x3, 4x4 floating point matrix.

- - *sampler2D*

- - Access a 2D texture.

-

- - *samplerCube*

- - Access cube mapped texture.

-To access the elements of a vector or a matrix, square brackets "[]" can be used (e.g. vector[index] = value* and *matrix[column][row] = value;*). In addition to this, the vector's named components are accessible by using the field selector operator "." (e.g. *vector.x = xValue* and *vector.xy = vec2(xValue, yValue)*). The names *(x, y, z, w)* are used for positions. *(r, g, b, a)* and *(s, t, p, q)* are used to address color values and texture coordinates respectively.

-.. list-table::

- :widths: 30 70

- :header-rows: 1

- :stub-columns: 0

-

- - Storage Qualifier

- - Description

- - *none*

- - (default) Normal variable

- - *const*

- - Compile-time constant

- - *attribute*

- - Linkage between a vertex shader and OpenGL for per-vertex data.Since the vertex shader is executed once for every vertex, this read-only value holds a new value every time it runs. It is used to pass vertices to the vertex shader for example.

- - *uniform*

- - Linkage between a shader and OpenGL for per-rendering data. This read-only value does not change across the the whole rendering process. It issued to pass the model-view-projection matrix for example since this parameter does not change for one object.

- - *varying*

- - Linkage between the vertex shader and the fragment shader for interpolated data. This variable is used to pass values calculated in the vertex shader to the fragment shader. For this to work, the variables need to share the same name the in both shaders. Since there are usually a lot of fragments in between a few vertices, the data calculated by the vertex shader is (by default) interpolated. Such variables are often used as texture coordinates or lighting calculations.

-

-To send data from the vertex shader to the fragment shader, the `out` variable of the vertex shader and the `in` variable of the fragment shader need to share the same name. Since there are usually a lot of fragments in between a few vertices, the data calculated by the vertex shader is by default interpolated in a perspective correct manner. To enforce this behavior, the additional qualifier smooth* can be written before *in*. To use linear interpolation, the *noperspective* qualifier can be set. Interpolation can be completely disabled by using *flat*. Then, for all the fragments in between a primitive, the value output by the first vertex of this primitive is used.

-.. list-table::

- :widths: 30 70

- :header-rows: 1

- :stub-columns: 0

- - Variable Name

- - Description

- - *vec4 gl_Position*

- - The rasterization step needs to know the position of the transformed vertex. Therefore, the vertex shader needs to set this variable to the calculated value.

- - *vec4 gl_FragColor*

- - This variable defines the fragment's RGBA color that will eventually be written to the frame buffer. This value can be set by the fragment shader.

-When using multiple variable qualifiers, the order is <storage qualifier> <precision qualifier> <type> <name>*.

-Just like in C, every GLSL program's entry point is the main()* function, but you are also allowed to declare your own functions. Functions in GLSL work quite differently than those in C. They do not have a return value. Instead, values are returned using a calling convention called `value-return`. For this purpose, GLSL uses parameter qualifiers, which need to be written before the variable type during function declaration. These qualifiers specify if and when values are exchanged between a function and its caller.

-.. list-table::

- :widths: 30 70

- :header-rows: 1

- :stub-columns: 0

- - Parameter qualifier

- - Description

- - in

- - (default) On entry, the variable is initialized to the value passed by the caller.

- - out

- - On return, the value of this variable is written into the variable passed by the caller. The variable is not initialized.

- - inout

- - A combination of in and out. The variable is both initialized and returned.

-There are actually many more qualifiers, but listing all of them goes beyond the scope of this tutorial.

- The language also offers control structures like if*, *switch*, *for*, *while*, and *do while*, including *break* and *return*. Additionally, in the fragment shader, you can call *discard* to exit the fragment shader and have that fragment ignored by the rest of the pipeline.

- GLSL also uses several preprocessor directives. The most notable one that you should use in all of your programs is #version* followed by the three digits of the language version you want to use (e.g. *#version 330* for version 3.3). By default, OpenGL assumes version 1.1, which might not always be what you want.

- Type casting is only possible using constructors (e.g. *myFloat = float(myInt);*).

-Qt provides a widget called `QGLWidget` for rendering OpenGL Graphics, which enables you to easily integrate OpenGL into your Qt application. It is subclassed and used like any other QWidget and is cross platform. You usually reimplement the following three virtual methods:

-

- `QGLWidget::initializeGL()` - sets up the OpenGL rendering context. It is called once before the first time `QGLWidget::resizeGL()` or `QGLWidget::paintGL()` are called.

-Qt also offers a cross platform abstraction for shader programs called `QGLShaderProgram`. This class facilitates the process of compiling and linking the shader programs as well as switching between different shaders.

-This example will confirm if we have set up our development environment properly and if OpenGL is running on our target system.

-

-We also need some member variables. `pMatrix` is a `QMatrix4x4` that keeps the projection part of the transformation pipeline. To manage the shaders, we will use a `QGLShaderProgram` we named `shaderProgram`. `vertices` is a `QVector` made of `QVector3Ds` that stores the triangle's vertices. Although the vertex shader will expect us to send homogeneous coordinates, we can use 3D vectors, because the OpenGL pipeline will automatically set the fourth coordinate to the default value of 1.

-

-This can be used to set the capabilities of the OpenGL rendering context such as double buffering or multisampling. We are fine with the default values so we could as well have omitted the `QLFormat`. Qt will try to acquire a rendering context as close as possible to what we want.

-

-If we want to render 3D images, we need to enable depth testing. This is one of the tests that can be performed during the per-sample-operations stage. It will cause OpenGL to only display the fragments nearest to the camera when primitives overlap. Although we do not need this capability since we only want to show a plane triangle, we will need this setting in our other examples. If you've omitted this statement, you might see objects in the back popping through objects in the front depending on the order the primitives are rendered.

-Shader programs need to be supplied as source codes. We can use `QGLShaderProgram::addShaderFromSourceFile()` to have Qt handle the compilation. This function compiles the source code as the specified shader type and adds it to the shader program. If an error occurs, the function returns `false`, and we can access the compilation errors and warnings using `QGLShaderProgram::log()`. Errors will be automatically printed to the standard error output if we run the program in debug mode.

-

-It needs to read two input variables. The first input is the model-view-projection matrix. It is a 4x4 matrix, that only changes once per object and is therefore declared as a `uniform mat4`. We've named it `mvpMatrix`. The second variable is the actual vertex that the shader is processing. As the shader reads a new value every time it is executed, the vertex variable needs to be declared as an `attribute vec4`. We've named this variable `vertex`.

-After we had checked the widget's height to prevent a division by zero, we set it to a matrix that does the perspective projection. Luckily we do not have to calculate it ourselves. We can use one of the many useful methods of `QMatrix4x4`, namely `QMatrix4x4::perspective()`, which does exactly what we need. This method multiplies its `QMatrix4x4` instance with a projection matrix that is specified by the angle of the field of view, its aspect ratio and the clipping regions of the near and far planes. The matrix we get using this function resembles the projection of a camera that is sitting in the origin of the world coordinate system looking towards the world's negative z direction with the world's x axis pointing to the right side and the y axis pointing upwards. The fact that this function alters its instance explains the need to first initialize it to an identity matrix (a matrix that, if it is applied as a transformation, does not change a vector at all).

-

-The rendering can now be triggered by calling the OpenGL function `glDrawArrays(GLenum mode, GLint first, GLsizei count)`. But before we can do that, we need to bind the shaders and hand over all the uniforms and attributes they need.

-In native OpenGL the programmer would first have to query the id (called `location`) of each input variable using the verbatim variable name as it is typed in the shader source code

-three components. The color of the triangle is set using a `QColor` instance that will

-we additionally need to explicitly enable the attribute array using

-QGLShaderProgram::enableAttributeArray(). If we did not do this, OpenGL would assume

-configuration. We pass `GL_TRIANGLES` as the first parameter to tell OpenGL that each of the three vertices form a triangle. The second parameter specifies the starting index within the attribute arrays and the third parameter is the number of indices to be rendered.

-You should now see a white triangle on black background after compiling and running this program.

-

-QWidget::mouseMoveEvent()`, and `QWidget::wheelEvent()`. The new member variables `alpha, beta` and `distance` hold the parameters of the view point, and `lastMousePosition` helps us track mouse movement.

-change and adapt the angles `alpha` and `beta`. Since the view point's parameters have

-changed, we then call `QGLWidget::updateGL()` to trigger an update of the rendering context.

-using the mouse. Since each of its six sides is painted in the same plane color, depth is not very visible. We will work on this in the next example.

-will allow us to specify a single color for each vertex and use the interpolation of varyings to generate the fragment's colors.

-This example will show you how to communicate data from the vertex shader over to the

-

-.. Note:: The source code related to this section is located in `examples/coloring/` directory

-Of course we still need to imploy a new structure to store the color values and send them to

-.. Note:: The source code related to this section is located in `examples/texture-mapping/` directory

-In order to map a texture to a primitive, we have to specify so-called texture coordinates* that tell OpenGL which image coordinate is to be pinned to which vertex. Texture coordinates are instances of `vec2` that are normalized to a range between 0 and 1. The origin of the texture coordinate system is in the lower left of an image, having the first axis pointing to the right side and the second axis pointing upwards (i.e. the lower left corner of an image is at `(0, 0)` and the upper right corner is at `(1, 1)`. Coordinate values higher than 1 are also allowed, causing the texture to wrap around by default.

-created using `glGenTextures(GLsizei n, GLuint texture)` and deleted again with a call to `glDelereTextures(GLsizei n, const GLuint *texture)`. To identify textures, each

-texture is assigned a texture ID during its creation. As with shader programs, they need to be bound to `glBindTexture(GLenum target, GLuint texture)` before they can be configured

-also takes care of that.

-this purpose, OpenGL uses so-called texture units*. So before we can use a texture, we need

-Because we also need to call `glBindTexture(GLenum target, GLuint texture)` if we want

-to add new textures or modify them, and binding a texture overwrites the the current active

-texture unit, you should set the active texture unit to an invalid unit after setting it by calling `glActiveTexture(0)`. This way several texture units can be configured at the same time. Note that texture units need to be used in an ascending order beginning with `GL_TEXTURE0`.

-We replace the `vec4` color attribute and the corresponding varying with a `vec2` variable for the texture coordinates and forward this value to the fragment shader.

-`QVector` made of `QVector2Ds` for the texture coordinates and add a member variable to

-First we include the `glext.h` header file to set the missing enums and a few typedefs which will help us keep the code readable (since the version shipped with your compiler might be outdated, you may need to get the latest version from `the OpenGL homepage <http://www.opengl.org>`_. Next we declare the function pointer, which we will use to call `glActiveTexture(GLenum texture)` using the included typedefs. To avoid confusing the linker, we use a different name than `glActiveTexture` and define a pre-processor macro which replaces calls to `glActiveTexture(GLenum texture)` with our own function:

-In this chapter, we will implement a technique called Phong shading*, which is a popular

-To show the results, we will display the cube with a light source circling above it. The light source will be marked by a pyramid which we will render using the per-vertex color shader of one of the previous examples. So in this example, you will also see how to render a scene with multiple objects and different shader programs.

-.. Note:: The source code related to this section is located in `examples/lighting/` directory

-highlights of glossy surfaces and an ambient term that sums up the small amounts of light

-For each kind of surface (whether glossy, flat etc), we define the following parameters: :math:`k_d` and :math:`k_s` set the ratio of reflection of the diffuse and specular component, :math:`k_a` sets the ratio of the reflection of the ambient term respectively and :math:`\alpha` is a shininess constant that controls the size of the specular highlights.

-:math:`\hat{L}_m` is the normalized direction vector pointing from the fragment to the light source, :math:`\hat{N}` is the surface normal of this fragment, :math:`\hat{R}_m` is the direction of the light reflected at this point and :math:`\hat{V}` points from the fragment towards the viewer of the scene.

-

-model matrix `mMatrix` set to an identity matrix. Then we calculate the model-view matrix,

-spotlight to the light sources position. Now we still want to rotate it since it looks nicer if it faces our cube. We therefore apply two rotation matrices on top. Because the pyramid that represents our lightspot is still to big to fit into our scene nicely, we scale it down to a tenth of its original size.

-After this we call `QGLBuffer::allocate()` to allocate the amount of memory we will need to store our vertices, normals, and texture coordinates. This function expects the number of bytes to reserve as a parameter. Using this method, we could also directly specify a pointer to the data which we want to be copied, but since we want to arrange several datasets one after the other, we do the copying in the next few lines. Allocating memory also makes us responsible for freeing this space when it's not needed anymore by using `QGLBuffer::destroy()`. Qt will do this for us if the `QGLBuffer` object is destroyed.

-Just in case you're interested, this is how the creation of buffer objects would work if we did not use Qt's `QGLBuffer` class for this purpose: We would call `void glGenBuffers(GLsizei n, GLuint buffers)` to request `n` numbers of buffer objects with their ids stored in `buffers`. Next we would bind the buffer using `void glBindBuffer(enum target, uint bufferName)`, where we would also specify the buffer's type. Then we would use `void glBufferData(enum target, sizeiptr size, const void *data, enum usage)` to upload the data. The enum called `usage` specifies the way the buffer is used by the main program running on the CPU (e.g. write-only, read-only, copy-only) as well as the frequency of the buffer's usage, in order to support optimizations. `void glDeleteBuffers(GLsizei n, const GLuint *buffers)` is the OpenGL API function to delete buffers and free their memory.