这段时间都在弄PostProcess，到现在为止，我对我的设计都不满意。但是也需要做个了结，先实现一些基本的功能。到以后慢慢有了经验了，或是看到了别人比较好的设计方法时再会过头来弄吧。
   我对PostProcess也是从0开始的，最先是网上查看一些资料和看sdk中的那postprocess的例子。说白了，postprocess很简单，就是在最后把场景渲染到一种贴图，然后通过pixel shader对这个贴图进行各种处理已达到想要的效果，然后把贴图以2D的方式渲染出来。整个过程都是很简单的。但是要把postprocess的框架设计的好我觉得是很困难的。框架的好与劣以我暂时的浅薄的看法就是框架不需要为增加一种postprocess效果而改动太大。但是这个问题纠结了我很久。
   我最初的想法是类似模仿sdk中的例子，通过归纳总结出postprocess操作的shader需要些什么数据，然后把数据都传入进去，不管是否需要，比如有些shader需要渲染窗口的backbuffersize的大小用于把像素点大小转化为纹理大小（blur操作），有些shader需要原始场景贴图合并操作，把后处理的tex与原始场景累加（combine操作）。甚至有些c++的代码需要知道shader里面的数据，比如把贴图放大或缩小操作。这种，把所有都归纳出来的话碰到有两个问题：1、归纳无法完善，现在我们能确定的也只是所有后处理的shader需要上一次后处理的结果的tex作为输入源。然后各种不同的shader就有不同需求了，有的只是需要上一次的postprocess结果，有的是需要原始场景贴图，backbuffer的大小，有点还要给外部c++代码提供参数，放大或缩小贴图。2、由于我使用的是直接的shader而不是effect，所以当一个shader里的量没被使用到时GetConstantByName 和GetConstantDesc是不成功的，因为没使用的变量会被编译器优化掉。
   想了很久都卡在这了，但是总不至于每个postprocess都单独的写一份c++的代码去对待吧。最后我也没想出好的什么办法，一个不是办法的办法：封装一个SinglePostProcess类，其代表一个后处理，它带有两个产生列表。一个是提供信息给c++代码使用，一个是提供信息告诉我们shader需要一些什么样的参数设置。然后在pp的框架中就分别根据这两个列表来进行一些设置。这样的缺点就是shader的编写和一些参数的名字是要有规则的，在创建一个SinglePostProcess时需要填写这两个参数列表。
实现的效果：

没经过postprocess处理的截图：

通过了后处理的（bloom处理）截图：



   实现一种效果往往需要多个后处理才能达到，所以我觉得一个好的后处理框架的设计很重要。
后处理就先到次吧，以后想到或发现有更好的设计再弄。接下来还要很多东西要学习····慢慢走吧····