GamerClass Shading系统设计【二】普遍性与特殊性

在进行Shading系统的设计之前，可能先需要明白大体的需求以及自己手中拥有哪些资源。

在这个系统中，主要包括如下的组成部分：

1，模型数据。用于描述模型的空间位置，外型。模型的处理可能也许要用到Shader，主要是Vertex Shader和Geometry Shader。比如Skin、水面波动、地表波动、粒子系统之类的。

2，材质。用于描述表面的受光特性，表面的属性，包括半透明、线框、是否进行Alpha Test等等。这个视需求而定，可能比较简单，也可能比较复杂。但无论如何，它都可能涵盖整个Shader的三个阶段（VS、GS、PS）。

3，光照处理。例如：延期着色系统和前向着色系统。对于同样的材质，不同着色系统的输出不同。光照可能会走顶点光照，也可能走像素光照，不过对于Deferred Shading这种本身并不处理顶点光照的着色系统而言，可以把顶点光照认为是一种特殊的Emissive材质，这样就只需要处理像素光照了。

其他特殊的处理可能包括，但不限于：

动态阴影：主要在Pixel Shader阶段产生影响。但在此之前，空间深度图是需要渲染系统单独去拍的。

静态光照图：主要影响Pixel Shader，但是可能需要传入Light Map的UV，这个UV一向与Diffuse和Normal的UV不同。

SSAO：像素空间环境遮挡，这个是一个Post Process效果，影响Pixel Shader阶段。

等等。

在对这些功能的分析中，我们不难发现，整个体系的归结点，是两个部分：数据和Shader。例如：模型部分，其数据主要来自于提交的Mesh顶点和Shader参数的设置。只是，不同的几何体，具体提交的数据不同，组成Shader的模式不同而已。

例如：静态模型，不带顶点色的，一般只需要提供顶点、法线和Diffuse UV。带顶点色的多提供一个Color。Skin类型的模型需要再提供一组Bone数组。有Light Map的需要多一组Light Map UV。此外，还需要考虑到，没有法线的模型——可能是Emissive的模型，不需要法线，比如UI上的那些图元。甚至有可能没有Diffuse UV，整个就是一个纯色。

如图，从左到右，分别是只有Diffuse图的Static Mesh提交，有Light Map的Static Mesh提交，和只有Diffuse的Skin Mesh的提交。红色的部分标识了每个提交相对于其他的不同。

 

根据这些，您可能大概能想到，其他的提交会是什么样子。对于引擎的设计者而言，很可能是永远都无法想到用户的诡异的。因此，最好的习惯可能是不要假设说用户“一定会这么做”，而是说“我希望你这么做”。这其实是一个态度问题，90%的用户不会超出你希望的范围，但如果你不考虑那10%的可能，就会在扩展性上捉襟见肘——直到最后被用户、或者变更的系统踩到尾巴。

在上面的列举中，我们很容易发现，当前系统面临的普遍性和特殊性。普遍性就是，所有的问题都可以归结为数据（Mesh顶点和Shader参数）和对数据的渲染（Shader代码本身）。特殊性就是，不同的需求，其数据源和渲染可能会来自各种各样的地方，变化很大。

有了数据和Shader，就可以有效组织模型的数据、材质以及光照处理的代码了。在后面我们会逐步展开这个话题。

在那之前，对于Shader，我们还需要了解的几个基本概念是：

首先，Shader不怕“废代码”。Shader的代码是自动优化的，除非你编译时填写了SKIP OPTIMIZATION，跳过了优化。在每个Shader阶段中，只要是不必要的代码，就不会被执行。

第二，Shader是可插接的。虽然到DX10为止，Shader并不支持虚函数、重载，但是，Shader是支持宏的。最差的情况下，如果我们可以穷举出所有的可能性，那么，在一个很大的，很巨大的Common Shader中，通过#ifdef #elif #endif来处理可能，那么应该是会有一定的成果的。

此外，Shader的编译时机我们也可以灵活掌握。在必要的时候，我们可以根据需要，重新组织Shader代码，然后重新编译Shader即可。

在明白了我们大约面对的问题，和我们手中工具的性质之后，就可以进行需求的分析和设计了。

其实，说白了，设计就是归纳的过程，归纳出普遍性，以期用普遍性去演绎特殊性，这很可能就是设计唯一要解决的问题。