OpenGL编程指南：基于Shader的高级教程 - CSDN文库

计算机图形学

需积分: 47 150 浏览量更新于2024-07-18 1 收藏 42.72MB PDF 举报

"这是一份高级的OpenGL编程教程，旨在帮助读者快速上手基于shader的OpenGL编程。教程由Joey de Vries创作，并在LearnOpenGL网站上发布，遵循 Creative Commons Attribution-NonCommercial 3.0 Unported License。教程涵盖了从入门到高级的多个主题，包括OpenGL的核心模式与立即模式、扩展、状态机、对象创建以及窗口创建等基础知识。" 本文档是LearnOpenGL网站的离线版，作者Joey de Vries在2017年发布了第三版。教程首先介绍了离线版的基本信息和前提条件，强调了读者需要具备一定的基础知识，如基本的编程技能和对计算机图形学的理解。文档的结构清晰，包含各种提示和代码示例，便于读者理解和实践。在"Getting started"章节，教程探讨了OpenGL的两个主要版本：核心模式和立即模式。核心模式是现代OpenGL的发展方向，强调向后兼容性和可预测性，而立即模式则更注重简单易用。同时，教程提到了OpenGL的扩展，这些扩展允许开发者利用硬件特性，但使用时需要注意兼容性问题。OpenGL的状态机模型意味着许多设置一旦生效就会持续到下次改变，这在处理图形渲染时需要谨慎管理。此外，教程还引入了对象的概念，如缓冲区、着色器程序等，这些都是现代OpenGL编程的核心元素。 "Creating a window"章节则转向实际应用，介绍了如何使用GLFW库创建一个用于显示OpenGL图形的窗口。GLFW是一个跨平台的库，使得开发者能够在Windows、Linux和macOS等操作系统上轻松创建OpenGL上下文并处理用户输入。在后续章节中，教程会深入到更多OpenGL的技术细节，如顶点数据、着色器语言（GLSL）、纹理映射、深度测试、视口变换、光照模型等。此外，还会涉及高级话题如混合、多重采样抗锯齿、帧缓冲对象（FBO）以及后期处理效果等。每个主题都提供了丰富的代码示例，帮助读者通过实践掌握OpenGL编程。这份教程适合有一定编程基础并希望深入理解现代OpenGL的读者。通过学习，读者将能够熟练地使用shader进行图形渲染，并创建复杂的交互式图形应用程序。

1.3 Structure 16

blocks, color hints and function references.

1.3.1 Boxes

Green

boxes encompasses some notes or useful features/hints about OpenGL or the subject at

hand.

Red boxes will contain warnings or other features you have to be extra careful with.

1.3.2 Code

You will ﬁnd plenty of small pieces of code in the website that are located in dark-gray boxes with syntax-

highlighted code as you can see below:

// This box contains code

Since these provide only snippets of code, wherever necessary I will provide a link to the entire source

code required for a given subject.

1.3.3 Color hints

Some words are displayed with a different color to make it extra clear these words portray a special meaning:

•

Deﬁnition: green words specify a deﬁnition i.e. an important aspect/name of something you’re likely

to hear more often.

• Program logic: red words specify function names or class names.

• Variables: blue words specify variables including all OpenGL constants.

1.3.4 OpenGL Function references

A particularly well appreciated feature of LearnOpenGL is the ability to review most of OpenGL’s functions

wherever they show up in the content. Whenever a function is found in the content that is documented at

the website, the function will show up with a slightly noticeable underline. You can hover the mouse over

the function and after a small interval, a pop-up window will show relevant information about this function

including a nice overview of what the function actually does. Hover your mouse over

glEnable

to see it

in action.

Now that you got a bit of a feel of the structure of the site, hop over to the Getting Started section to start

your journey in OpenGL!

2. OpenGL

Before starting our journey we should ﬁrst deﬁne what OpenGL actually is. OpenGL is mainly considered

