好忙呀～

近一個月沒更新文章了。

最近有在忙修正舊引擎的效能，還有新增一些功能。

效能上有提升到三倍，新增功能方面是自己挖洞下去的XD。

其實花大部分時間在於看一堆compression文件。

texture在遊戲上是扮演很重要的角色，也是美術的功力展現之一。

我想很多遊戲都將texture作compress動作。

所以身為圖學工程師，要幫他們作把關，

盡量將原圖或近似原圖展現在玩家眼中之外，

又為每種硬體設備做出很棒的調整，

尤其是大量使用normalmap的texture。

這次的backlog的質量相當重，有太多的東西要去研究。

希望這backlog能夠在五月底能夠產生出來。

about the Graphics Memory

為了掌控texture的品質，最近再看關於Graphics Memory的相關資料。

並且去瞭解內部的運作是怎樣的。

BIOS中可以去調整AGP Aperture size，一般玩家覺得調那個可以

加快遊戲執行的速度，其實調那個是並不會增加遊戲速度，

有興趣者請看這份資料：What is AGP Aperture size。

而且在DirectX SDK中，有個Video Memory的sample，

可以教我們如何show出關於video memory的資訊。

除此之外，Window Vista對於Graphics Memory的管理又是另一套方式，

名叫：Windows Vista Display Driver Model(WDDM)

他的相關資料在這：Graphics Memory Reporting through WDDM

最後，

如何去檢查剩餘的Graphics Memory？

可以用RivaTuner和Video Memory Watcher。

以上！

關於dynamic lighting

前幾天看到C9的宣傳影片，發覺到dynamic lighting有明顯進步。

第一次公布宣傳影片時，只有人物和怪物有dynamic lighting。

最新的宣傳影片，多加上Terrain的dynamic lighting運算，但是草則沒有。

草為什麼沒有？這我能瞭解此原因。要作出來是可以，只是效率上的關係。

我這幾天在看一些資料，關於dynamic lighting的作法有幾種：

1.Single Pass PerLight
2.Multiple Lights PerPass
3.deferred shading

第一點的優點是彈性很大，可以隨意去加你想要的light type。

但是效率會不太好，因為batch會提升的關係。

第二個跟第一點是相反的關係。

第三個我就不談了，光是Geometry Buffer就讓人吃不消了。

第一點在製作console game的話，可以拿去實作，

但是在online game的話，我會去用第二點。

其實在C9的dynamic lighting只有Point light而已（影片中），

至於每個geometry能吃多少個光，這我就不清楚了，

能確定的是online game是不能處理太多光源的，原因在於效能。

現在還沒完成，要等到下禮拜一才開始動工，

不過大致上看了一下之後，要實作出來是沒什麼問題，

而且關於玩家的顯卡上的運算方式和光源數量的調整動作，

也是沒有多大的問題。


//////////// 09/03/11 ////////////////


花了兩個工作天，已經把dynamic lighting給完成了，

每個geometry可以吃5個燈光(per-pixel in shader 2.0)，

加上direction light就有六個燈光，至於比較遠的話，會弄成per-vertex。

基於效能的關係，花草不會納入運算，不過樹木會納入。

其實最後會加上bloom效果，會讓人看起來花草有納入運算。

課長講說：試看看能不能吃更多的光。

我想說...就算可以吃很多，但是還沒測過整體效能，

所以吃太多也未必好事。

而且這東西會跟C9一樣，會跟特效放在一起。

智冠春酒晚宴

真是難忘的一個晚上。

昨晚是公司的春酒晚宴，當天有六組團體在表演，

競爭相當激烈！在滿分只有50分之下，

每個團體的分數只有48、49、 50分三種，而我們這組拿下第一名！

而且我們又是第一組表演，所以我們對每一組的表演相當緊張，

因為他們表演的內容也相當好。

而我們主要表演內容是男性的「應援團」，還有女性的「啦啦隊」。

團長（最右邊）和組員：


這兩個是團長：



我後面有小腰包，所以屁股有點翹XD



PanPan（團長）超high低：



