请教OSG内部数据结构共享问题

lifc

今天研究如何整合libmini和OSG，想到很多用OSG的项目都会同时引入物理仿真和地形系统，而这三者的内部数据集又高度重合（顶点数组、多边形索引、材质坐标等），所以考虑OSG能否与其他二者实现高效的数据共享？
具体情况如下：地形系统生成地形信息数据并提交OSG进行渲染，OSG内部保存地表物体（建筑等）模型数据，物理仿真库又通过访问上述数据实现碰撞检测和运动仿真。
看了几个现有实现（包括delta3d），基本都是在每一帧中调用地形系统生成地形数据，然后创建OSG对象实现渲染，再将OSG内部的数据集通过Vistor取出提交物理引擎（比如delta3d的地形和ode接口），其中反复几次进行拷贝转换，其实多数时候只是改变了一下数据的排列顺序（甚至顺序都没变）。加上一些物理引擎自身提供了外部数据共享访问接口（例如bullet可以通过指定stride或Indexer直接访问外部mesh），由此想到能否将外部数据通过一个简单封装层直接传递指针给OSG，同时将OSG的内部数据引用取出供外部库使用？
初步观察发现Geometry内部数据以ArrayData形式存放，且提供了几个Accessor方法，但追进去之后似乎又与Display list、VBO等有关联，如果直接设置、访问这部分数据不知是否会与OSG发生冲突或者产生某些副作用？

array

可以直接使用dynamic_cast获取顶点、法线和纹理坐标的数组指针（Vec3Array*，Vec2Array*），并加以使用。
如果在循环开始前，那怎么设置都没有关系；如果是在仿真循环运行中，那就要十分注意冲突的问题。

OSG是一个多线程渲染库，也就是在渲染上一帧的顶点数据时，下一帧的用户更新就会开始，这个时候如果您正在更改顶点坐标等信息，那么程序将立即崩溃，或者出现无法预测的结果。因此“反复几次进行拷贝转换”的做法是正确且高效的，不然您只能在更新自己的数据时暂停渲染线程的执行，因而大大降低了渲染的效率

lifc

的确如此，开始就是发现物理引擎的仿真结果和地形数据出现偏差才有此疑问的。开始并不确定问题所在，后来观察到低配置系统（OSG自动选择了单线程模型）运行结果反而正确才怀疑OSG内部的优化机制（比如多线程模型）导致数据并发访问冲突，刚测试了一下果然是这个问题。
看来要追求高效共享光靠“篡改”几个Array还不够，起码要实现个COW（Copy On Write）之类的保护机制才能从根本上解决。
因为模型（包括地形）数据通过算法优化肯定存在一定的持续性（不然OSG构建Display List和VBO也没必要了），所以认为这种优化在特定场合应该还有其优势，只是最终效果还有待进一步验证：）

array

其实如果您设置模型节点的setDataVariance为DYNAMIC，然后再使用更新回调来修改顶点坐标之类的信息，应该不会引发崩溃，这也是在OSG中实现模型动画的重要前提。但是这样的话，就像我在《最长的一帧》中分析的那样，渲染线程会一直等待直到所有标记为DYNAMIC节点更新完成为止，因而损耗了渲染的效率。如何取舍，这是一个有趣的话题。

一个思路也许是使用线程：例如DatabasePager的工作线程中就大量应用了Mutex互斥量来实现数据的保护，也许您可以从中汲取一些灵感。而几何数据数组是否有必要使用COW引用计数呢，这样会提高或者至少不影响渲染效率吗？这样是否会反而加大了OSG内部已经久经检验的多线程渲染机制的复杂性呢？不好说。

FlySky

你有时间可以看看VTP，，，里面整合了libmini和OSG～～～～

lifc

说的有道理，osg内部机制环环相扣，突击学习的结果往往顾此失彼。毕竟自己接触OSG时间太短，目前的很多想法还处在尝试阶段，想达到随心所欲运用自如的境地只有靠慢慢磨练。
其实您的教程还有翻译的Quick start guide我都看过，只是OSG实战经验太少，很多东西就算看几遍也并没有真正理解，还要自己亲自折腾一番才能有深刻体会。看来知识的盗版实在很难，就算有人写出来摆在那里都不一定能偷走：）

lifc

原帖由 FlySky 于 2008-11-14 00:23 发表
你有时间可以看看VTP，，，里面整合了libmini和OSG～～～～

用opengl时接触过一点libmini和vtp，所以这次学osg专门看了一下vtosg部分实现，因为对他的实现策略和效率不太满意（vtp到osg再到物理引擎数据拷贝开销大，内部渲染机制未能利用osg渲染优化），才妄想做点小改造让libmini、osg、Physics engine实现数据共享。无奈功力太浅折腾半天也没能成功只好来向前辈们请教，看来明天要继续研究osg的几个例子...