没有合适的资源?快使用搜索试试~ 我知道了~
首页OSG经典教程最长的一帧
资源详情
资源评论
资源推荐

最长的一帧
王锐(array)
这是一篇有关 OpenSceneGraph 源代码的拙劣教程,没有任何能赏心悦目的小例子,也
不会贡献出什么企业级的绝密的商业代码,标题也只是个噱头(坏了,没人看了^_^)。
本文写作的目的说来很简单,无非就是想要深入地了解一下,OSG 在一帧时间,也就
是仿真循环的一个画面当中都做了什么。
对 OSG 有所了解之后,我们也许可以很快地回答这个问题,正如下面的代码所示:
while (!viewer.done())
viewer.frame();
就这样,用一个循环结构来反复地执行 frame()函数,直到 done()函数的返回值为 true
为止。每一次执行 frame()函数就相当于完成了 OSG 场景渲染的一帧,配置较好的计算机可
以达到每秒钟一二百帧的速率,而通常仿真程序顺利运行的最低帧速在 15~25 帧/秒即可。
很好,看来笔者的机器运行 frame()函数通常只需要 8~10ms 左右,比一眨眼的工夫都要
短。那么本文就到此结束吗?
答案当然是否定的,恰恰相反,这篇繁琐且可能错误百出的文字,其目的正是要深入
frame()函数,再深入函数中调用的函数……一直挖掘下去,直到我们期待的瑰宝出现;当然
也可能是一无所获,只是乐在其中。
这样的探索要到什么时候结束呢?从这短短的 10 毫秒中引申出来的,无比冗长的一帧,
又是多么丰富抑或无聊的内容呢?现在笔者也不知道,也许直到最后也不会明了,不过相信
深入源代码的过程就是一种享受,希望读者您也可以同我一起享受这份辛苦与快乐。
源代码版本:OpenSceneGraph 2.6.0;操作系统环境假设为 Win32 平台。为了保证教程
的篇幅不致被过多程序代码所占据,文中会适当地改写和缩编所列出的代码,仅保证其执行
效果不变,因此可能与实际源文件的内容有所区别。
由于作者水平和精力所限,本文暂时仅对单视景器(即使用 osgViewer::Viewer 类)的
情形作出介绍。
转载请注明作者和 www.osgchina.org
本文在写作过程中将会用到一些专有名词,它们可能与读者阅读的其它文章中所述有所
差异,现列举如下:
场景图形-SceneGraph;场景子树-Subgraph;节点-Node;摄像机-Camera;渲染器-Renderer;
窗口-Window;视口-Viewport;场景-Scene;视图-View;视景器-Viewer;
漫游器-Manipulator;
访问器-Visitor;回调-Callback;事件-Event;更新-Update;筛选-Cull;绘制-Draw。
第一日
好了,在开始第一天的行程之前,请先打开您最惯用的编程工具吧:VisualStudio?
CodeBlocks?UltraEdit?SourceInsight?Emacs?Vim?或者只是附件里那个制作低劣的记事
本……总之请打开它们,打开 OpenSceneGraph-2.6.0 的源代码文件夹,打开