大團照：中間那位也是程式課的組員



抓到外星人XD：



我們的星光大道入場：




第一場個人演唱的準備：中間是我們的主角！




我們在一開始的個人歌唱表演時，就當同組的舞伴，

所以那時候已經打下團體第一名的根基！

我在當舞伴時，緊張到在跳舞過程中，腳差一點抽筋XD。

那位歌手當然很快就拿到10個燈，也就是滿燈。

跳完之後，還有人找我們去拍照，真是讓我嚇一跳XD。

重點來到團體表演時刻，沒想到團長一開始站的位置錯誤，

還加上搶拍＠＠！ 還好這都不影響成績，而且可能還會有加分動作，

因為那位團長相當有Fu XD。

我們跳的過程比練習更加有魄力！整個應援團的氣勢有帶出來。

在最後，兩位團長的合體技出了點差錯，不過這都是加分動作XD。

因為我們只是春酒表演，不是比賽表演，只要氣氛帶出來就行了。

在最後的頒獎典禮，我以為是王總會上台頒獎，

沒想到是高雄縣縣長楊秋興＠＠，我超high低！



但是如果是高雄市市長的話，那更好！

因為我們團長跟市長是一樣的髮型XD

在抽獎方面，我們六位應援團當中有四位抽到獎品，

分別有PSP、ipod、五千塊禮券、股票。我就是抽到股票的人！

當時我超high的XD

我們應援團共六人，其中五人是程式開發課，一人是動畫媒體部，

我們團隊不像一般程式人員很害羞的阿宅，我們是很「悶燒」的阿宅。

最後！自樂應援堂！加油加油加油～

PS：其他照片會放在我的無名上。

對SSAO的優化方式和一些感嘆

因為一些原因，所以scene manage暫時不能去動，

其實這一塊還有進步空間。

現在只能以我的部分去試著作一些最佳化。

今天把水底下的任何物件不去作SSAO的運算，

這樣做有好處是：

1.減少pixel的大量運算。
2.在視覺上有正確性的幫助。

第一點的意思比較直覺，因為能夠減少SSAO的運算當然是最好的，

這也是當初用1/2的frame buffer的原因。

第二點要說明一下了，我看過很多的SSAO demo，

就是少了水底下的物件要怎去呈現！

唯一在unreal 3 的demo中，就有看到了。

它還是水底下中有運算到SSAO，但是這作的話，反射的效果會很不明顯。

而且如果沒有反射和折射的效果的話，只是單純的noraml map去抖動，

那水面下會看到SSAO運算到的物件，簡單說：可能會看到黑邊。

所以第二點就是把水底下的物件不去運算SSAO。

其實當我在優化時候，突然想到還有一種優化方式，

不過現在還在實作中，可行性滿高的。

以上的優化方式只是針對GPU的瓶頸去處理的，

CPU的瓶頸還是要去修改scene manage的演算法。

最後，個人一些感嘆：

我看過一些台灣人作出一些高技術的demo，

但是在產品往往看不到此技術。

其實我覺得作出來demo跟商品化還是有一段距離，

尤其是高技術層面的，因為除了還要跟美術去磨合之外，

還有一些問題要去處理，尤其是效能上的。

就好像做出SSAO，但是放上去只剩下幾張fps在動，

我想這根本無法商品化。還有，就是玩家的顯示卡！

這點是很頭痛的，一個game engine，為了考量大量市場，

所以把技術層面降低再降低（聽說仙X Online是這樣？！）。

再掌握高技術同時，也要考慮到底下的人，

如果底下的人想要看此遊戲的完整畫面，只能乖乖去升級，

順便幫Nvidia和AMD賺錢XD。

不過要切記的是，技術愈來愈高並不是單純看高質量的遊戲畫面，

它背面還有針對效能上的提升，所以才有高質量的遊戲畫面誕生。

不講GPU和CPU，光是DX9和DX10之間，我就覺得差滿多的。

所以再過幾年，國人還是在遊走DX9的fixed pipeline的同時，

