最近一直在做关于shadow的东西，一个“副业”就是把原来用fixed pipeline实现的东西全部换成shader的，为什么？相信做过shadow mapping demo的人都知道。
既然都用shader来实现lighting了，索性都用per-pixel lighting了吧，连spot/fall off和 far/near attenuation都考虑进去吧。这样就碰倒一个问题，一个mesh可能被多个光源影响，所以需要一种dynamic shader merge的机制来动态的生成不同数量和类型光源的组合。在SM3.0上，到是可以吧所有lighting的计算都统一起来，然后把light parameters放到一个1D的texture中，再用一个静态loop搞定所有光源的计算。
恩，抛开SM2.0来看，这样看起来似乎不错。真的吗？
显然不是，shadow的计算还没有考虑了，由于shadow计算需要sample depth texture，而texture sampler在SM3.0下不是indexible的，所以还是得走回shader merge的路子。不要跟我说multi-pass，现在系统的bottle neck就是draw API和geometry pipeline......
deferred shading在各方面看都非常适合我所遇到的情况，我有时真有想试一把的冲动，可惜这样实在太aggressive了，不想被用户骂的话，还是不要那么冒进。
deferred shading的主要问题还是在于fill rate，DX10并不意味者高fill rate，HW feature的发展可以一触而就，但file rate的发展仍然是“后摩尔定理”，即传输率指数级增长，latency成线性增长。（明天继续）