an API (an Application Programming Interface) that provides us with a large set of functions that we can use

to manipulate graphics and images. However, OpenGL by itself is not an API, but merely a speciﬁcation,

developed and maintained by the Khronos Group.

The OpenGL speciﬁcation speciﬁes exactly what the result/output of each function should be and how it

should perform. It is then up to the developers implementing this speciﬁcation to come up with a solution of

how this function should operate. Since the OpenGL speciﬁcation does not give us implementation details,

the actual developed versions of OpenGL are allowed to have different implementations, as long as their

results comply with the speciﬁcation (and are thus the same to the user).

The people developing the actual OpenGL libraries are usually the graphics card manufacturers. Each

graphics card that you buy supports speciﬁc versions of OpenGL which are the versions of OpenGL

developed speciﬁcally for that card (series). When using an Apple system the OpenGL library is maintained

by Apple themselves and under Linux there exists a combination of graphic suppliers’ versions and hobbyists’

adaptations of these libraries. This also means that whenever OpenGL is showing weird behavior that it

shouldn’t, this is most likely the fault of the graphics cards manufacturers (or whoever developed/maintained

the library).

Since most implementations are built by graphics card manufacturers. Whenever there is a bug

in the implementation this is usually solved by updating your video card drivers; those drivers

include the newest versions of OpenGL that your card supports. This is one of the reasons why

it’s always advised to occasionally update your graphic drivers.

Khronos publicly hosts all speciﬁcation documents for all the OpenGL versions. The interested reader

can ﬁnd the OpenGL speciﬁcation of version 3.3 (which is what we’ll be using) here which is a good

read if you want to delve into the details of OpenGL (note how they mostly just describe results and not

implementations). The speciﬁcations also provide a great reference for ﬁnding the

exact

workings of its

functions.

2.1 Core-proﬁle vs Immediate mode 19

2.1 Core-proﬁle vs Immediate mode

In the old days, using OpenGL meant developing in immediate mode (often referred to as the ﬁxed function

pipeline) which was an easy-to-use method for drawing graphics. Most of the functionality of OpenGL

was hidden in the library and developers did not have much freedom at how OpenGL does its calculations.

Developers eventually got hungry for more ﬂexibility and over time the speciﬁcations became more ﬂexible;

developers gained more control over their graphics. The immediate mode is really easy to use and understand,

but it is also extremely inefﬁcient. For that reason the speciﬁcation started to deprecate immediate mode

functionality from version 3.2 and started motivating developers to develop in OpenGL’s core-proﬁle mode

which is a division of OpenGL’s speciﬁcation that removed all old deprecated functionality.

When using OpenGL’s core-proﬁle, OpenGL forces us to use modern practices. Whenever we try to

use one of OpenGL’s deprecated functions, OpenGL raises an error and stops drawing. The advantage of

learning the modern approach is that it is very ﬂexible and efﬁcient, but unfortunately is also more difﬁcult to

learn. The immediate mode abstracted quite a lot from the

actual

operations OpenGL performed and while

it was easy to learn, it was hard to grasp how OpenGL actually operates. The modern approach requires the

developer to truly understand OpenGL and graphics programming and while it is a bit difﬁcult, it allows

for much more ﬂexibility, more efﬁciency and most importantly a much better understanding of graphics

programming.

This is also the reason why our tutorials are geared at Core-Proﬁle OpenGL version 3.3. Although it is

more difﬁcult, it is greatly worth the effort.

As of today, much higher versions of OpenGL are published (at the time of writing 4.5) at which you

might ask: why do I want to learn OpenGL 3.3 when OpenGL 4.5 is out? The answer to that question

is relatively simple. All future versions of OpenGL starting from 3.3 basically add extra useful features

to OpenGL without changing OpenGL’s core mechanics; the newer versions just introduce slightly more

efﬁcient or more useful ways to accomplish the same tasks. The result is that all concepts and techniques

