探索未知种族之osg类生物---呼吸分解之advance

回顾
我们用了两节的内容才堪堪讲解完ViewerBase::frame()函数中调用的realize()---Viewer:: realize()函数。我们简单的总结就是Viewer:: realize()主要是使GraphicsContext处于可用状态,并且启动相关的图形线程。

ViewerBase::frame()函数解读到这里,我们完成了osg生物第一次尝试呼吸所需要的所有器官的初始化工作。下面就真正的开始进入osg呼吸动作的研究了。也就意味着我们真是进入osg的仿真循环的研究当中。那我们就来看看osg呼吸的第一个动作advance()。

osgViewer::advance()
osgViewer::advance()函数的功能算是比较简单的,老规矩先介绍一下这个函数中遇到的新的成员变量。_frameStamp:(osg::FrameStamp)是用来记录osg的帧数以及时钟校准,计数所用到的内置器官,这样可以精确的掌握osg的运行时间,有利于开发人员进行调优工作。在这里(advance())

double previousReferenceTime = _frameStamp->getReferenceTime();
unsigned int previousFrameNumber = _frameStamp->getFrameNumber();
_frameStamp->setFrameNumber(_frameStamp->getFrameNumber()+1);
首先获得osg运行的上一帧时间(是在osg内部记录的时间不是真实世界的时间),以及获得已经运行了多少帧了,并使记录加1(也就是记录目前所处的帧数),

_frameStamp->setReferenceTime( osg::Timer::instance()->delta_s(_startTick, osg::Timer::instance()->tick()) );

if (simulationTime==USE_REFERENCE_TIME)
{
_frameStamp->setSimulationTime(_frameStamp->getReferenceTime());
}
else
{
_frameStamp->setSimulationTime(simulationTime);
}
再设置现在的相对运行的时间(根据当前时刻,重新记录参考时间,并因此得到两次记录之间的差值,即一帧经历的时间)。

// update previous frame stats
double deltaFrameTime = _frameStamp->getReferenceTime() - previousReferenceTime;
getViewerStats()->setAttribute(previousFrameNumber, "Frame duration", deltaFrameTime);
getViewerStats()->setAttribute(previousFrameNumber, "Frame rate", 1.0/deltaFrameTime);

// update current frames stats
getViewerStats()->setAttribute(_frameStamp->getFrameNumber(), "Reference time", _frameStamp->getReferenceTime());
记录这些的目的就是有时候我们需要将帧速率,参考时间等内容予以记录并显示给用户,此时需要通过 ViewerBase::getStats 函数获得 osg::Stats 对象,用以进行帧状态的保存和显示。

if (osg::Referenced::getDeleteHandler())
{
osg::Referenced::getDeleteHandler()->flush();
osg::Referenced::getDeleteHandler()->setFrameNumber(_frameStamp->getFrameNumber());
}
上一段内容基本对advance介绍完成了,只剩下最后一个if (osg::Referenced::getDeleteHandler())判断。它的作用是用来将已经收集得到的所有的osg弃用的对象删除(osg::DeleteHandler::flush())。这里所说的“弃用”,与我们非常熟悉的 osg::ref_ptr 智能指针是密切相关的。我们已经知道,ref_ptr 采用内存引用计数的方式,当一个场景对象(通常是 Node 节点)链接到根节点或者其他节点时,它的引用计数加一,这一动作是通过 ref_ptr::ref()函数实现的;如果它被剔除出节点,那么它的引用计数减一,执行这一工作的函数是 ref_ptr::unref()。unref 函数的另一个重要任务是检查对象的引用计数值是否到达零,如果已经没有被其它对象所引用, 那么称这个对象被“弃用”,它应当被立即删除,以释放相应的内存空间,避免泄露。

osg::DeleteHandler与osg::ref_ptr
C++中通用的删除对象的方法是 delete,OSG 的智能指针也是采用这种方式来释放对 象的,不过由于OSG采用多线程更新/渲染的方式, 这样做可能带来会某些隐患,想象这样一种情况:

