OSG场景管理

2018-09-01

   场景管理是渲染引擎的核心功能，我们希望能够把所有的渲染物体合理的组织在一起，而且能够方便的查找、管理。本质上就是设计一个或者多个数据结构。这个目标很容易实现，放在一个数组里就可以了，各种操作的代价也不是很大。但是，这是不行的。
   首先，我们需要把显示物体分组，一堆对象可能是属于一起的，在逻辑上在一个集合，虽然我们可以用额外的数据结构来进行分组管理，那很容出错。所以，我们这个数据结构具有递归保存自身节点类型的功能，其实就是一棵树了。
   其次，有的节点是逻辑上的，它只是起保存分组信息的功能（Group），还需要让有些节点保存 渲染物体信息的功能（Geode）。那么，这就需要使用C++ 的继承机制，Geode继承于 Group，另外添加一些保存渲染信息的接口即可。有些引擎不是这么设计的，可参与渲染的节点只能是叶子节点。我倒是觉得OSG的设计更方便一些。目前，osg::Geode 默认它的children都是可绘制对象，因为有碰撞检测的需求，可绘制对象必然会碰撞，所以会强制转换为osg::Drawable类型，这样会导致一个问题：osg::Geode不能把组织节点作为 子节点。这个问题一般不大。
   第三，当我们想要重用一个节点时该如何呢？总不能把节点的渲染数据复制一份吧。所以，需要场景管理的数据结构支持一个子节点有多个父节点。那么，这棵树现在已经变成一个有向无环图 (Directed Acyclic Graph)了。节点需要增加一个指向多个父节点指针的数组。
   第四，OpenGL是状态机机制，但是，场景管理不需要管理渲染API 究竟是如何渲染的，它的职责只是管理了静态的组织结构。如，我们想给一组节点设置属性，如透明与否、缩放程度、是否隐藏、线条粗细、颜色等，所以，节点需要一个保存这些信息的对象（StateSet）。
   第五，因为我们想要自动管理场景内存的功能，如删掉一个子节点，且没有其他对象再引用它，那么就可以把它析构掉，而且需要给子节点对象提供保存用户填入的任何类型信息功能，这就需要提供智能指针的支持，所以提供Object和Reference类支持。我对于智能指针的看法是：这不是解决内存泄漏的终极办法，用的不小心，还是一样要内存泄漏。我们在模块设计时，对象的生命周期就应该被充分考虑，不能说有了智能指针，这部分工作就可以不用做了。
   第六，因为渲染引擎需要支持各种剔除，那么节点需要支持碰撞检测加速，所以节点需要有包围盒，采用最简单的AABB即可，OSG每个节点都保存一个AABB。要是上层有更严苛的需求，再自己使用强大的包围盒算法。这也一般不是渲染引擎的职责。
   第七，简单的3D应用，可能只有一个Camera，但是，复杂的需求一般都会需要使用多个Camera。两个Camera可能只是在不同的角度看向相同的场景，也可能看向完全不同的场景。如一个主Camera，负责看到主场景，一个隐藏Camera，负责设备坐标系的绘制，另一个隐藏Camera，负责绘制需要defer shading的场景， 它们看到的场景时完全不同的。所以，渲染主循环中，遍历Camera以完成渲染，最终按照既定次序把结果组合起来。所以，我们需要把多个场景根节点和多个Camera一一关联起来。OSG的做法是：把Camera作为一个普通的Node，场景根节点root作为Camera的子节点。不得不说这其实挺巧妙的。
   第八，最重要的一个需求就是遍历场景。我们有多种遍历场景的需求，一种方式是建立一个通用的遍历函数，它分析遍历到的节点的类型，调用不同类型的回调函数来处理，这样的话回调函数的管理是一个困难的问题；另一种方式就是采用经典的visitor模式。针对不同类型的需求创建不同类型的visitor，而把子节点遍历与类型判断工作放到Node，这样的话就能很好的递归调用了，缺点是看调用栈会有点懵，可能会产生无限循环递归的错误。把visitor对象交给节点，在节点中把节点的指针再交还给visitor，控制权翻转，在Visitor中重载的不同节点类型处理函数中做你想要的逻辑操作。
   至于osg::Node，官方文档上说：以组合模式，提供了节点基础的操作接口。它把渲染节点、组织节点都做了一个抽象。
   组织管理场景的最重要的几点需求列在上面了，可以看到我们需要的功能点还是比较清晰简单的，也比较容易实现出来。但是，能够做到通用性强，并通过工业强度的检验，还是有难度的。我们做一个模块设计，很多时候，困难的并不是解决常见问题的部分，而是那些比较小但却很不得不解决的问题，导致设计上做了妥协与让步。但是，一步步来，从核心问题开始一个一个解决。

1. http://public.vrac.iastate.edu/vancegroup/docs/OpenSceneGraphReferenceDocs-3.0/a01814.png
2. https://blog.csdn.net/csxiaoshui/article/details/74859066
3. http://www.bricoworks.com/articles/stateset/stateset.html
4. http://www.bricoworks.com/articles/stategraph/stategraph.html

如果有任何意见，欢迎留言讨论。 


[ 主页 ]

COMMENTS