GamerClass Shading系统设计【四】需求-扩展性

扩展性：这个东西必须容易修改

钉死几种模式，比如，GC只允许你有Static Mesh和Skinned Mesh，光照模型只能有一种——全动态光照，必须都有阴影，那么好了，这就不用说这么多废话了。

需要说废话，是因为我们有理由为扩展付出心思。如果因为换了一种光照模式，换了一种表面描述，就必须大量修改代码，还要牵动调用方的话，那GC就也不用继续下去了，每天都老老实实的去改原来的代码就行了。

在DX8的时代，我们甚至未曾敢考虑过Deferred Shading的一丝“可能”。但到DX9C时代，Deferred Shading就很容易实现了。SSAO、Lighting Environment，等等等等，这些很酷，很眩，又很便宜的技术，不由得你不支持。

另一方面，DX10提出了新的Geometry Stage，而DX11更是提出了三个新的Stage。Shader的地位逐步在加强，已经慢慢的从CPU的附庸，变成了与CPU平起平坐的兄弟——甚至已经成为了另一种意义上的CPU，可以进行传统CPU无法胜任的高性能计算（CUDA、物理加速）。

即便在现在，当下，渲染数据的来源就已经千奇百怪了，并不仅仅是Mesh的顶点，还包括预生成的光照图，骨骼动画，球谐（SH）光照环境，Displacement Map，Instancing以及预缓存的PRT信息等等。而与此相配合的，渲染数据的表现则可能更加复杂。看看NVidia，看看ATI的网站吧！在可以预见的未来，数据的来源和表象可能会更加难以捉摸。

但是，无论数据来源和表现特征多么复杂，我们所需的，应该是一条稳固的通道和体系，如果说，有一个体系的引入，就必须修改引擎结构的话，那将是很恐怖的工作量。一个好的体系支撑下，你可以在没有需求的时候，持续一两年不去做动态阴影支持，但当需求一到的时候，你可以不修改结构，只需要插件，就能插接新的功能到你的引擎里去。这就是设计的作用！

为什么要话这么大心思来说这些看似是废话的东西呢？事实上，现在的网络这么方便，过去被人们捂来捂去，当作秘籍、传的东西，现在实际上已经到处可寻。中文的或许并不多，但是英文的则很方便。对技术的实现，需要时间和精力的持续保证，一般来说，有勇气，有恒心，有毅力，就可以去抄，去研究（当然有些算法要恶补数学……）。

但是，引擎和Demo的不同就在于引擎是为了游戏制作者的方便而考虑的。既然要游戏制作者方便，就必须为扩展性提供足够的考虑。这中间，针对引擎升级，有几个问题需要面对：

1，引擎升级或者Fix BUG后，制作者的代码是否需要修改？需要多大程度的修改？

这个看起来简单，事实上并不容易，因为新的接口很有可能极大修改原有流程，比如DX8和DX10的流程，差得很远。

2，引擎升级后，旧功能会在多大程度上可以继续使用？是完全不能使用？是能使用但效果或者性能变差？还是能使用但不能修改（最常见是因为旧的流程被抛弃，实际上硬编码了旧接口的实现）？还是能使用且能修改以加入新功能？

但是这个世界上总有很多必须要变的东西。比如：Instancing提出了，这么好用的东西，想用，变不变？得变。Deferred Shading提出了，这么好玩的东西，想用，变不变？也得变。

关键不是变本身，而是如何去变。U3给出的方案就是围绕着Vertex Factory（顶点）、Material Proxy（表面）和Policy（受光）的一整套方法（后面的章节希望能提供对其的粗略描述），这种方法的好处是可以在编译期确定所有可能的Shader组合，进行Shader的预编译。其他引擎也各有各自的高招，比如OGRE则可能就是围绕着Render System和Render Object，Victory是围绕着Modifier（视图）和Model Object（模型）。

可能大家想到的方法八仙过海，各显神通，但是，有一点共性是可以确认的，那就是只有钉死了数据和大流程，才能在这个前提和基础上，实现相应程度的扩展性。为了描述这个问题，我希望能在下一节大概提一提U3的大体做法，它的做法并不见得是优秀的，但起码足以描述这个问题本身。