osgViewer/ViewerBase.cpp 这个文件……同样的话就不再重复了。但是如果您没有这样做,
而仅仅是一边聊着 QQ,一边在电话里和女朋友发着牢骚,一边还要应付突然冲进来的老板,
一边打开这篇教程的话——对不起,我想您会在 1 分钟以内就对其感到厌烦,因为它就像天
书一样,或者就像一坨乱七八糟的毛线团,只有家里那只打着哈欠的小猫可能会过来捅上一
下。
不过不用担心,如果您已经耐着性子读到了这里,并且已经看到了 ViewerBase.cpp 中总
共 752 行规规矩矩的代码,那么我会尽全力协助您继续走完漫长的一帧的旅程,并在其中把
自己所知所得(不仅仅局限于那个该死的 frame 函数,而是遍及 OSG 的方方面面)全数灌
输给您。当然也希望您尽全力给我以打压、批评和指正,我只是一个普普通通的梦想着先找
个女朋友成家立业的毛头小子而已,如果我的话全都是对的,那么那些真正的图形学权威们
一定都住在寒风刺骨的珠穆朗玛峰顶上。
好了,废话不再多说。我们这就开始。
当前位置:osgViewer/ViewerBase.cpp 第 571 行,osgViewer::ViewerBase::frame()
frame 函数的内容本身几乎一眼就可以看完。不过要注意的是,这个函数是 ViewerBase
类的成员函数,而非 Viewer 类。因此,无论对于单视景器的 Viewer 类,还是多视景器的
CompositeViewer 类,frame 函数的内容都是相同的(因为它们都没有再重写这个函数的内容)。
该函数所执行的主要工作如下:
1、如果这是仿真系统启动后的第一帧,则执行 viewerInit();此时如果还没有执行 realize()
函数,则执行它。
2、执行 advance 函数。
3、执行 eventTraversal 函数,顾名思义,这个函数将负责处理系统产生的各种事件,诸
如鼠标的移动,点击,键盘的响应,窗口的关闭等等,以及摄像机与场景图形的事件回调
(EventCallback)。
4、执行 updateTraversal 函数,这个函数负责遍历所有的更新回调(UpdateCallback);
除此之外,它的另一个重要任务就是负责更新 DatabasePager 与 ImagePager 这两个重要的分
页数据处理组件。
5、执 行 renderingTraversals 函数,这里将使用较为复杂的线程处理方法,完成场景的筛
选(cull)和绘制(draw)工作。
下面我们就按照 1~5
的顺序,开始我们的源代码解读之旅。
当前位置:osgViewer/View.cpp 第 227 行,osgViewer::View::init()
Viewer::viewerInit 函数只做了一件事,就是调用 View::init()函数,而这个 init 函数的工
作似乎也是一目了然的:无非就是完成视景器的初始化工作而已。
不过在我们离开这个函数,继续我们的旅程之前,还是仔细探究一下,这个初始化工作
到底包含了什么?
阅读某个函数的源代码过程中,如果能够大致知道这个函数的主要工作,并了解其中用
到的变量的功能,那么即使只有很少的注释内容,应该也可以顺利地读完所有代码。如果对
一些命名晦涩的变量不甚理解,或者根本不知道这个函数于运行流程中有何用途,那么理解
源代码的过程就会麻烦很多。
View::init 函数中出现了两个重要的类成员变量:_eventQueue 和_cameraManipulator,
并且还将一个 osgGA::GUIEventAdapter 的实例传入后者的初始化函数。
代码如下:
osg::ref_ptr<osgGA::GUIEventAdapter> initEvent = _eventQueue->createEvent();

initEvent->setEventType(osgGA::GUIEventAdapter::FRAME);
if (_cameraManipulator.valid())
_cameraManipulator->init(*initEvent, *this);
从变量的名称可以猜测出_eventQueue 的功能,它用于储存该视景器的事件队列。OSG
中代表事件的类是 osgGA::GUIEventAdapter,它可以用于表达各种类型的鼠标、键盘、触压
笔和窗口事件。在用户程序中,我们往往通过继承 osgGA::GUIEventHandler 类,并重写 handle
函数的方法,获取实时的鼠标/ 键盘输入,并进而实现相应的用户代码(参见
osgkeyboardmouse)。
_eventQueue 除了保存一个 GUIEventAdapter 的链表之外,还提供了一系列对链表及其
元素的操作函数,这其中,createEvent 函数的作用是分配和返回一个新的 GUIEventAdapter
事件的指针。
随后,这个新事件的类型被指定为 FRAME 事件,即每帧都会触发的一个事件。
那么,_cameraManipulator 呢?没错,它就是视景器中所用的场景漫游器的实例。通常
我们都会使用 setCameraManipulator 来设置这个变量的内容,例如轨迹球漫游器
(TrackballManipulator)可以使用鼠标拖动来观察场景,而驾驶漫游器(DriveManipulator)
则使用类似于汽车驾驶的效果来实现场景的漫游。
上面的代码将新创建的 FRAME 事件和 Viewer 对象本身传递给_cameraManipulator 的
init 函数,不同的漫游器(如 TrackballManipulator、DriveManipulator)会重写各自的 init 函
数,实现自己所需的初始化工作。如果读者希望自己编写一个场景的漫游器,那么覆写并使
用 osgGA::MatrixManipulator::init 就可以灵活地初始化自定义漫游器的功能了,它的调用时
机就在这里。
那么,回到 viewerInit 函数……很好,这次似乎没有更多的内容了。没想到一个短短的
函数竟然包含了那么多的信息,看来草率地阅读还真是使不得。
解读成果:
osgGA::EventQueue::createEvent,osgGA::MatrixManipulator::init,osgViewer::View::init,
osgViewer::Viewer::viewerInit。
悬疑列表:
无。
第二日
当前位置:osgViewer/Viewer.cpp 第 385 行,osgViewer::Viewer::realize()
Viewer::realize 函数是我们十分熟悉的另一个函数,从 OSG 问世以来,我们就习惯于在
进入仿真循环之前调用它(现在的 OSG 会自动调用这个函数,如果我们忘记的话),以完成
窗口和场景的“设置”工作。那么,什么叫做“设置”,这句简单的场景设置又包含了多少
内容呢?艰辛的旅程就此开始吧。
首先是一行:setCameraWithFocus(0),其内容无非是设置类变量_cameraWithFocus 指向
的内容为 NULL。至于这个“带有焦点的摄像机”是什么意思,我们似乎明白,似乎又不明
白,就先放入一个“悬疑列表”(Todo List)中好了。
下面遇到的函数就比较重要了,因为我们将会在很多地方遇到它:
Contexts contexts;
getContexts(contexts);
变量 contexts 是一个保存了 osg::GraphicsContext 指针的向量组,而 Viewer::getContexts

