OGRE渲染队列分析总结

  OGRE渲染队列的分析文章貌似可以baidu到一些的，对学习很有帮助，感谢各位的贡献啊。这篇主要是我的学习总结。希望看到的人可以找出理解上的问题，并且留言告诉我，这样才能共同进步的说。

 

  要看RenderQueue那必然要看它的header和source，也就是OgreRenderQueue的相关文件。其实OGRE的很多小的实现思路都是在它的注释中的，可以学到不少东西，了解作者当时是怎么思考问题的。RenderQueue类主要是一个渲染队列的管理器类，在SceneManager中延迟创建，包含了RenderQueueGroup类的一个map成员，该map以一个uint8的值为key，OGRE预先定义了一些这样的值也就是RenderQueueGroupID enum。三个addRenderable方法就是把需要渲染的对象加入到RenderQueue中，稍后会结合流程重新提到。RenderQueueGroup类正像它的注释所提，其实它是一个coarse ordering control。更fine的ordering control都放在RenderPriorityGroup中。RenderQueueGroup包含一个以prority为key的RenderPriorityGroup的map。RenderQueueGroup类就是包含渲染集合的类，它包含几种不同特性的渲染集合：mSolidsBasic、mSolidsDiffuseSpecular、mSolidsDecal、mSolidsNoShadowReceive、mTransparentsUnsorted、mTransparents。从该类的addRenderable可以看出，根据Technique的状态把Renderable添加到不同的QueuedRenderableCollection中去。QueueRenderableCollection类实际存储了最终的Renderable对象，保存在两个集合中：PassGroupRenderableMap mGrouped，按照pass进行排序的集合；RenderablePassList mSortedDescending，descending对象集合，back forward存取就可以得到ascending的集合。渲染队列的基本结构就是这个样子吧。可能还有很多重要的细节，看到的童鞋如果觉得还有什么需要注意的可以留言大家一起讨论。

  继续看看RenderQueue是如何应用到实际的渲染过程中的。OGRE是一个以Scene为中心的渲染器，所以基本上所有的核心代码都在SceneManager的实现中，所以这个类也是相当的庞大......我们主要关注一下RenderQueue涉及的部分。SceneManager::_renderScene：该方法渲染camera对应一个Render Target中的viewport看到的场景。该方法中有一个对_findVisibleObjects函数的调用，这个函数会对场景节点进行递归遍历，用来找到场景中的叶节点的可见Renderable对象，把它们add到之前介绍RenderQueue中，也就是上面提到的addRenderable方法。OK，现在就剩下渲染这些收集到的对象了。_renderScene调用_renderVisibleObjects方法来渲染可见对象，里面有两个分支：custom渲染和默认渲染。默认渲染就是迭代RenderQueueGroup。OGRE在此是用了visitor设计模式。把最终易变化的渲染算法部分重新导向到SceneManager的renderSingleObject方法中去，最终完成了Renderable的渲染。默认的渲染队列就是轮流渲染RenderQueueGroup，自动的处理shadow渲染，根据pass分组渲染Renderable，最后按照降序渲染半透明物体。custom渲染主要就是让你改变这种默认的行为，自己来决定如何渲染这些RenderQueue，主要依赖绑定到Viewport上的RenderQueueInvocationSequence对象来实现。

  当然其中还有很多细节需要分析，这些大部分都是与光照和阴影相关的处理，我觉得这部分代码相对比较复杂，尤其是OGRE支持stencil和texture两种shadow，而且又分为几种小的类别。个人认为也是由于这部分的代码的复杂性让很多想仔细研究OGRE的人望而却步了。要想深入了解这部分代码的原理，没有良好的基础知识，光看代码是很难看懂的。

  最后说说RenderQueue的主要作用，其实就是为了减少由于渲染状态的改变带来的driver中状态管理以及violation的CPU时间以及重置GPU状态的时间，把相同Pass的Renderable放在一起渲染。但是就像Wolfgang的blog里面说的OGRE是一个“重”material的引擎，是很难有效的管理状态切换的，也就影响了OGRE的渲染效率。我个人理解是不能把一些只有少量变化的Pass放在相邻的位置上渲染，不能做到fine sorting，不像WildMagic里面的effect排序管理，效率必然要高，因为WildMagic与Gamebryo的渊源，也就能理解Gb渲染效率高的原因，当然我只是听说，因为没有机会使用Gb，并不实际了解。