好了，现在我们经过三节的介绍我们已经大体上明确了单线程模型（SingleThreaded）下 OSG 渲染遍历的工作流程。事实上无论是场景的筛选render还是绘制cull工作，最后都要归结到场景视图（SceneView）的相应实现函数中去完成，渲染器类 Renderer 只是一个更为方便和直观的公用接口而已。
我们总结一下OSG 系统的场景图形，摄像机，图形设备，渲染器和场景视图的关系
OSG 视景器的摄像机（包括主摄像机_camera 和从摄像机组_slaves）均包括了与其对应的渲染器（Renderer）和图形设备（GraphicsContext）；同时，当我们使用 setSceneData 将场景图形的根节点关联到视景器时，这个根节点实质上被添加为此 Viewer 对象中每个主/从摄像机的子节点（使用 View::assignSceneDataToCameras 函数），因而我们可以通过改变摄像机的观察矩阵来改变我们观察整个场景的视角。
场景的筛选（CULL）和绘制（DRAW）工作实质上都是由内部类 osgUtil::SceneView来完成的，但是 OSG 也为场景渲染的工作提供了良好的公用接口，就是“渲染器”。渲染器Renderer 负责将场景绘制所需的各种数据（OpenGL 状态值，显示设置，筛选设置等）传递给 SceneView 对象，并调用 SceneView::cull 和 SceneView::draw 函数，以完成场景的筛选/绘制工作。
摄像机所对应的图形设备（GraphicsContext）同样也可能负责调用 SceneView::draw 函数，这与我们选择的线程模型有关。事实上，由于 OSG 的多线程模型将为每一个图形设备创建一个专门的工作线程（使用 GraphicsContext::createGraphicsThread 函数），并在其中处理与场景绘制相关的诸多工作，因此 GraphicsContext 类在某种意义上也可以视作 SceneView的一个公有实现接口）
场景视图的工作过程中将遍历场景图形的根节点，此时只要获取对应摄像机的子节点就可以了。下面我们就正式进入 SceneView 的内部，看看 OSG 那高效的渲染后台，到底是个什么样子。
网友评论