別人早在DX10或DX11的平台下開發了。

我討厭fixed pipeline

這一個禮拜都在搞fixed pipeline。

發現到他的texture blend的operation好少呀～～

雖然lighting方面都是平行光，不過關於light map的混色很麻煩。

如果只是單純混色就好了，也不會花一天的時間去搞。

還有利用fixed pipeline去寫一個project texture，

以上這些動作都是在Effect中。

這一切的一切都是要支援低階卡的關係，

我們的規格會跟WOW一樣，從GeForce 2 MX400開始，

那張卡是支援DX7的，也就是....9年前的顯示卡，

簡單說就是從hardware T&L 一直到 shader model 3.0都有支援到，

不過我們的shader model是從2.0開始，

我們不打算寫shader model 1.0，那種的顯卡是DX8的，

所以還是會用fixed pipeline的方式去作成像的動作。

///////// 09/2/25 ///////////

今天終於拿到ATI Radeon 7000的顯示卡（另稱貧卡或DX7.0卡）。

主要是拿來測試一下我寫的fixed material，

結果發現到！它可以支援用軟體去模擬vertex shader 1.0，

速度上雖然跟一般的fixed pipeline有一點差別，

不過我們的目的不再專攻DX7.0，而是DX8.0的市場，

如果是這樣的話，那我根本不需要有多大的變動，

但是terrain還是有一點頭痛。這等以後再講吧～

在這幾個月還是專注於架構上，沒什麼時間去寫高階的shader。

優化pre-pass和post-pass

昨天把real-time sadow整合完畢之後，試著把SSAO加進去。

在繪製大量物件時(註)，發現frame降滿多的，

因為以我的神卡是不可能運算過慢，

所以瓶頸還是出在於CPU上。

其實義大利人對於RenderState Change的優化早就有作了，

讓我剩下的優化方式很簡單：就是所有的物件都是instancing。

作用是大大降低DrawXXXX的driver work，

將顯示卡的威能給顯示出來。

這點在DX10作得很好！所以當初為什麼想丟棄DX9的原因。

在這時間點真的要作一下優化了，因為後面還有其他效果要作，

如：SSAO、PSSM、DOF、dynamic lighting、HDR、motion blur。

這是最基本的，後續要作God Rays...等之類，可以讓玩家自由去選擇。

/////// 09/2/16 ///////////////

終於尋找到效能上的問題！

原來是BOOST_FOREACH的使用方式錯誤Orz。

會導致有7000個物件，白白去作拷貝的動作，

其實我的原意並不是這樣。

以下是修正後：


環境：
雙核心 3.01ghz GPU：ATI 4870
解析度：1440 * 900

ssao off

物件總量 = 7400
polygons =308357
drawcall = 733 (包含instance drawcall 的數量)
instance drawcall =527
fps 30

////////////////////////////

ssao on

物件總量 = 7400
polygons = 681737
drawcall = 1281(包含instance drawcall 的數量)
instance drawcall = 995
fps 20



再來是測試少量的instance object

ssao off

物件總量 = 2837
非instance物件總量 = 1736
instance物件總量 = 1101
polygons = 591182
drawcall = 2056(包含instance drawcall 的數量)
instance drawcall = 197
fps 30

////////////////////////////////////

ssao on

物件總量 = 2837
非instance物件總量 = 1736
instance物件總量 = 1101
polygons = 1076542
drawcall = 2552
instance drawcall = 573
fps 25

//////////////////////////////

註：

在雙核心2.66ghz，nvidia 98000GTX+環境下，

假設同一種mesh和單一diffuse color，

繪製16000個geometry，Polys共有545278，開啟instancing之後，

共呼叫23次的draw call，結果fps是120左右。


不開啟instancing時，會呼叫16023次的draw call，fps降到剩下7。



當然這是最佳狀況，主要是mesh的不同，還會格外增加draw call。

DX10可以突破這個缺點，所以要打國戰之類，是可以做到的，

會這樣講是因為看過ATI的最新DX10.1技術，

只要呼叫一次draw call XD。