调试最长的一帧（第18天）

发现一个错别字，改过来，哈哈，

先看看总体流程

直奔renderer::draw()

 

为了查询gpu，在main（）函数先设置，要不没法往下调试

 

重点落在sceneView::draw()以后深入

 

需要删除的对象包括过期的显示列表，纹理，着色器等

 

 

是时候亮出这张图了

抄一抄，我觉得写的很好。

无论是场景的渲染还是绘制工作，最后都要归结到场景视图SceneView的相应实现函数中去完成。渲染器Renderer只是一个更为方便和直观的公用接口而已。

osg视景器的摄像机（包括主摄像机_camera和从摄像机组_slaves）均包含了与其对应的渲染器Renderer和图形设备GraphicsContext

同时当我们使用setSceneData将场景图形的根节点关联到视景器时，这个根节点实质上被添加到此viewer对象中每个主/从摄像机的子节点。

因此，我们可以通过改变摄像机的观察矩阵来改变我们观察这个场景的视角。

场景的筛选CULL和绘制Draw实质上都由内部类osgUtil::Sceneview来完成的。但是OSG也为场景渲染的工作提供了良好的公用接口渲染器。渲染器Renderer负责将场景绘制所需的各种数据（OpenGL状态值，显示设置，筛选设置等）传递给SceneView对象，并调用SceneView::cull和SceneView::draw函数，以完成场景的筛选/绘制工作。

摄像机所对应的图形设备GraphicsContext同样也可能负责调用SceneView::draw函数，这与我们选择的线程模型有关。事实上。由于OSG的多线程模型将为每一个图形设备创建一个专门的工作线程，并在其中处理与场景绘制相关的主动工作，因此GraphicsContext类在某种意义上也可以视作SceneView的一个公有实现接口。不过，它更重要的意义在于，它是OSG与特定操作系统平台API的接口.

调一调,先注释掉单线程。

 

开启摄像机线程了

并行堆栈中

分页数据库开始启动了

可以拉回来了。场景视图的工作过程中将遍历场景图形的根节点，此时只要获取对应摄像机的子节点就可以了。

下一步要集中在SceneView内部了