关于pagedlod的读取和淘汰，请指教！谢谢

songgod

现在在做一个项目，用到了osg::pagedlod。

看到了论坛里的一个高人帖子：http://www.osgchina.org/bbs/viewthread.php?tid=863，也看了源代码，发现pagedlod::traverse在满足needToLoadChild条件时并且执行多次后，就会把所有层次的模型都读取出来放到内存里面了。

现在有这种情况：如果有一个城市场景，所有的模型数据都分为三级0~300，300~1000，1000~10000级（m），那么在9000m的视距下，可能看到了整个城市的场景，在这种情况下就会把整个城市的三个级别的模型都读取到内存里面，场景也不会因为裁剪而淘汰。这样岂不是会搞残机器？还是osg还有其他的淘汰路径？

还是我理解的有问题？请各位高手指点一下。


顺便解决一下问题：我已经把DataBasePager中的读取本地文件线程数已经调到100，（网络数为0，单机版程序），但是感觉模型显示出来的等待时间还是很长（理想状态下应该是在远视景首先读取数据量小的粗模，然后“较快的”显示到场景中，到近视景时再读取精模数据，然后显示。）。

望各位高手高手高高手指引一条活路！谢谢！

indif

1."在这种情况下就会把整个城市的三个级别的模型都读取到内存里面，场景也不会因为裁剪而淘汰。这样岂不是会搞残机器？"   首先，即使此时三级数据都在内存里，每帧traverse到的也只有符合当前视距的那一级数据； 其次，所谓数据的淘汰是指过期数据的释放吧，这个应该是在DatabasePager::updateSceneGraph中执行的。

2.文件读取线程决不是越多越好，再多的线程也是共用有限的CPU时间片，太多的线程切换反而会增加系统开销。

songgod

我说的搞残是说内存受不了。整个城市如果算上所有层次的模型或许需要2~3个G的数据量，这样如果都放到普通机器上（1~2个G的内存）就不行了。如果travase都不能根据距离遍历场景，就失去了lod的意义了。

觉得pagedlod不适合于我描述的情况，倒是挺适合vpb生成的地形这种情况。

ghczhaolei

最近也发现了这样的问题，关注中

array

PagedLOD就是LOD的子类，因此当然是根据距离来遍历场景的。不会把“整个城市的三个级别”都读入进来

一般我们会设置setDoCompile(true)来指示DatabasePager负责执行模型的预编译，以提升显示所用的时间；此外还应当适当调整setLODScale的值，保证LOD的负担不会太重

songgod

首先谢谢array对如何提高显示效率给出的解决办法。

但是还是有疑问问array：
按照帖子上的内存结合源代码，pagedlod::traverse在满足needToLoadChild条件时并且执行多次后，就会把所有层次的模型都读取出来放到内存里面了。我不知道这个结论是否正确。

如果上述结论正确的话，在能够看到整个城市的三维场景的前提下，虽然视距是在最粗的模型可见距离范围内，但是pagedlod::traverse执行多次后就会把所有层次的模型数据都读进内存里面，这样机器估计就受不了。

array

为什么您认为“pagedlod::traverse执行多次后就会把所有层次的模型数据都读进内存里面”，也许您可以再仔细阅读一下它的源代码实现，例如：

1. if (_rangeList[i].first<=required_range && required_range<_rangeList[i].second)
   
2. ……

复制代码

这一句就保证视野之外的对象不会被载入

[ 本帖最后由 array 于 2009-6-1 19:39 编辑 ]

ghczhaolei

array，pagedLod读取数据后，当调整视角距离，使模型与人的距离不断的改变，在这个过程中能看到模型的变化，即实现了调度，但是通过读取程序在进程中占用的内存量，发现内存很多时候都是不改变的或有不断增加的趋势（此时显示的是简化的模型），及时很长时间处于简化模型状态，本进程占用的内存量仍与显示精细模型时占用的内存量相近甚至更高。从代码是看不出异常，但是实际确实出现了这个问题。

array

可以通过设置setLODScale来改善这一行为，我个人通常是这样做的

ghczhaolei

谢谢array，试试

xiyatuyun