渲染是3D引擎不可缺少的模块，这两天在思考如何把这个部分设计好。
首先明确需求，最起码的因该是把图形API进行抽象风装，这样引擎只调用经过抽象的渲染接口，这样便于扩展到其他图形API上，简单来说就是把GL/GLES/D3D的通用的API抽象出来到CRenderBase上，再由此派生CRenderGL,CRenderGLES,CRenderD3D等分别实现，完成底层渲染API的分离。这是最起码要做到的，接下来就是一些具体的渲染工作到底是放在CRender里面还是放在具体到CEntity上，比如网格的渲染等。
这时有两个不同的设计思路，这两种思路户为互补，又很难并存。一种是保持CEntityMesh这样的几何实体实现简单，里面只包括对几何数据必要的操作，渲染则放到CRender里面，也就是有这样的函数CRender::RenderMesh(...); 这样做的好处是所有渲染相关的东西完全被放到了CRender里面，看起来结构较为单纯，当然它也有问题，这就是下面要提到的另一种思路。另一种思路是则是保持CRender的单纯，他的最主要的工作就是对底层API进行隔离和不同图形API的统一风装，EntityMesh自己写渲染函数并调用CRender的方法，也就是这样的函数CEntityMesh::Render(...); 这样做的好处是在CEntityMesh这个角度看和他相关的都被完整地写在了自己的类里面，如果哪天不要CEntityMesh了直接把这个类删掉就行了，不影响其他，而第一种思路除了删掉CEntityMesh类以外还要对应删掉CRender::RenderMesh函数，当各种实体之间互相调用关系比较复杂的时候，很可能会不那么容易删的彻底且仍然看来其来设计良好。这也是第二种方法的好处。
第一中方法在不少的商业引擎里面可以看到，而结合我的引擎，我使用的是第二种方法，总的思路是保持CRender的单纯，这是引擎底层写好了一般不动，同时尽量保持CEntityMesh这样实体类的内聚与模块化，添加删除这样的实体类尽量保证其对外影响最小。