这段时间都在弄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处理)截图:
实现一种效果往往需要多个后处理才能达到,所以我觉得一个好的后处理框架的设计很重要。
后处理就先到次吧,以后想到或发现有更好的设计再弄。接下来还要很多东西要学习····慢慢走吧····
posted on 2011-04-28 22:58
木华 阅读(2536)
评论(0) 编辑 收藏 引用