ｏｓｇ ｃｕｌｌ问题

akingbr

最近做一个场景，发现当添加大量的ＩＶＥ模型时候，速度会下降的厉害，（当然面，顶点越多，速度越慢），但有个疑问：

（用的单线程模式）
osg调用cull时候，应该还没把数据送到管线，应该属于ＣＰＵ计算阶段把，我发现把所有的模型移动视锥外的时候，ＣＵＬＬ时间就下降下来了，这２者的区别，应该就是cullvisitor做剪裁的时候，发现模型的包围盒在视锥外，所以就剪裁了，也就是说：
（以geode为例子）：
void CullVisitor::apply(Geode& node)
『
。。。
if (node.isCullingActive() && isCulled(bb)) continue;
。。。
』
就是在这句话返回了，后续的处理就是drawable的pushStateSet，状态树相关，奇怪的是，为什么cull 时间会相差那么多？？

也就是说cull速度的瓶颈难道是大量的模型在创建状态树的耗时操作吗？？

请教下，如两位版主给予指点，非常感谢。

akingbr

补充下，我的场景树节点快１１层，因为用到了ＤＥＬＴＡ３Ｄ里的ｐｒｏｘｙ，所以模型用不少臃余的节点～，在６～１１层分支随模型数量增加递增。～

谢谢

array

场景裁减（cull）的工作是，判断对象是否需要被裁减，然后对剩下的对象重新构建状态树和渲染树，计算远近平面，按照状态排序并准备渲染。树的构建和排序当然是需要时间的，并且这一过程必不可少：因为渲染数据必须按顺序进入OpenGL管线，方能实现正确的渲染结果。

此外，一些数据编译的工作也可能在cull过程中完成

akingbr

谢谢解答。我在打印状态树的时候，发现状态集的合并好像就只能在同一层的场景树节点上，比如说：
node1(status1) --> child1(status2)
node2(status3)-->child1(status2),

在生成状态树的，好像child1并没有被合并，仍然是在两个分支上的？是这样吗？（因为我把模型的mesh关联复用了，但不同的transform带有不同的状态集，但生成状态树时候发现，模型mesh在状态树上虽然都同一状态，却没合并）？？

谢谢。

akingbr

现在就比较困惑的是：　场景里所有点，面数，　场景树的层次深度，以及大量的状态切换，三者分别对程序渲染效率的影响如何，有个量化的判断基准么？
（因为实际操作发现，模型太多，卡，模型类型少，上１０几ｗ面片不怎么卡，模型类型多，１０Ｗ左右就卡，有点晕）


找个一些性能检测工具，不是不能用，就不兼容～～有什么好的建议么，谢谢。

array

您可以阅读我的《最长的一帧》，其中对于状态树和渲染树的构建过程作了讲解，关键是给出了您可以自行阅读的代码位置

模型类型多，１０Ｗ左右就卡，有点晕

如果您做了好的场景结构划分，并进行分页处理的话，那么数TB级别的数据量也不会卡~~

akingbr

多谢ＡＲＲＡＹ指点，ＴＢ级的数据量肯定需要动态载入把，再多问一句：

基于ＯＳＧ，一个好的场景的结构划分的基本准则有那些么？

谢谢。

array

四叉树是一个相当成熟的结构划分方法，VPB中就使用四叉树来做地形分页的
BSP树则被其他一些场景工具用到，OSG的mdl格式支持中就使用了BSP树