關於Deferred Rendering的一些想法

1. 應該是未來的趨勢。其壞處之一是需要大量VRAM，但在硬體的快速進展下應該不成問題。
2. MRT數量問題應該也會被硬體進步下解決。
3. Lighting model要全部用同一個的問題也可能被硬體進步後MRT數量變多解決，但相對的pixel shader也要強悍很多才行，不然耗費很多計算在根本沒有作用的東西上(像SSS或parallax occlusion)會跑不動。我想Lighting model部分要依靠硬體進步解決有點難。
4. Lighting model雖然不能變，但是shader依然可以在做一定程度的變化，只是要在一開始輸出給MRT時就先做好計算。像valve source engine裡面用到的Radiosity normal mapping就沒辦法跟一般lighting model混用，但carton render的描邊就可以。因為後者可以直接輸出成只有ambient來做lighting，而前者卻必須要在lighting查照三張不同座標的light map。
5. CPU近期內不會有大幅的速度躍進，能加速的部分看來只有多核心的運用，對於大量的物件與大量燈光的配對(計算物件是否在燈光內以判定要不要計算lighting)可能有一定的幫助，但對與整體繪製速度幫助有限。畢竟大量燈光造成的問題是同一物件不能接受那麼多光源(shader register有限)，且要繪製後才被z-test拿掉的over-draw過多。
6. DX11不知道有沒有將z-test在進pixel shader就先做的機制做出來，如果有的話deferred rendering的好處會下降非常多。但shader register有限的問題依然沒被處理掉。
7. Z-Pass在現階段對over-draw也會有一定的幫助。但同樣的shader register有限的問題還是沒得解。
8. 我沒試過multi-pass來做多盞燈可以做到什麼程度，但我想CommitChanges會吃掉很多效能。另外公司同仁提過用一張貼圖來描述所有燈光的做法我想也是可行，不過因為shader內的loop不可以用即時讀進來的數字(好像是因為PS2.0不是真正的loop而是將HLSL loop展開的關係)，所以只能不管實際有多少盞燈都要跑一個固定的上限值。另外，shader model 3對loop的限制是24，也就是說即使這樣做也只能跑24盞燈。
9. 需要用到多盞燈在同一物件繪製的狀況大多在Terrain上。
10. 看來想要有超過24盞燈在同一個物件作用的話還是乖乖去寫deferred rendering好了。