CE3和UE3在多线程渲染方面的简单对比

由于刚刚开始看CE3，对很多细节都还不是很熟，所以下面的有的针对CE3的描述可能是不准确的，在此先表歉意。

       CE3和UE3都支持多线程渲染，即有一个单独的渲染线程，当然它们都可以通过简单的办法来开关，CE3通过r_multithreaded的值来控制，UE3传递命令行-onethread即可关闭多线程渲染。在某些情况下，比如需要使用perfhud来调试程序的时候，需要关闭多线程渲染。另外UE无论是在编辑器还是游戏中，都默认开启多线程渲染，而CE在编辑器中是禁止多线程渲染的。

        两者实现多线程渲染的方式都是命令缓冲，想必这是目前最好的实现方式了吧？从结构上来看，个人更喜欢UE3的方式，UE3通过封装RenderCommand的派生类来实现渲染命令，然后通过一些列的宏，可以很方便的追加新的渲染命令而不需要修改其它地方。而CE3则采取了相对古老的实现方式：命令ID，这有点类似于网络游戏中发送消息包的ID，因此我们可以看到许多switch case，当然，这是较为陈旧的设计。另外UE3采用宏来生成渲染Command还有一个潜在的好处就在于这个新生成的渲染Command必定在它的主线程发出这个指令的相同位置，这样我们可以在调试的时候通过IDE轻松的找到这个渲染指令的发起者。曾经我对这个宏的存在有很大的疑问，因为它会让我们的代码难于理解和调试，因为宏生成的代码不是每个IDE都能分析的很好，但是现在看来，这个办法实在是太英明了。在我自己写的Engine当中，我就采用的是手写的办法，以至于很多时候我都无法分清到底是谁发出的这个指令。

       整体架构上来说，在这方面UE3还是占优势的，UE3很好的处理了主线程资源和渲染资源之间的关系，比如UE3中的基本渲染单元是PrimitiveComponent，那么它在渲染线程中有一个轻量级的通用场景代表：PrimitiveSceneInfo，以及用于渲染的针对不同PrimitiveComponent不同的Proxy：PrimitiveSceneProxy；PrimitiveSceneProxy被PrimitiveSceneInfo控制。这样的好处就在于主线程无须关心渲染线程的资源是如何处理的，至少对于上层编码来说，是这样的。而对于渲染线程来说，它也无须向主线程交代什么，比如说主线程要动态创建一个模型，那么主线程无须关心渲染线程是如何处理的，也不需要主线程的StaticMeshActor去管理渲染线程拥有的VertexBuffer、IndexBuffer、InputLayout。

       CE3在这方面相对要单薄的多，不像UE3那样的清晰，如果在CE中主线程需要创建一个诸如Texture，VB之类的资源，就需要先把命令序列化到命令缓冲中，然后在同步等待渲染线程完成操作。毫无疑问，这不如UE3的架构合理。不过CE3通过一些“大指令”比如Init指令来让渲染线程一次执行许多的操作，比如分类VB，IB，创建Texture等等，这样使得大量的操作全部在渲染线程完成，这样可以显著减少需要同步的次数。

       另外CE里面Debug模式下感觉开启多线程渲染之后，帧率提升也算是较为明显的，不过CE的Debug模式确实相当的卡，目前还没有去看它到底为什么卡，或许跟Ogre的Debug一样吧，哈哈。Release下面的CE效率真的挺高的，如果UE能有这样的效率，那它就不是UE了，它是UCE。。。