1、场景某个的节点负责显示某种图形,它的工作一直很正常。

2、我们采用 DrawThreadPerContext 或者 CullThreadPerCameraDrawThreadPerContext 线程模型。

3、假设我们在更新工作中立即将这个节点删除,而上次渲染工作可能正要将这个节点 中的数据送往 OpenGL 图形渲染管线,那么灾难就发生了……

看到这里,你一定已经想到了一种解决方案。对,就是在渲染后台也使用 ref_ptr 来引用(ref)图形节点,然后在渲染结束取消引用(unref),这样不就可以避免无谓的牺牲了吗?也省却用户的很多麻烦。

说得有道理,不过这其中恐怕忽视了一个核心的问题:渲染效率。是的,假设我们要渲染成千上万个这样的几何体节点(这对您来说也许简直是家常便饭),如果每个节点的渲染 都要多执行一次 ref/unref 的话,效率的损失将是无法被忽略的。事实上经过测算,CPU 时间的流失大概可以达到 6%,对于一个实时渲染系统来说,这的确值得斟酌。

因此,OSG 的新版本中提出了 DeleteHandler 的概念,也就是“垃圾收集”,把那些引 用计数已经为零的对象统一收集起来,确保它们不会再被渲染线程用到之后,再在适当的地 方予以释放。DeleteHandler 有一个重要的参数_numFramesToRetainObjects,它的意义是,垃 圾对象被收集之后,再经过多少帧(默认设置是 2),方予以释放。因此,OSG 的垃圾收集 器同样需要使用 DeleteHandler::setFrameNumber 来记录当前的帧数。 这个概念提出的时间并不长,也许还需要一段时间的测试,也许会有更好的方案来替代 它。目前,OSG 的发行版本仍然采用第一种方式,也就是渲染后台采用 ref_ptr 引用计数的 方式来避免删除对象造成的问题;如果您想要尝试使用和帮助调试 DeleteHandler 的话,可 以在自己的程序中(main 函数之前)加入:

#undef OSGUTIL_RENDERBACKEND_USE_REF_PTR

以请求使用 DeleteHandler。

欢迎大家来我的新家看一看 www.3wwang.cn

原文地址:https://blog.51cto.com/9302896/2355750

时间: 2024-08-29 23:28:08

探索未知种族之osg类生物---呼吸分解之advance的相关文章

探索未知种族之osg类生物---呼吸分解之事件循环一

事件循环和更新循环**终于到了我们嘴里经常念叨的事件循环.更新循环以及渲染循环了.首先我们来区分一下事件循环和渲染循环,他们两个首先是两个不同顺序执行的过程,我们有时候会用到任意node的updateCallback函数,这个就是在更新循环的时候遍历所有的node来调用updateCallback函数的:而事件循环是与用户操作和操作系统事件想关联的,以及调用我们设置的事件回调(EventCallback)函数.而事件循环函数(viewer::eventTraversal())是我们现在要探究的内

探索未知种族之osg类生物---呼吸分解之事件循环二

