后来的 OpenGL 规范 - 不仅仅是着色器?
我几乎完全按照 2 规范进行 OpenGL 编程,对 3 和 4 规范了解不多。 我在一些论坛上读到,后来的 OpenGL 规范基本上只是将数据提供给着色器,由着色器完成所有实际工作。 这与我所理解的 OpenGL 形成鲜明对比,着色器是照明、水和其他效果等辅助工具 我充其量对着色器有一个非常基本的了解,如果在前面提到的任何主题中被证明是错误的,我不会感到惊讶。我只是想更好地理解
谢谢
I've been programming OpenGL almost entirely in the 2 specification, and don't know much about the 3 and 4 specs.
I read on some forum that the later specs of OpenGL are basically just feeding data to shaders, that do all the real work.
That would be in sharp contrast to what I understand to be OpenGL, and shaders as an auxiliary tool for things like lighting, water and other effects
I have, at best, a very basic understanding of shaders and would not be surprised to be proved wrong in any of the previously mentioned topics. I'm just curious for a greater understanding
Thanks
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
你的理解是正确的。在 OpenGL 3.0 中,几乎所有固定功能都被弃用,取而代之的是着色器。即使是可从着色器访问的内置内容也已被弃用,例如模型视图/投影矩阵、顶点坐标、法线、灯光等。
基本工作流程应该如下:
glDrawElements
或glDrawArrays
所以您将进行的大多数 OpenGL 调用都只是推送通用数据。您将调用诸如
glUniform4f
之类的通用函数,而不是诸如glLightfv
之类的状态函数。Your understanding is correct. In OpenGL 3.0, nearly all of the fixed functionality is deprecated in favor of shaders. Even the built in stuff accessible from shaders is deprecated, such as modelview / projection matrices, vertex coordinates, normals, lights, etc.
The basic workflow is supposed to be as follows:
glDrawElements
orglDrawArrays
So most of the OpenGL calls you'll be making are just pushing generic data around. Instead of state functions like
glLightfv
, you'll be calling generic functions likeglUniform4f
.如果您已经在使用着色器,则无需进行太多更改。您遇到缺少的内容,在渲染代码中添加矩阵乘法并向着色器添加两行(或更可能是半行),然后生活继续。
如果您像我一样愚蠢地尝试使用 OpenGL 来做一些富有成效的事情(即以高帧速率渲染科学数据,而不是玩游戏),那么您就会受到一点伤害。您将需要编写(我的意思是剪切+粘贴示例)几十行着色器代码来替换固定功能管道,以及近一百行设置代码来编译、链接和激活这些代码着色器(以及调试输出,您第一次尝试时不会得到正确的结果)。
无论哪种情况,仍然没有任何作用。然后你发现你需要绑定一个VAO。您实际上不需要用它做任何事情(除非您想使用多个 VAO 进行状态管理),您只需要一个,因为没有它,其他属性/VBO 都无法工作。
不过,完成后,您可以开始考虑使用着色器或 OpenCL 集成 GPGPU 计算,并将数据移交给渲染,所有这些都在图形内存内。
If you were already using shaders, not much changes. You run into something that's missing, add a matrix multiply in your render code and two lines to your shader (or more likely, half a line) and life goes on.
If, like me, you were foolish enough to try to use OpenGL for something productive (i.e. rendering scientific data at high frame rates, not gaming), you're in for a little bit of hurt. You're going to need to write (by which I mean cut+paste an example) a couple dozen lines of shader code to replace the fixed-function pipeline, and nearer a hundred lines of setup code to compile, link, and activate those shaders (along with debug output, you won't get it right on the first try).
In either case, still nothing will work. Then you find out you need to bind a VAO. You don't actually need to do anything with it (unless you want to use multiple VAOs for state management), you just need one because none of the other attribute/VBO stuff works without it.
When you're done, though, you can start thinking about integrating GPGPU computation using shaders or OpenCL and hand off the data for rendering, all inside the graphics memory.
我认为这个想法是几何学很简单。我们已经把几何学打败了。引擎的存在可以很好地处理几何形状。
现在,真正的挑战是我们如何使几何图形看起来更真实?这种工作(最好)是用着色器完成的,所以这就是该行业的焦点所在。
I think the idea is that geometry is easy. We have beat geometry to death. Engines exist to handle the geometry just fine.
Now, the real challenges are how do we make that geometry look more realistic? That kind of work is (best) done with shaders, so that's where the focus of the profession is headed.
当前的 OpenGL 规范仍然执行大部分与以前相同的几何图形。他们不再做的是(自动)处理在着色器中相当容易完成的事情。例如,它们不再自动在顶点颜色之间进行插值来获取每个像素的颜色。插值硬件仍然存在,因此着色器很简单,但仍然是必要的。
The current OpenGL specs still do most of the same geometry as ever. What they no longer do is (automatically) handle the kinds of things that are reasonably easy to do in shaders. Just for example, they no longer automatically interpolate between vertex colors to get the color for every pixel. The interpolation hardware is still there, so the shader is trivial, but still necessary.