osg 大场景数据的优化

dzm520

请问版主osg 大场景的优化方法有哪些啊？

array

osg的场景树采用BVH包围体层次进行管理，同时提供了LOD节点，以及动态数据分页调度的机制；VPB自动生成的地形还使用了场景四叉树来进行分块。这些机制可以保证我们在osg场景中顺利地浏览百GB以至TB级别的数据。

此外对于大数据的交集测试，OSG还提供了KdTree的加速检测的机制。

dzm520

谢谢array老大了！前两天写了个osg中的大场景调度算法，实现了场景数据随视点动态调度，但当某区域数据量较大时，调度就比较卡，查了查内存也不太大就100多M，但PF使用率高达3——4个G，这是什么原因啊，调度中的节点操作使用了智能指针，加载模型文件在新开启的线程中进行，场景节点操作则在回调中进行，应该不会太卡啊，麻烦array老大给分析分析，谢谢了！

array

您是自己写的调度算法？有一种情况需要注意，osg默认使用显示列表来管理所有的场景对象，因此每一个新加入场景的对象都需要经过一次“编译”（compileGLObjects），即使用glNewList来生成显示列表的过程。默认情况下每个对象的编译都是在第一次显示它的时候，如果同时加载的对象较多，那么这一大串绘制操作会造成内存的剧烈变化以及比较严重的延迟；在DatabasePager中可以指定setDoCompile(true)来强制在调度线程中立即编译每个对象的显示列表，而您的算法可能也需要考虑类似的情形。

此外如果您的算法有自己的特色的话，希望与大家分享您的成果~~呵呵

dzm520

呵呵……我也想到有可能是这个问题了，请问老大那如何解决啊？我的算法比较弱，就是将数据按空间分割成块，再按空间顺序命名文件，然后根据视点的位置和需加载的范围判断哪些模型需要加载、删除，在线程中将文件读取并加载到节点并维护一个添加删除节点的队列，同时在回调中根据队列完成节点在场景中的添加删除，这样就可以实现调度了。由于公司封了USB口代码太多，自己实在没办法将数千行的代码给大家敲上去，真是不好意思啊！不过有问题的话大家可以共同研究研究！array大哥我的这个问题有什么办法可以很好的解决啊？

array

参考DatabasePager中FindCompileableGLObjectsVisitor和compileAllGLObjects的实现代码，以及《最长的一帧》中相关的内容

dzm520

好的，谢谢老大了！