VPM矩阵1.V 表示摄像机的观察矩阵(View Matrix),它的作用是把对象从世界坐标系变换到摄像机坐标系.因此,对于世界坐标系下的坐标值 worldCoord(x0, y0, z0),如果希望使用观察矩阵 VM 将其变换为摄像机相对坐标系下的坐标值 localCoord(x', y', z'),则有: localCoord = worldCoord * VM 此外,观察矩阵可以理解为"摄像机在世界坐标系下的变换矩阵的逆矩阵",因此 Camera类也专门提供了 getInvers

探索未知种族之osg类生物---呼吸分解之更新循环二

_scene->updateSceneGraph(*_updateVisitor); 我们用了前面4节才刚刚算是完成对DatabasePager::DatabaseThread::run()函数的探究,也就是了解了osg究竟是怎么完成对数据的加载的.那么我们现在要回到DatabasePager::updateSceneGraph的工作中,它是在osgViewer::Viewer:: updateTraversal()函数中遇到的 _scene->updateSceneGraph(*_updat

探索未知种族之osg类生物---呼吸分解之事件循环三

那我们就开始处理这些事件中得到的所有的交互事件,首先我们要判断这些事件是否包含osg的退出事件,那什么情况下会触发这个退出事件呢?如果您运行过osg中example中的小例子的,聪明的你一定就会发现当按下esc时就会退出osg.所以osg中默认的退出事件就是由esc触发的.当然我们也可以通过ViewerBase::setQuitEventSetsDone 设置是否允许按下某个键之后直接退出这种做法, 同时还可以使用另一个函数 ViewerBase::setKeyEventSetsDone 来设置

[转][osg]探索未知种族之osg类生物【目录】

作者:3wwang 原文链接:http://www.3wwang.cn/html/article_58.html 前序 探索未知种族之osg类生物---起源 ViewBase::frame函数中的ViewerInit()及realize() 探索未知种族之osg类生物---器官初始化一 探索未知种族之osg类生物---器官初始化二 探索未知种族之osg类生物---器官初始化三 探索未知种族之osg类生物---器官初始化四 ViewBase::frame函数中的advance() 探索未知种族之o

探索未知种族之osg类生物---状态树与渲染树以及节点树之间的关系

节点树 首先我们来看一个场景构建的实例,并通过它来了解一下“状态节点”StateGraph 和“渲染叶”RenderLeaf 所构成的状态树,“渲染台”RenderStage 和“渲染元”RenderBin 所构成的渲染树,进一步了解这两棵树之间错综复杂的关系,以及理解它们与场景节点树之间更加复杂的关系. 上面是一个虚构的场景结构图,其中叶节点_geode3,以及所有六个几何对象均设置了关联的渲染状 态集(StateSet),且几何体 1 和几何体 2 共享了同一个 StateSet(ss11(

探索未知种族之osg类生物---起源

任何程序都是有生命的,是生命就需要呼吸.例如普通的windows程序,当运行完main()函数后,就需要进入消息循环,来监听用户的各种操作,以便做出及时的回应.这样的每次循环就像生命的每次呼吸,来维持生命体征. osg的程序不仅仅需要消息循环来监听用户的鼠标.键盘等操作,同时也得具备了渲染循环.当然随着我们的对osg的深入了解会发现,osg的事件监听和渲染循环是串行的.但是当我们把osg与MFC(QT)等结合时,相应UI上的鼠标,键盘事件的同时也要兼顾可能发生在osg中的效果,所以一般的osg程

探索未知种族之osg类生物---器官初始化一

我们把ViewerBase::frame()比作osg这类生物的肺,首先我们先来大概的看一下'肺'长什么样子,有哪几部分组成.在这之前得对一些固定的零件进行说明,例如_done代表osg的viewer是否被删除释放内存:_firstFrame代表是否是第一次进入frame函数.那么接下来我们会发现frame函数表面上组成结构非常简单,逻辑上也非常的清晰---先判断当前的viewer是否被删除,也就是判断是否died,如果已经died,那么肺的功能就不会进行.然后判断这个osg小孩是否刚刚出生,是

探索未知种族之osg类生物---器官初始化二

那我们回到ViewerBase::frame函数中来,继续看看为什么osg生命刚刚出生的时候会大哭,除了初始化了eventQuene和cameraManipulator之外还对那些器官进行了初始化.在这之前我们先介绍一下上一节说到的osg的肢体或者器官但是没有展开介绍的. 前言osgGA::GUIEventAdapter,GUI事件适配器.它就是对所有平台windows linux mac平台上的鼠标.键盘.以及其他的窗口事件进行了封装,目的是使接口统一,用户在使用osg库的时候不用再自己区分平