总结
前面我们基本上已经完成对ViewerBase::frame()函数的探究,只剩下renderingTraversals()渲染遍历的探究,虽然就剩下了一个函数,但是这却是最重要的,不可少的一个步骤。他主要是完成对场景的筛选和绘制工作,以及很多线程的调度和同步工作也是在这个函数中完成的。前面的几天我们主要是讲解了完成三个主要的遍历函数,我们来总结一下。
advance(simulationTime); // 记录场景的帧数,帧速率信息
eventTraversal(); // 处理场景的交互事件及其回调
updateTraversal(); // 处理场景的更新回调,以及分页数据的更新
所以我们总结上面的三个动作主要是,更新用户数据, 负责场景对象的运动和管理等等;而这里并没有涉及到有关场 景筛选或绘制的源代码,而是着重于有关用户更新(APP)操作的各类内容,而这些代码中 也几乎没有涉及到线程与多核处理的内容(分页数据库的处理线程是个例外,它并非是与场 景渲染相关的内容)。那么今天我们主要是讲解renderingTraversals()函数。
四种线程模式
因为这里我们会涉及到OSG 目前 提供的四种线程模型。所以我们先来简单的介绍一下他们。OSG 的视景器包括四种线程模型,可以使用 setThreadingModel 进行设置,不同的线程 模型在仿真循环运行时将表现出不同的渲染效率和线程控制特性。通常而言,这四种线程的 特性如下:
SingleThreaded:单线程模型。OSG 不会创建任何新线程来完成场景的筛选和渲染,因 而也不会对渲染效率的提高有任何助益。它适合任何配置下使用。
CullDrawThreadPerContext:OSG 将为每一个图形设备上下文(GraphicsContext)创建 一个图形线程,以实现并行的渲染工作。如果有多个 CPU 的话,那么系统将尝试把线程分 别放在不同的 CPU 上运行,不过每一帧结束前都会强制同步所有的线程。
DrawThreadPerContext:这一线程模型同样会为每个 GraphicsContext 创建线程,并分配 到不同的 CPU 上。十分值得注意的是,这种模式会在当前帧的所有线程完成工作之前,开 始下一帧。
CullThreadPerCameraDrawThreadPerContext:这一线程模型将为每个 GraphicsContext 和每个摄像机创建线程,这种模式同样不会等待前一次的渲染结束,而是返回仿真循环并再 次开始执行 frame 函数。如果您使用四核甚至更高的系统配置,那么使用这一线程模型将 大限度地发挥多 CPU 的处理能力。
与 DrawThreadPerContext 和 CullThreadPerCameraDrawThreadPerContext 这两种同样可 以用于多 CPU 系统,且相对更有效率的线程模型相比,CullDrawThreadPerContext 的应用范 围比较有限;而 SingleThreaded 模式在单核以及配置较低的系统上运行稳定。
今天只是对renderingTraversals(); // 场景的渲染遍历工作,开一个小头,因为它的内容比较的丰富,所以我需要一些时间梳理一下思路。