我有一些关于OpenGL的基本观点/问题,不是所有涉及代码而是概念.如果你能回答,肯定或扩展他们中的任何一个,我将不胜感激.我警告你,有些人可能天真,所以请耐心等待.
我知道OpenGL只是一个标准,而不是一个软件.例如,"获取"OpenGL实际上涉及获得第三方实现,而不一定必须得到Khronos的认可.
OpenGL通常指GL实用程序(GLU)和GL实用工具包(GLUT)的组合.他们的方法以gluand 开头glut.而简单的"基本"OpenGL方法gl是由那些制作图形驱动程序的人实现的,即NVIDIA？
我假设这些glut方法是特定于操作系统的助手,例如glutKeyboardFunc()必须要解释键盘.因此,如果我想要一种更强大的替代方式来解释键盘输入,我只会使用OS API.OpenGL本身纯粹是关于图形,但glut有这种东西,因为图形并没有太多没有实时的人为控制.
在我看来,glu方法可能与调用一系列低级gl方法相同.我想引用的一个例子是glOrtho()和gluPerspective().在我看来,他们有类似的工作方式,但计算透视可能更复杂,所以gluPerspective()是为了方便,但可能只是解决某些gl方法.
我在大学时使用freeglut研究了基本的OpenGL,并且我一直只使用低级方法来实现使用OpenGL的"硬核"方式.我不知道这是否是一个完全天真的想法,但是有一种"专业"的方式来编写OpenGL,以获得它的最大功能吗？比如,据推测,游戏开发者不会使用glutPostRedisplay(),例如,对吧？这似乎太容易和方便,就像它隐藏了很多正在发生的事情.我怀疑对于C++也是如此,因为GLUT回调对命名空间中的方法不友好(正如我在其他问题中看到的那样).
dat*_*olf 17
\ 1.我知道OpenGL只是一个标准,而不是一个软件.例如,"获取"OpenGL实际上涉及获得第三方实现,而不一定必须得到Khronos的认可.
确实.
\ 2. OpenGL通常指GL实用程序(GLU)和GL实用工具包(GLUT)的组合.他们的方法以
gluand 开头glut.而简单的"基本"OpenGL方法gl是由那些制作图形驱动程序的人实现的,即NVIDIA？
不,OpenGL只是开头的功能gl….其他所有(GLU,GLUT)都是第三方库,OpenGL没有涵盖.
\ 3.我假设
glut方法是特定于操作系统的帮助程序,例如glutKeyboardFunc()必须要解释键盘.因此,如果我想要一种更强大的替代方式来解释键盘输入,我只会使用OS 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.搅拌机是最极端的例子,我喜欢它.
这似乎太容易和方便,就像它隐藏了很多正在发生的事情.我怀疑对于C++也是如此,因为GLUT回调对命名空间中的方法不友好(正如我在其他问题中看到的那样).
GLUT回调可以使用命名空间(命名空间只是C++编译时间).但是,不可能将类实例方法作为GLUT/C回调传递.
你似乎对OpenGL和takeit有一个非常好的概念.不知道还有什么要说的.我猜(5)确实是人们可以评论的地方.
根据您正在构建的应用程序类型,您认为有些人会选择仅使用本机GL调用来构建其应用程序.
例如,如果你建立windows下单个文档的应用程序,有一个OpenGL视图,而且标准的菜单和工具栏,也就是你将要直行的C++和你所说的"低水平"的API一个很大的机会.
但是,如果你在全屏模式下构建一个低节奏的游戏,没有真正的理由为什么你不应该使用Glut或任何其他工具包,如果它可以简化您的应用程序的开发.
您直接单独使用GLut或低级别调用的事实不会使应用程序更好或更差:)
希望它有所帮助