了解OpenGL

发布于 2024-12-13 01:05:21 字数 1061 浏览 0 评论 0原文

我有一些关于 OpenGL 的基本观点/问题,并非全部涉及代码,还涉及概念。如果您能回答、肯定或扩展其中任何一个问题,我将不胜感激。我警告你,有些人可能很天真,所以请耐心等待。

  1. 据我了解,OpenGL 只是一个标准,而不是一个软件。例如,“获取”OpenGL 实际上涉及获取第三方实现,而该实现不一定需要得到 Khronos 的认可。

  2. OpenGL通常指GL实用程序(GLU)和GL实用程序工具包(GLUT)的组合。他们有分别以 gluglut 开头的方法。而“基本”OpenGL 方法(以 gl 开头)是由那些制作图形驱动程序的人实现的,即 NVIDIA?

  3. 我假设 glut 方法是特定于操作系统的帮助程序,例如 glutKeyboardFunc() 必须是,才能解释键盘。因此,如果我想要一种更强大的替代方法来解释键盘输入,我只会使用操作系统 API。 OpenGL 本身纯粹是关于图形的,但是 glut 有这种东西,因为如果没有实时的人类控制,图形就不多了。

  4. 在我看来,glu 方法可能与调用一系列较低级别的 gl 方法相同。我想引用的一个例子是 glOrtho()gluPerspective()。在我看来,它们的工作方式相似,但计算透视可能更复杂,因此 gluPerspective() 是为了方便,但可能只是解析为一些 gl 方法。

  5. 我在大学时使用 freeglut 学习了基本的 OpenGL,并且我一直对使用 OpenGL 的“硬核”方式抱有这样的愿景,即仅使用低级方法。我不知道这是否是一个完全天真的想法,但是是否有一种“专业”的方式来编写 OpenGL,以发挥其最大功能?比如说,游戏开发者大概不会使用 glutPostRedisplay() ,对吧?这看起来太简单太方便了,好像它隐藏了很多正在发生的事情。我怀疑这对于 C++ 来说也是如此,因为 GLUT 回调对命名空间中的方法不友好(正如我在其他问题中看到的那样)

I have some fundamental points/questions about OpenGL, not all involving code but concepts as well. I would be grateful if you could answer, affirm or expand on any of them. I warn you, some might be naive, so please bear with me.

  1. I understand that OpenGL is just a standard, as opposed to a piece of software. For example, 'getting' OpenGL actually involves getting a third-party implementation which doesn't necessarily have to be endorsed by Khronos.

  2. OpenGL usually refers to the combination of the GL utilities (GLU) and the GL utilities toolkit (GLUT). They have methods beginning with glu and glut, resp. and the 'basic' OpenGL methods, that begin with simply gl, are implemented by those that make graphics drivers, i.e. NVIDIA?

  3. I assume that glut methods are OS-specific helpers, for example glutKeyboardFunc() has to be, to interpret the keyboard. So if I wanted a more powerful alternative way to interpret keyboard input, I would just use the OS API. OpenGL itself is purely about graphics, but glut has this sort of thing since graphics is not much without real-time human control.

  4. It seems to me that glu methods may be identical to calling a series of lower-level gl methods. One example I would like to quote is glOrtho() and gluPerspective(). They seem to me to have similar ways of working, but calculating perspective may be more complex, so gluPerspective() is for convenience, but might just resolve to some gl methods.

  5. I have studied basic OpenGL using freeglut at university, and I keep having this vision of a 'hardcore' way of using OpenGL, using only low-level methods. I don't know if this is a totally naive thought, but is there a 'professional' way of writing OpenGL, to get out its maximum functionality? Like, presumably, game developers wouldn't use glutPostRedisplay() for example, right? It seems too easy and convenient, like it hides a lot of what is going on. I suspect this is also true for C++ since GLUT callbacks aren't friendly with methods in namespaces (as I've seen in other questions).

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

夏至、离别 2024-12-20 01:05:21

\ 1.我理解OpenGL只是一个标准,而不是一个软件。例如,“获取”OpenGL 实际上涉及获取
第三方实现,不一定非得是
得到 Khronos 的认可。

的确。