remain the same over the modern OpenGL versions so it is perfectly valid to learn OpenGL 3.3. Whenever

you’re ready and/or more experienced you can easily use speciﬁc functionality from more recent OpenGL

versions.

When using functionality from the most recent version of OpenGL, only the most modern

graphics cards will be able to run your application. This is often why most developers generally

target lower versions of OpenGL and optionally enable higher version functionality.

In some tutorials you’ll sometimes ﬁnd more modern features which are noted down as such.

2.2 Extensions

A great feature of OpenGL is its support of extensions. Whenever a graphics company comes up with a

new technique or a new large optimization for rendering this is often found in an extension implemented

in the drivers. If the hardware an application runs on supports such an extension the developer can use

the functionality provided by the extension for more advanced or efﬁcient graphics. This way, a graphics

developer can still use these new rendering techniques without having to wait for OpenGL to include the

functionality in its future versions, simply by checking if the extension is supported by the graphics card.

Often, when an extension is popular or very useful it eventually becomes part of future OpenGL versions.

The developer then has to query whether any of these extensions are available (or use an OpenGL

extension library). This allows the developer to do things better or more efﬁcient, based on whether an

extension is available:

if(GL_ARB_extension_name)

{

// Do cool new and modern stuff supported by hardware

}

else

{

// Extension not supported: do it the old way

2.3 State machine 20

}

With OpenGL version 3.3 we rarely need an extension for most techniques, but wherever it is necessary

proper instructions are provided.

2.3 State machine

OpenGL is by itself a large state machine: a collection of variables that deﬁne how OpenGL should currently

operate. The state of OpenGL is commonly referred to as the OpenGL context. When using OpenGL, we

often change its state by setting some options, manipulating some buffers and then render using the current

context.

Whenever we tell OpenGL that we now want to draw lines instead of triangles for example, we change

the state of OpenGL by changing some context variable that sets how OpenGL should draw. As soon as we

changed the state by telling OpenGL it should draw lines, the next drawing commands will now draw lines

instead of triangles.

When working in OpenGL we will come across several state-changing functions that change the context

and several state-using functions that perform some operations based on the current state of OpenGL. As

long as you keep in mind that OpenGL is basically one large state machine, most of its functionality will

make more sense.

2.4 Objects

The OpenGL libraries are written in C and allows for many derivations in other languages, but in its core it

remains a C-library. Since many of C’s language-constructs do not translate that well to other higher-level

languages, OpenGL was developed with several abstractions in mind. One of those abstractions are objects

in OpenGL.

An object in OpenGL is a collection of options that represents a subset of OpenGL’s state. For example,

we could have an object that represents the settings of the drawing window; we could then set its size, how

many colors it supports and so on. One could visualize an object as a C-like struct:

struct object_name {

float option1;

int option2;

char[] name;

};

Whenever we want to use objects it generally looks something like this (with OpenGL’s context visualized

as a large struct):

// The State of OpenGL

struct OpenGL_Context {

...

object

*

object_Window_Target;

...

};

// create object

unsigned int objectId = 0;

glGenObject(1, &objectId);

// bind object to context

glBindObject(GL_WINDOW_TARGET, objectId);

// set options of object currently bound to GL_WINDOW_TARGET

glSetObjectOption(GL_WINDOW_TARGET, GL_OPTION_WINDOW_WIDTH, 800);

glSetObjectOption(GL_WINDOW_TARGET, GL_OPTION_WINDOW_HEIGHT, 600);

// set context target back to default

glBindObject(GL_WINDOW_TARGET, 0);

This little piece of code is a workﬂow you’ll frequently see when working in OpenGL. We ﬁrst create an

object and store a reference to it as an id (the real object data is stored behind the scenes). Then we bind

the object to the target location of the context (the location of the example window object target is deﬁned

剩余513页未读，继续阅读

weixin_37056500

粉丝: 1
资源: 4

最新资源