DatabasePager 调度数据清空与模型数据量的关系

dzm520

最近在研究DataBasePager时发现模型的大小对调度时内存的清空影响很大，用小数据量（单个房屋）的模型时内存释放正常，当换成大模型（还有百个房屋）的ive模型时调度时内存释放不及时，导致最终崩溃。而且还发现当用大模型调度时漫游速度较低时内存释放比较正常，但当速度特别快时，内存迅速飙升达到1个多G，而此时场景中只有少量模型，请问有人发现过如此问题没？如何实现在高速漫游状态下DataBasePager内存正确释放？请高手赐教。

array

我无法判断您的问题所在，您是否包含了大量的纹理数据？请尽量将它们分级和优化处理

dzm520

呵呵……不好意思啊，可能是自己把问题没有描述清楚。问题是这样的，现在有200多平方公里的三维模型（包括房屋精模，地形，绿化、小品等（房屋大概有7万多个吧，每个房屋的贴图都比较精细且纹理数据较多）），调度采用两种形式进行了实验：
1.将整图幅的房屋分解为多个单体房屋模型（整图幅的房屋可能有上百个房屋），DataBasePager就含有7万多的房屋节点，且将房屋纹理进行压缩做成两级调度，地块小品等按整个图幅压缩也制成两级调度，通过设置DataBasePager的调度参数，调度效果比较好且内存释放正常，漫游速度较快时，内存释放正常。
2.将所有模型按图幅压缩制作成两级调度，重新设置DataBasePager的调度参数，现在在漫游速度较低的情况下内存释放正常，但当漫游速度较快时内存无法及时释放导致程序最终崩溃。
请问老大，应该分几级啊？如何进行优化啊？如何实现漫游速度较快时内存正常释放？
请老大帮忙啊！谢谢了。

zhufu0208

借贵地也问个问题  
在处理大场景浏览的时候   除了设置模型的lod外  还需要注意哪些？
在设置DataBasePager的时候  我设置了管理共享特性

dzm520

请问 zhufu0208  是“管理共享特性”还是“纹理共享特性”，我好像只见过后者，DataBasePager一般要设置每帧最大编译数目，pagelod最大数目，是否预编译等。

array

这种规模的数据量是必须作分块处理的，使用四叉树等方式对场景进行分块，然后各个分块再作动态调度和包含子节点。直接把所有的PagedLOD传递给DatabasePager，这只会让系统的负担过重

VPB的分级分块策略非常值得您去参考

dzm520

好的，谢谢老大指点！