关于渲染系统,场景管理器,资源管理器设计的一些想法

废话不多说.

 

先从显卡渲染都需要哪些东西说起。

显卡要完成渲染本质上就是要回答两个问题，即画什么和如何画。

 

对于画什么这个问题，是由场景管理器来决定，这也是场景管理最本质的工作。

场景管理器最重要的工作就是根据当前相机位置及朝向，使用各种算法（BSP,四叉树,八叉树或者其他）来快速筛选出场景可渲染的几何体，这就是画什么。

 

对于如何画这个问题，是由材质来解决，在材质中保存了渲染管线参数，Shader等信息，用来设置显卡。

 

 

这样是否足够了，当然不够，这只是完成复杂渲染的一个步骤而已。一个复杂的渲染可能会需要多次绘制，并最终在屏幕空间完成最终的效果。

这样就衍生出这样一个流程:

RenderFlow

Stage0->Stage1->Stage2 ... StageN -> FrameBuffer

其中的Stage0就是告诉GPU如何画和画什么，这可以是来自场景的渲染也可以是来自屏幕的渲染。这样可以实现一个专门的渲染流程，通过解析外部配置的渲染流程文件（通常是xml）来实现各种复杂的效果，这样在不损失效率的同时提供了可配置的灵活性。

 

 

对于渲染系统的设计是仁者见仁智者见智的问题，但大致会有两种思路，在之前的文章中也或多或少提过。

1. 渲染系统仅仅是对API进行一次封装。他解决的问题主要是易于更化各种其他渲染API，时引擎建立在渲染API无关的基础上。在这个渲染系统里面并不会写什么RenderMesh,RenderWater之类的函数，显然这样就使渲染系统和引擎的其他模块发生关系，更具体的讲就是引擎的其他模块会调用渲染系统，而渲染系统也会用到引擎其他模块，这种耦合是双向的。

2. 在渲染系统内实现各种渲染方法，比如RenderMesh，RenderWater等等诸如此类的具体的渲染方法。

 

 

而渲染系统，场景管理器，资源管理三者之间的关系是什么呢？

我更倾向于渲染系统仅提供渲染API封装，不实现具体的渲染方法，这样渲染系统就完全底层了，而且是只能被调用，不能调用引擎其他模块，耦合性单向，这样比较容易进行替换。

场景管理器正如前面所说他负责管理场景内的实体，并收集可渲染得几何体，并形成才智相关的渲染列表，调用渲染系统相关API进行渲染。

场景内的实体会持有具体资源的共享指针，资源可以从资源管理系统中获得，这样场景管理器间接（通过实体）与资源管理器发生关系。

 

 

我在做复杂设计的时候有几个原则

1. 简单的设计永远比复杂的好，原子性的操作要胜于某些貌似更加自动化的机制。

2. 我们真的很在乎一些细致末节的效率么？尤其是在假意效率之名破坏简单清晰的设计时请仔细斟酌是否值得。

3. 比起C++重载某些+-*/之类的方法，我宁愿去写add, mul, div这样的函数，至少可以让使用者（或者自己）一目了然的知道这背后意味着什么样的运算。

3. 最好不耦合，单向耦合要好于双向耦合。

4. 在做好第一版之后，再想想是否还可以再简单一些，而不是盲目的增加貌似有用的功能。

5. 在使用中如果发现对于使用者不够方便，或者对于日后的扩展需要增加很多额外的代码，那么请考虑这样的设计是否合理，是否足够简单。

6. 任何设计都有改进的余地，做的越深入就越觉得自己的无知，这时请听听其他人的想法，或许会有更大的启发。