\ 2. OpenGL通常指GL实用程序(GLU)和GL实用程序工具包(GLUT)的组合。他们的方法始于
分别是 gluglut。以及“基本”OpenGL 方法,开始
简单地使用gl,由那些制作图形驱动程序的人实现,
即英伟达?

不。OpenGL 只是以 gl... 开头的函数。其他所有内容(GLU、GLUT)都是第三方库,OpenGL 未涵盖。

\ 3. 我假设 glut 方法是特定于操作系统的帮助程序,例如 glutKeyboardFunc() 必须是,才能解释键盘。所以如果我
我想要一种更强大的替代方法来解释键盘输入
只需使用操作系统 API。 OpenGL本身纯粹是关于图形的,但是
glut 有这样的事情,因为没有图形就没有太多
实时人工控制。

正确的。 GLUT 是一个非常小的框架,因此强烈建议使用其他框架。

\ 4. 在我看来,glu 方法可能与调用一系列较低级别的 gl 方法相同。我想引用一个例子
glOrtho()gluPerspective()

我认为您指的是 gluOrtho2D 但是的,您是对的。 glOrtho 是一个真正的 OpenGL-1 函数。在某种程度上,gluOrtho2D 是有史以来最无用的函数之一:

void gluOrtho2D(GLfloat left, GLfloat right, GLfloat bottom, GLfloat top)
{
    glOrtho(left, right, bottom, top, -1, 1);
}

我觉得他们有相似之处
工作方式,但计算透视可能更复杂,所以
gluPerspective() 是为了方便起见,但可能只是解决某些问题
gl 方法。

又对了,但实际上非常简单:

gluPrespective(GLfloat fov, GLfloat aspect, GLfloat near, GLfloat far)
{
    GLfloat a = 0.5 * atan(fov);
    glFrustum(-a*near, a*near, -a*near/aspect, a*near/aspect, near, far);
}

从 OpenGL-3 核心开始,整个矩阵操作的东西都被删除了。在任何严肃的应用程序中,它都没有什么用处,因为无论如何你都会自己管理矩阵。

\ 5. 我在大学时使用 freeglut 学习了基本的 OpenGL,并且我一直对使用 OpenGL 的“硬核”方式抱有这样的愿景,使用
仅低级方法。我不知道这是否完全天真
我想,但是有没有一种“专业”的方式来编写 OpenGL,以获得
发挥其最大功能?大概就像游戏开发者一样
例如,不会使用 glutPostRedisplay() ,对吗?

是的,这是可能的,大多数游戏引擎确实会自己完成所有繁重的工作。
libSDL 也涵盖了 OpenGL。就个人而言,我确实更喜欢 GLFW 或自己做这些事情。然而,这并不会改变人们使用 OpenGL 本身的方式。但这只是基础设施,而且主要只是编写样板代码。作为初学者,如果不使用已建立的框架,你只会获得很少的收益。如果您的程序大量使用 GUI 小部件,那么使用 Qt 或 GTK 及其嵌入式 OpenGL 小部件是一个合理的选择。

然而,有些项目非常核心,并且也使用 OpenGL 实现整个 GUI。 Blender 是最极端的例子,我喜欢它。

这看起来太简单太方便了,就像它隐藏了很多正在发生的事情。我
怀疑这对于 C++ 也是如此,因为 GLUT 回调不友好
使用命名空间中的方法(正如我在其他问题中看到的那样)。

过量回调对于命名空间来说是可以的(命名空间只是 C++ 编译时的事情)。但不可能将类实例方法作为 GLUT/C 回调传递。

\ 1. I understand that OpenGL is just a standard, as opposed to a piece of software. For example, 'getting' OpenGL actually involves getting a
third-party implementation which doesn't necessarily have to be
endorsed by Khronos.

Indeed.

\ 2. OpenGL usually refers to the combination of the GL utilities (GLU) and the GL utilities toolkit (GLUT). They have methods beginning with
glu and glut, resp. and the 'basic' OpenGL methods, that begin
with simply gl, are implemented by those that make graphics drivers,
i.e. NVIDIA?

No. OpenGL is just the functions beginning with gl…. Everything else (GLU, GLUT) are third party libraries, not covered by OpenGL.

