之前一段時間因為太忙了, 花在引擎上的時間比較少, 所以也就很少post新的進度. 回台灣後, 則是因為寫引擎太忙了, 所以也沒時間post新的進度 :P
回來這一個月其實也都是都花在修正引擎的一些設計上, 算是refactoring, 所以並沒增加新的功能, 但是引擎的架構更強固也更有彈性了. 有鑑於現在遊戲對光源數量的要求越來越高, 前天晚上則開始將deferred shading部分加入引擎的lighting 系統中, 昨天晚上完成了大致的架構, 基本上會用到三張跟back buffer size相同的GBuffer, 所以當解析度高時記憶體用量會是個問題.
同樣用之前的場景做了測試, 即便在只有一盞環境燈跟一盞聚光等的情況下, 在HD4870上仍有20%的效率提升, 所以光源數多的話效能會提升更多, 而最佳化後也還可以有更好的效能提升(目前還沒有做unlighted pixel的rejection). 看來我應該會朝這方向移動了, 尤其DX10之後很多deferred shading原本的缺點都可以解決了.
-
Posts
5 comments:
請問閣下的 3個 GBuffer 打算用什麼 texture format? 而資料(depth, normal, diffuse ...etc)打算怎樣分配到3個 GBuffer 上呢?
另外想問一問閣下有沒有 order independent transparency 的方案?
基本上這還只是第一個版本, 所以所有東西都是還沒定案. 由於引擎本身就會有Depth Map以及Offscreen(用來存diffuse), 所以三個額外的GBuffers則用來存放Normal, Specular以及Material Attributes, 目前除了Normal是使用ARGB16F, 其他都是使用ARGB8.
OIT比較有名的方法就是depth peeling以及A-Buffer, 我前同事Emil的網站有一些範例.
http://www.humus.name/index.php?page=3D
GBuffer 其实胆子大点也可以用分辨率低一些的版本…… 效果…… 也能接受的
Normal使用ARGB16F和其他32bit格式不同,這樣似乎無法使用MRT用一個pass完成?
因為這只是第一個測試版本, 所以我先用最容易的格式來做, 將來最佳化時當然會考慮減少GBuffer的數目及大小, 使用compressed的資料然後在shader中decompress.
真路人,
D3DPMISCCAPS_MRTINDEPENDENTBITDEPTHS若為true的話是可以支援不同bit depth的MRT的. 新的卡大都支援這個功能了.
Post a Comment