函数的作用是获取所有的图形上下文,并保存到这个向量组中来。
对于需要将 OSG 嵌合到各式各样的 GUI 系统(如 MFC,Qt,wxWidgets 等)的朋友来
说,osg::GraphicsContext 类是经常要打交道的对象之一。一种常用的嵌入方式也许是这样实
现的:
osg::ref_ptr<osg::GraphicsContext::Traits> traits = new osg::GraphicsContext::Traits;
osg::ref_ptr<osg::Referenced> windata =
new osgViewer::GraphicsWindowWin32::WindowData(hWnd);
traits->x = 0;
traits->y = 0;
……
traits->inheritedWindowData = windata;
osg::GraphicsContext* gc = osg::GraphicsContext::createGraphicsContext(traits.get());
Camera* camera = viewer.getCamera();
camera->setGraphicsContext(gc);
……
viewer.setCamera(camera);
这个过程虽然比较繁杂,但是顺序还是十分清楚的:首先设置嵌入窗口的特性(Traits),
例如 X、Y 位置,宽度和高度,以及父窗口的句柄(inheritedWindowData);然后根据特性
的设置创建一个新的图形设备上下文(GraphicsContext),将其赋予场景所用的摄像机。而
我们在 getContexts 函数中所要获取的,也许就包括这样一个用户建立的 GraphicsContext 设
备。
当前位置:osgViewer/Viewer.cpp 第 1061 行,osgViewer::Viewer::getContexts()
在这个函数之中,首先判断场景的主摄像机_camera 是否包含了一个有效的
GraphicsContext 设备,然后再遍历所有的从摄像机_slaves(一个视景器可以包含一个主摄像
级和多个从摄像机),将所有找到的 GraphicsContext 图形上下文设备记录下来。
随后,将这些 GraphicsContext 的指针追加到传入参数(contexts 向量组)中,并使用
std::sort 执行了一步排序的工作,所谓的排序是按照这样的原则来进行的:
1、屏幕数量较少的 GraphicsContext 设备排列靠前;
2、窗口 X 坐标较小的设备排列靠前;
3、窗口 Y 坐标较小的设备排列靠前。
如果希望观察自己的程序中所有的图形设备上下文,不妨使用这个函数来收集一下。简
单的情形下,我们的程序中只有一个主摄像机,也就只有一个 GraphicsContext 设备,它表
达了一个全屏幕的图形窗口;而 osgcamera
这个例子程序可以创建六个从摄像机,因此可以
得到六个图形上下文设备,且各个图形窗口的 X 坐标各不相同,这也正是这个例子想要表
达的。
可是,主摄像机的 GraphicsContext 呢?为什么 osgcamera 中不是七个 GraphicsContext
设备呢?答案很简单,主摄像机没有创建图形上下文,因此也就得不到设备的指针。为了理
解这个现象的原因,我们不妨先回到 realize 函数中。
当前位置:osgViewer/Viewer.cpp 第 394 行,osgViewer::Viewer::realize()
有一个显而易见的事实是:当程序还没有进入仿真循环,且对于 osgViewer::Viewer 还
没有任何的操作之时,系统是不会存在任何图形上下文的;创建一个新的 osg::Camera 对象
也不会为其自动分配图形上下文。但是,图形上下文 GraphicsContext 却是场景显示的唯一

