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