\ 3. I assume that glut methods are OS-specific helpers, for example glutKeyboardFunc() has to be, to interpret the keyboard. So if I
wanted a more powerful alternative way to interpret keyboard input, I
would just use the OS API. OpenGL itself is purely about graphics, but
glut has this sort of thing since graphics is not much without
real-time human control.

Correct. GLUT is a very minimal framework, so using something else is strongly recommended.

\ 4. It seems to me that glu methods may be identical to calling a series of lower-level gl methods. One example I would like to quote
is glOrtho() and gluPerspective().

I think you refer to gluOrtho2D but yes, you're correct. glOrtho is a true OpenGL-1 function. In some way, gluOrtho2D is one of the most useless functions ever:

void gluOrtho2D(GLfloat left, GLfloat right, GLfloat bottom, GLfloat top)
{
    glOrtho(left, right, bottom, top, -1, 1);
}

They seem to me to have similar
ways of working, but calculating perspective may be more complex, so
gluPerspective() is for convenience, but might just resolve to some
gl methods.

Right again, but it's actually quite simple:

gluPrespective(GLfloat fov, GLfloat aspect, GLfloat near, GLfloat far)
{
    GLfloat a = 0.5 * atan(fov);
    glFrustum(-a*near, a*near, -a*near/aspect, a*near/aspect, near, far);
}

Starting with OpenGL-3 core, the whole matrix manipulation stuff has been removed. In any serious application it's of little use, since you'll manage the matrices yourself anyway.

\ 5. I have studied basic OpenGL using freeglut at university, and I keep having this vision of a 'hardcore' way of using OpenGL, using
only low-level methods. I don't know if this is a totally naive
thought, but is there a 'professional' way of writing OpenGL, to get
out its maximum functionality? Like, presumably, game developers
wouldn't use glutPostRedisplay() for example, right?

Yes this is possible and most game engines indeed do all the grunt work themself.
There is libSDL, which also covers OpenGL. Personally I prefer GLFW or doing the stuff myself, indeed. However this does not change the way one uses OpenGL itself. But this is just infrastructure, and it's mostly just writing boilerplate code. As a beginner you gain only very little by not using an established framework. If your program makes heavy use of GUI widgets, then using Qt or GTK, with its embedded OpenGL widget is a reasonable choice.

However some projects are very hardcore, and implement the whole GUI with OpenGL, too. Blender is the most extreme example, and I love it.

It seems too easy and convenient, like it hides a lot of what is going on. I
suspect this is also true for C++ since GLUT callbacks aren't friendly
with methods in namespaces (as I've seen in other questions).

GLUT callbacks are okay with namespaces (a namespace is just a C++ compilation time thing). But what's not possible is passing class instance methods as GLUT/C callbacks.

丶情人眼里出诗心の 2024-12-20 01:05:21

您似乎对 OpenGL 和 takeit 有很好的了解。不知道还有什么可说的。
我想(5)确实是一个可以发表评论的地方。

根据您正在构建的应用程序类型,您认为有些人会选择仅使用本机 GL 调用来构建其应用程序,这是正确的。

例如,如果您在 Windows 下构建一个具有 OpenGl 视图以及标准菜单和工具栏的单文档应用程序,那么您很可能会想要直接使用 C++ 和所谓的“低级”API。

但是,如果您在全屏模式下构建低节奏游戏,那么如果 Glut 或任何其他工具包可以简化应用程序的开发,那么您就没有真正的理由不应该使用 Glut 或任何其他工具包。

事实上,您直接单独使用 GLut 或低级调用并不会让应用程序变得更好或更差:)

希望它有所帮助

You seem to have a pretty good notion of OpenGL and the tookit. Not sure what's more to tell.
I guess (5) is really where one can comment on.

Depending what type of application you are building you are right in thinking that some will choose to build their application only using the native GL calls.

For example, if you build a single document app under windows that has an OpenGl view but also the standard menus and toolbars, there is a strong chance you will want to go straight for c++ and what you call "low level" api.

However, if you build a low paced game in full screen mode, there is no real reason why you should not use Glut or any other toolkit for that matter if it ease the development of your app.

The fact you use GLut or low level calls directly alone doesn't make the app better or worst :)

hope it help

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文