平台,系统有必要在开始渲染之前完成其创建工作。
假设用户已经在进入仿真循环之前,自行创建了新的 Camera 摄像机对象,为其分配了
自定义的 GraphicsContext 设备,并将 Camera 对象传递给视景器,就像 osgviewerMFC 和
osgcamera 例子,以及我们在编写与 GUI 系统嵌合的仿真程序时常做的那样。此时,系统已
经不必为图形上下文的创建作任何多余的工作,因为用户不需要更多的窗口来显示自己的场
景了。所以就算主摄像机_camera 还没有分配 GraphicsContext,只要系统中已经存在图形上
下文,即可以开始执行仿真程序了。
但是,如果 getContexts 没有得到任何图形上下文的话,就说明仿真系统还没有合适的
显示平台,此时就需要尝试创建一个缺省的 GraphicsContext 设备,并再次执行 getContexts,
如果还是没能得到任何图形上下文的话,那么就不得不退出程序了。
创建缺省 GraphicsContext 设备的方法有以下几种:
1、读 取 OSG_CONFIG_FILE 环境变量的内容:如果用户在这个环境变量中定义了一个
文件路径的话,那么系统会尝试用 osgDB::readObjectFile 函数读入这个文件,使用 cfg 插件
进行解析;如果成功的话,则调用 osgViewer::Viewer::take 函数,使用配置信息设置当前的
视景器。这些工作在 osgViewer::Viewer::readConfiguration 函数中实现。
2、读取 OSG_WINDOW 环境变量的内容:如果用户以“x y w h”的格式在其中定义了
窗口的左上角坐标(x,y)和尺寸(w,h)的话(注意要以空格为分隔符),系统会尝试使
用 osgViewer::View::setUpViewInWindow 函数来创建设备。
3、读取 OSG_SCREEN 环境变量的内容:如果用户在其中定义了所用屏幕的数量的话,
系统会尝试用 osgViewer::View::setUpViewOnSingleScreen 函数,为每一个显示屏创建一个全
屏幕的图形窗口;如果同时还设置了 OSG_WINDOW,那么这两个环境变量都可以起到作
用,此时将调用 setUpViewInWindow 函数。
4、如果上述环境变量都没有设置的话(事实上这也是最常见的情况),那么系统将调用
osgViewer::View::setUpViewAcrossAllScreens 函数,尝试创建一个全屏显示的图形设备。
那么,下文就从这几种图形设备建立的方法开始。至于后面的路,果然遥遥无期呢。
解读成果:
osgViewer::Viewer::getContexts,osgViewer::Viewer::readConfiguration。
悬疑列表:
类变量_cameraWithFocus 的意义是什么?
第三日
当前位置:osgViewer/View.cpp 第 575 行,osgViewer::View::setUpViewInWindow()
这个函数有五个传入参数:窗口左上角坐标 x,y,宽度 width,高度 height,以及屏幕
数 screenNum。它的作用顾名思义是根据给定的窗口参数来创建一个图形设备。
首先函数将尝试获取 osg::DisplaySettings 的指针,这个类在 OSG 的窗口显示中扮演了
重要的地位:它保存了 OSG 目前用到的,与图形显示,尤其是立体显示有关的所有信息,
主要包括:
_displayType:显示器类型,默认为 MONITOR(监视器),此外还支持 POWERWALL
(威力墙),REALITY_CENTER(虚拟实境中心)和 HEAD_MOUNTED_DISPLAY(头盔
显示器)。
_stereoMode:立体显示模式,默认为 ANAGLYPHIC (互补色),此外还支持
剩余72页未读,继续阅读


















安全验证
文档复制为VIP权益,开通VIP直接复制

评论0