早餐店小型男

出差

2012-02-17T16:56:00.000-08:00

後天星期一要去出差了.

從我任職主管以來,滿想跑跑集團內部的公司.

為了多看看其他公司的文化與運作,台北跟高雄的差距在哪裡?

不過都被擋掉.

這次有機會可以去學習學習.

當然更希望能跟他們做一些交流!

目的地是中華網龍XD

不知道能不能順便見見阿哲(MO BAGEL的 CEO)

霹靂神州online

2011-11-28T21:01:00.000-08:00

幫公司宣傳一下吧～

完整版

 CF版

第一次發佈在霹靂交響會上。

場景幾乎都是遊戲實際畫面，而且還在開發中。

不得不佩服場景美術！

引擎有加入一些新技術，如：景深...等。

只能透露這樣XD

請各位期待霹靂神州online

Mind Mapping

2011-11-12T18:04:00.000-08:00

由於在弄一些教育訓練的事情,組長有提到Mind Mapping的訓練方式.

的確!我平常做事情都是這樣的思維.

希望也讓底下和後續的員工有這樣的思維:不要只看點,要看面(點線面).

這裡有一個免費軟體推薦一下:FreeMind

這樣慢慢累積的話,後輩者看到前輩們以前所寫的思維.

讓他們很快速站上巨人肩膀上之後,就是創造新的東西.

題外話,

說實在不太喜歡現在這環境,不像在做遊戲和研發,

唉~一言難盡. 已經預測自己早晚會被冰起來XD

細節就不談了,要說的話,不如出書拿去賣XD

現在好好專心做這塊,算是對公司的回報.

對身邊的女友也是滿歉意的,連學開車的時間都不想拿出來,

假日和下班都在家裡持續工作,工作到超過12點,

跟上一位工作狂,不能好好帶她出去玩,還有對於未來的事情.....

再給我一點時間吧,一切都會結束的.

最速製程？

2011-07-25T08:29:00.000-07:00

這一個月來，又創造另一個新製程。

是跨原畫、模型、動作的領域，這三者可以同步進行，尤其是動作這塊。

不過這製程很講究團隊精神，不然這東西有等於沒有。

因為只要有一方不配合，就有問題。

這製程摸熟之後，可以將公司帶入次世代遊戲的領域，

但是製作時間不變（一個很厲害的美術的經驗談）。

不過事情不如這麼預期....，在網路上就不多談，還是人的問題。

有多快？

我下載Blade & Soul的模型之後，我只要花15分鐘，

骨架和權重全部完成，動作更快的話，不到10分鐘。

套動作的話，只要有動作資料庫，一分鐘之內就套入完成。

頭髮和布料，在花10分鐘就設定完成，run!

這不算什麼，真正嚇人的是transform system(變形金剛系統)。

不過基於某些原因，我把這功能給拿掉了。

還有一個更可怕的製程，還沒搬出台面上，

又基於某些原因就不想提。

以上這些東西，我想在國外已經跑透透了。

從AION和Blade & Soul都有看到這些的影子。

我會這麼花心思在這裡，為了能讓美術能夠有更多時間去深造去創作。

只是最近耐心愈來愈低了。

不過有一種作法，倒是還沒想到怎麼實做，國外有做到這點。

把一件衣服套入任何「變形」完的體型，而這衣服會自動調整成合身。

可以確定的是這衣服的面數要很高，因為要變形XD。

題外話：最近看到MMD，對於他們物理運算部分還滿不錯的。

感嘆呀...

2011-06-11T09:45:00.000-07:00

這幾個禮拜再弄物理系統的優化，也觀察一些情況。

公司台上主打量產，台下要品質，再加上一些團隊處於一盤散沙狀況。

再怎推量產製程，還得要過人這關，

就算我身為主任（代課長），也無法干涉其他部門的決定，

再加上跟美術觀念之間的差別，

漸漸開始採取比較消極的作法，因為我累了。

這幾天跟動畫部門的美術聊一下，

心中已經決定好關於臉部表情的製程研發，又是參考unreal 3XD。

我很感謝他們，帶給我不少靈感。

不過心中也下定決心不再搞研發了，高雄這邊只剩下我在弄而已。

再遇上一些不如意的事情，所以開始要慢慢轉換跑道，

就是好好當個主管來管理下面，因為很少時間去關心他們，

很多時間花在美術製程與溝通。

想起當初接下TD的職務，有如同神鬼寓言3當上國王時，

你要選擇善良國王呢？還是選擇邪惡國王？

只能說善良國王不好當。在遊戲上，我是選擇邪惡國王來抒發一些壓力XD。

發覺到....邪惡國王很好當，極度有S的屬性。

最後，物理系統算是我最後的代表製程，只要有時間，

私底下會試試想弄的製程，比如說這個：APB online。

胃口愈來愈大了

2011-04-27T07:11:00.000-07:00

老闆對於這次的美術觀摩會，要求愈來愈高了。

尤其是新專案的要求，就要看到新東西，不喜歡有武俠風。

心想：場景在前幾個月有新技術導入，怎還不夠呀～

唉～要趕量又要有新東西，會累死人的。

動作、人物兩方跑就已經快不行了，還加上一個場景要跑....。

還被「偽救世主」搞亂動作製程，弄到自身爆氣，

還說出「不幹了」的氣話。

最後跟兩位製作人談談心，穩定不少心情，本來還想直接找老闆。

不過好消息的是物理系統終於有初步的進展，

參考unreal 3的clothing以及rag doll製作流程，

尤其在3D軟體中的clothing設定，滿方便的作法，

就是可以設定你想哪些polygon有物理特性。

滿不錯的想法，之前在age engine有想過，但是不知道要怎弄，

看過unreal 3的作法再加上長期跟美術配合的經驗，

就把這些特性給抄過來XD。

架構上比之前寫的物理系統更好！

動作美術對物理的導入相當高興，也談到擠乳的效果XD

那個是可以做，不過先把基本盤給磨好吧～

大家在討論的過程，提出不少想法，

深深感覺到.....這就是研發呀～而且是大家一起努力，

這就是我想要的team work。

那個demo內容是mocap + clothing + rag doll，還需要更密集的磨合。

在電視上，看到公司的產品

2011-03-13T06:30:00.000-07:00

好像前兩個禮拜有採訪人員做訪問。

終於看到採訪內容了XD

網址：飄邈之旅online (9:30)

雖然它飄了很久，不過還是很高興它在台灣上市了。

個人沒有參與此專案，參與的程式大部分都是在新加坡，

除了影片上的panpan。

影片的最後合照，本來要入鏡的，因為我人在美術那邊忙事情，

所以他們找不到我。

不過也好，我那時很阿宅，留了好幾個月的頭髮，可以綁辮子了，

直到昨天才去剪頭髮。

很久沒PO文了，最近除了在優化引擎的效能之外，

還開了skinning lod的製程。

在家空閒時間看了ado.net和平行運算的技術(cuda)以及vsto。

最近開始翻起之前age engine導入的物理系統，想開始導入到新專案上，

主要physX有做優化，再加上引擎有優化的動作，

而且對製程上和美術的創意有很大的幫助，讓我有想導入的念頭。

age engine的render部分還不會導入，所以動態光影自然不會有支援，

因為會改很大，而且對製程不會有很大的幫助，只是畫面上的提升，

現在有ao撐著，可以檔好幾年。

未來也會想導入這製程，滿讓我感興趣的，

我想「動X聞」也沒這道製程吧XD。

網址：Grow Rig System

剛好可以整合我寫的auto rigging。

最後希望公司的產品能在台灣有好的發展。

適應期

2011-01-25T07:41:00.000-08:00

剛上任不久，不太習慣處理行政上的工作項。

在專案上還是老樣子，處理的還不錯。

只是會議一直開一直開，想專心弄好製程，只能斷斷續續去處理。

主要底下的組員沒辦法吃我這塊，只能到104找人才XD。

ao部分已經教給美術了，工作量少了一些。

auto rigging部分，還在測試階段中，

這工具對動作製程來講是個可怕的怪物，量產動作非靠這不可！

我的作法跟這相似：Auto rigging。UI沒有用flash啦XD。

體型客制化部分，要做到FFXIV那樣由base延伸出來是沒有什麼多大問題，

可別以為只是縮放骨頭那樣簡單的作法XD。

最後，很多時間和心力花在處理人的問題，

說到這點真的很頭痛，還好製作人幫我負擔這事情，

不然我這邊很難有新東西出來。

因為我們部門算是技術與推銷還有客後服務三點之間的微妙感覺XD

PS：有些製程是建立在技術上。

升官了！

2010-12-02T05:50:00.000-08:00

今天被老闆直接任命當組長。

老闆開新的部門給我去運作，

雖然新部門的名稱未定，

老闆說出來的部門名稱也滿不專業的感覺XD。

部門名稱還可以再討論。

也定好我的搭檔一起來把這部門給弄好，

這部門是個小齒輪，是位於大齒輪與大齒輪之間做轉動。

想想剛進入公司時，壓根不可能會升組長以上。

沒想到老闆親自下來高雄坐鎮，

帶領著公司一步一腳印踏實走下去，

不會像以前飄移不定，政策搖擺。

現在我們這層樓一整個都「精實」起來，

想說每天早上是否要原地踏步然後開始精神答數XD

2010/12/31 更新：

人事令下來了，最後是官階二級跳升為主任（代課長）。

這結果滿出乎我意外。公司也願意大力栽培我，那我也會盡心盡力去努力。

再接再厲

2010-11-25T06:20:00.000-08:00

今天開AO製成part2會議。

這次進行很順利，事前有跟美術主管做好溝通，

再加上幾個效果來襯托出AO的強大性，

還有外掛工具的改善，已經沒什麼多大問題。

接下來給美術做測試使用，當然我會全程協助到底，

他可是這專案的場景成像的王牌殺手之一XD

另一張王牌要看我能不能在專案結束之前趕上。

為了自己能多幫更多美術的忙，也在努力看引擎的底層和工具，

以前自己也花太多時間去創造去研發，

很少時間去看看老外寫的code，除了render engine。

從小細節做起

2010-11-11T01:54:00.000-08:00

這幾天都在新增shader。

雖然都是以前寫過的，不過用在專案上倒是第一次，滿高興的。

其中rim lighting滿讓我驚訝的。

我舊有的blog就有寫到此效果，很早以前寫的。

第一次接觸是Team Fortress 2，所以認為應該用在卡通風格，

其實慢慢寫實風也開始用到，

從早期的昱泉作的流星online，到最近的瑪奇英雄傳和橘子作的Core Blaze

以及九陰真經。

效果上，瑪奇表現的比較好。

我寫的rim lighting美術也接受使用，滿高興的XD

接下來也寫了height fog效果，

這是UDK上的效果之一，雖然不能做到像UDK彈性大，效果逼真。

不過再加上AO效果之後，也衍延出另一個效果，美術們都很喜歡。

我也要開始重新回到AO製成的進度，

趕快把他給完成，只剩下修正和新增功能。

最後，感謝動畫組的人的提供建議，給我不少靈感。

他們用UDK相當順手，果然這類的工具給CG業界的美術比較好上手。

導入Ambient Occlusion和Global Illumination

2010-10-08T09:55:00.000-07:00

前兩個禮拜美術負責場景提出關於點繪圖的技術，

其實就是vertex color，這技術缺點就是面數要多。

結果我決定要導入AO和GI來去補足環境光源。

作法上是把一些資訊記錄在貼圖上，而不是在vertex裡。

而這些資訊來源就是利用xsi來幫忙處理，

我把美術編好的場景通通import to xsi，

這過程都是自動化，當然這外掛是自己寫的。

這作法滿像RenderWare：丟入到max運算。

UDK作法都是在工具上運算光源，

看我們動畫組的作法是在max建場景完畢，

再一次丟入UDK去運算AO和GI。

這研發過程最讓我頭痛的不是外掛難寫，而是GI。

參數不會調，運算又很慢，很多時間都在等算圖，

真希望有八核心XD。

不過現在已經知道怎抓參數了。

GI作法上，其實我會拿Photonmap(光子貼圖)這資訊。

另一個讓我煩惱的是....場景很大，真不知道要算多久，

還有物件的數量多寡來決定這些資訊的品質。

心想：作這麼大場景讓我很頭痛耶。

經過兩個禮拜實作，差不多快到達尾聲了，

剩下要跟動畫組的人借電腦算圖，

日本所製作的音速小子算GI要兩天時間，

真不知道我們這場景要算多久。

還有最後一點，技術上尚未克服，

就是instance object算AO和GI的資訊。

有一些想法和解決方式，不過相當麻煩。

我家門前有小河

2010-09-19T23:04:00.000-07:00

9/19的凡那比颱風，對南部很大的災情。

那天晚上在電腦面前看程式碼，然後突然接到舅舅問安。

舅舅：安嗎？
我：對呀～
舅舅：你家有怎樣嗎？
我：沒呀～（心想：我家如果淹水的話，省道就一片大海了）
舅舅：沒有就好。

通話結束後，心裡在想想....不對呀。

還是跟我女友一起下去看，一邊走下去一邊對女友說。

我：放心啦～就算下有三千的降雨量也不會淹低。

因為離上次淹水是我小時候的事情了。

下去之後看到爸媽在外面弄東西，

我出去看之後，差點腿軟掉XD

我家前面一片大海～

一兩個小時前，我有看門前沒有淹水呀！怎...淹大水了

我們那條巷子每戶都淹進家裡了，但是我家是沒什麼事情。

因為我家在重整時，故意把他作高，預防水淹進家裡。

連家裡的停車庫都沒淹進來，更別說是客廳了。

我拿iphone給拍下我家門前的狀況：

看到這情形就嚇到了，如果在上來40～50公分，

客廳就會淹水了。還好23點多雨勢就減少許多，水位也退了。

新聞說的筆秀村淹水慘狀，那是「內村」的，我們算是「外村」。

「內村」和「外村」中間隔了一條省道，我們這邊地勢比較高。

隔天就發現是檔水牆垮掉，所以我們這邊會淹水。

分享GoSoftimageLite

2010-09-14T19:35:00.000-07:00

簡單說就是類似gomax的外掛。從max到zbrush的雙向檔案載入與輸出。

網址：GoSoftimageLite

要注意看9樓的原PO者，他有作一些更新。

安裝方式裡面寫得很清楚，請自行安裝。

作法方面看了一下，XSI的script寫的滿簡單的，單純把obj給輸出。

然後在ZBrush的工具當中，在import obj。

只是問題出在我不會寫ZBrush的外掛XD

略談FFXIV角色製作手法

2010-09-04T19:59:00.000-07:00

同事丟給我這網頁：「FINAL FANTASY XIV」のキャラクター制作手法

又讓我開始想試著去實作看看，因為我看到了新的量產管道。

從報告來看，我就大約解釋以下幾點：

1.アトリビュート(polygon shaving)：

從下面的影片，可以看出來一個部分可以拆解許多部分。

一般製成都是由原畫設計出來，然後一氣呵成從建模到製圖。

但是原畫設定是以layer的方式，逐漸去規劃出來的。

除了原畫的方式不一樣之外，實作方面也要特別注意。

一個裝備分成許多部分，想必draw call會跟部位形成1比1的狀態。

這樣子的情況，當玩家變多時候，效能會大大降低。

個人用了一種方式之後，就可以克服掉這問題所在。

個人從export到import to engine，最後輸出成像，

這流程已經完成了。說真的，不太難作，只是要有點變化。

2.シェイプ変形(reshaping)

在XSI就有shape blending的功能，

所以看到那個帽子變形，在美術製作上沒什麼問題，

不過個人還沒寫這部分的export，engine也沒支援reshaping（笑）。

但是他主要講解的是不同裝備(布衣加重甲)的組合，

主要運用第1和第2點的作法就可以辦到，這部分我還在實驗中。

還有將同套裝備套用在不同體型上的reshaping，

這點還在思考怎去弄。

3.アイテムのバリエーション(裝備的多樣化)

這點實作不會太困難，只要是資深的電腦圖學工程師的話。

只是他的ideal太棒了！

個人沒想到還有這樣做法，

有了這作法的確可以節省許多功夫，以及資料量。

demo一下：

09/07 更新:

我們的專案目前也有遇到布衣和重甲的手不能混搭。

現在已經可以混搭了，經過實驗之後，確實是可行的，

剩下game play那邊要支援一下。

在公司已經做完完整的報告了，我想他們聽到這樣的製成，

也許都嚇一跳。這樣的製成的確誘人，會省下不少功夫。

接下來會私下找人一起跑看看，關於「裝備的多樣化」製成，

要做出一點成績出來，這樣推技術會比較順利。

畢竟我只是小小的一個員工。

09/11　更新：

已經思考出同套裝備能套入不同的體型的製成，

剩下就是要測試實驗。

如果成功的話，可以省下很多製作功夫。

另一個問題是animation是否要共用？！

共用的話，又很奇怪。

因為每種種族，都有自己特有的動作。

Mocap(Motion Capture)

2010-08-18T07:30:00.000-07:00

在公司某人丟給我這給我看：FFXIV Character，

燃起我無限的熱情和動力，所以這幾天再弄Mocap的製成。

公司買Mocap配備都是給動畫使用，但是專案上遲遲沒人要導入。

在XSI上，從6.0以後有MOTOR技術之後，

XSI就能支援Mocap的功能。

在上次的報告只是簡單介紹MOTOR技術順便demo Mocap，

不過我是拿valve作的Rigging。

這幾天在改動作組所做的玩家Rigging，

發現到不少control不適用於Mocap，會間接影響Mocap的輸出資訊。

這樣會導致輸出之後會大改，這樣不如用手調比較快XD

所以自己才修改Rigging，經過百次的測試和找資料，

終於弄好給Mocap的Rigging，然後在套入進去....，幾乎完美。

只剩下一些小修正。個人除了拿到既有的資料，

然後在Motion Builder修改FCurve，然後在XSI輸出觀看，

短短一兩個小時，就可以輸出兩種動作的產能。

為了Mocap的製成，那幾天個人處於情緒不穩狀態，

因為遇到很多困難點等著去克服，今天終於回收這份成果。

hair和cloth simulation製成上已經有了，

再加上compress keyframe，

在動作上可以大大縮短製作時間提升品質。

不過Mocap並未完成，還是要跟美術進行磨和，

這時期要開始人跟人互動了XD

離目標已經愈來愈近了....

新增連結Mocap教學網頁

台北之旅

2010-07-11T08:02:00.000-07:00

一早十點被公司的製作人開車載去台北，

經過3小時多的車程，路途經過兩個休息站。

我跟女友先在板橋火車站下車，目的地就是地下街。

自從上次去台北的記憶是國小畢業旅行吧～

這次台北之旅給我很大的感覺是：人很多，捷運便宜。

在地下街逛逛，感覺跟高雄的一般夜市擺攤差不多，

吃的費用和量都可以接受，好不好吃是另一回事了。

地下街也有傳說中的遊民在玩電動（笑），

以觀光客眼裡，的確不太雅觀。

逛到五點半，離開地下街作捷運到公館去台大，

人還是超多的，女友跟我分析高雄與台北的人口密度，

高雄是遠遠落差的。

時間大概18：15分到達台大育成中心，

我們真正目的是看大學朋友在台北新開一間公司：

名叫MO BAGEL。

我把製作人介紹給主辦人，希望未來能帶給他好處。

或者他們變成很有潛力的公司的話，

也許我們公司會吃下來也說不定（笑）。

最後，我們晚上還要趕回高雄，

所以21：00就走人了。

回到家已經凌晨一點半了。

這次相當感謝製作人開車載我們，

不然我這一生也許不會到台北一遊（笑）。

cloth simulation with XSI

2010-07-01T02:21:00.000-07:00

前一個禮拜看到關於FF XIII的製成，

前面的カットシーン(cut scene)就省略掉，對我來說太遙遠了。

比較讓我關注的是這影片。

我們專案上也有用到Hair和cloth，美術們只要動作一改，

Hair和cloth也要跟著調整，相當的麻煩。

我自己寫的script再加上XSI的功能，

能快速運算cloth的動作，

運算完畢之後再給美術人員作細微的手調。

雖然跟FF XIII用的方式不太一樣，

不過目的：大大節省調cloth bones。

影片：最內側的bones是已經plot進去。(就是把animation燒進去)

過程中，試了很多方法，也包含ICE。

用ICE的缺點就是碰撞偵測很差，優點是很快速做好前置作業。

澎湖之旅

2010-06-21T07:05:00.000-07:00

上禮拜三開始我的四天三夜的澎湖之旅，

住宿方面是在女友家，因為她是澎湖人XD

從一開始作飛機，這算是我第一次作飛機，

感覺相當緊張，尤其是遇到亂流而像在做雲霄飛車的時候。

不過滿失望的，不是大台那種而是雙螺旋小台的飛機。

到了澎湖之後，第一天是拜見對方父母之外，就是看電視休息。

第二天就是開始旅遊了，

首先到達水族館，剛進去就遇到海龜，超級可愛的。

還有海底隧道，雖然很短但是相當的漂亮。

最後買了一條珍珠手鍊送給女友。

然後在到活了三百多年的古榕樹，看到那顆樹滿嚇人的，

無法用言語形容。我們在那邊吃燒酒螺和仙人掌冰淇淋。

最後就去看鯨魚洞：注意音量

晚上剛好澎湖有煙火秀，由於容量太大所以不能上傳。

第三天下午就去海上牧場，過程是坐船去，

在那邊吃牡蠣和釣海鱺。

牡蠣滿好吃的，我的某位同事吃到拉肚子XD

個人是釣到海鱺，釣魚可是有技巧的。

第三天晚上，一個人獨自在房間看電視，

女友在跟家人play到凌晨一點半＝＝

第四天就準備作飛機回家。

美術研發-動作

2010-06-13T02:54:00.000-07:00

大概花了兩個月的時間，瞭解美術在動作上的製作。

動作這塊滿大的，有許許多多的資訊等著我去看，

就以Rigging來講，就有很多的學問在了，現在這塊尚未完成，

如何寫script做到Auto Rigging，就夠研究了（笑）。

還好友去參考valve所做的auto rigging，給我很大的幫助。

回到主題，這次主要講解動作如何作reuse之外，

還有怎去使用motion capture套入到xsi，並且作編輯動作。

公司有買配備但是遲遲無法用在遊戲上，是滿可惜的。

問一下原因在於卡在mocap data 無法在xsi作細微編輯動作。

其實這很好解決的，xsi許多功能都滿適合遊戲的，只是沒人去挖。

除了這之外，個人寫了compress keyframe的工具，

很大部分也是靠xsi幫忙，

可以在xsi看出壓縮前和後的動作差別，以節省記憶體的使用量。

就舉一個我們製作的boss例子：

輸出163根bones，總共要吃2萬2千個keyframe，

被我一壓之後剩下1098個keyframe，

輸出效果幾乎跟原本的差不多XD

所以一隻人物擁有一千根bones，不再是夢想XD

往後幾個月還會繼續研究動作這塊領域，滿好玩的。

Hair shader

2010-05-31T02:26:00.000-07:00

今天試著作頭髮的shader，搞到快下班就弄好。

結果發現到...原來引擎已經有支援此shader了Orz

只是差別在於我這是用算的且可以染色，另一個是查表方式。

讓我想作的原因是看了這文章：End of Eternity

因為它有用normal map而且想省資源的動機。

這shader會不會用到專案上，就不得而知了XD

查表的話，自己另外在寫一個。

不會隨著燈光方向而改變specular light，原本引擎會隨著燈光作改變，

那自己作一個不一樣的，也可在XSI拉Render Tree，

往後讓美術人員即時看一下成果。

看上圖的燈光就清楚了。

美術研發計畫

2010-05-21T09:56:00.000-07:00

這幾個禮拜忙到昏天暗地，原因在於我推出此計畫（如標題）。

為了提升美術專業技能和改善不良的製作流程所提出來的。

首先，相當感謝高層很贊同我的作法，尤其是我的上司。

這次首先推關於normal map的製作流程，

集合美術的key man，再加上我來一起共同製作normal map。

我對normal map的製作方式研究得很透徹，

不管是正確方式還是「邪魔歪道」，我都嘗試過了。

因為上司的一句話，讓我及時走回正途，要不然會走火入魔。

這次很確定是用Zbrush來雕刻高模。

已經有幾個作品產生出來了，遇到許多問題也克服掉了。

讓我覺得對於製作normal map最困難的地方，

不是雕刻的功夫而是「眉角」（台）。

簡單說只要弄錯一個步驟所產生的normal map就會爛掉，

尤其是切UV時候。

再過幾個禮拜，個人會再推關於動作的製作流程，

所以現在在看相關資料，

自己已經會架骨架拉控制器，調整skin weight...等。

還有其他很多東西要導入以及修改，

恩....好忙XD

到底有沒有戴安全帽？！

2010-05-09T23:33:00.000-07:00

昨天看到一則很有趣的新聞，關於某女鄉民騎摩托車時，

到底有沒有戴安全帽？！看了女鄉民的解說，

給我的感覺是...她好像沒有錯，是警察的問題。

但是我看到這個照片時，讓我覺得是....警察是對的！

yahoo新聞：照片為憑不夠！科學分析比對逼她認錯

我也來科學分析一下，請看這網址：

Anisotropic Shader For Hair

應該看出來哪裡有問題吧～

我以這樣的說法對我女友講時，

女友跟我說：聽到你這翻言論就知道你是工作狂

恩.......XD

測試detial map + normal map效果

2010-04-28T01:11:00.000-07:00

繼續上一篇資訊，我多加入detialmap和gloss map（自己作的資訊）。

前者是增加細微的資訊，後者是控制high light強度。

當然要改一下shader code，比較困難是normal map和detial map結合。

test for:

最後一張，我把靜頭拉到最近，

可以看到細微和normal map產生光影的部分：

我忘了加上AO資訊，以下是添加AO：

detial map的AO，我懶得去算，也不太需要似的。

2010 / 4 / 29 更新：

關於皮膚和衣服的模擬，自己稍微作一下測試，

原圖是256 * 256，我把鏡頭拉到最近，

可以看出來上面是皮膚下面是衣服的一小部分，

中間模糊掉算是測試一下沒有支援detial map的成像。

趁現在很閒的時候，作一些lighting的東西XD

測試一下ambient occlusion + normal map + diffuse map

2010-04-27T05:25:00.000-07:00

好久沒寫shader code了，這次小試一下身手，

跟平常不一樣的是有AO的資訊加入到lighting。

以下的資訊都是自己動手產生的：

diffuse map

normal map :

ambient occlusion map :

Test for:

有注意到的話，這張是無接縫貼圖。

我故意弄成像衣服的皺折樣子，不太像stone該有的紋路XD

個人滿想弄次世代的東西，主要是專案上的進度，

還有其他一些雜七雜八的問題，都來不及搬上檯面。

對呀，還有SSAO和PSSM以及動態光源的東西，

技術上已經克服掉了，只剩下整合的部份，

這部份往往是最雜最麻煩的事情。

自己身上綁太多技術東西了，結果來不及送上市場上XD

課長說我：實做很強，但是架構整合要加強。

說實在，到公司也沒作過很多關於架構上的東西，

很多都是實做技術性東西，還有擦別人的屁屁。

當上TD之後，嗯...我會累死，不過很快樂XD。

同事結婚

2010-04-18T01:52:00.000-07:00

昨天是公司資深企畫主任阿銘的結婚，自己是男方的伴郎之一，

個人主要是負責放炮，女友負責拿DV拍攝。

全程看阿銘如何迎娶美嬌娘的過程，總覺得新郎被玩的好慘XD

該不會總有一天會換我＝＝a

個人也拿著iphone幫阿銘拍下這精彩的過程，

我就放上在喜宴中比較好笑的部分：

JC和園園真情告白（拍攝者：我）

竹蜻蜓算什麼！（拍攝者：女友）

個人還有其他精彩影片，包含王總的祝福致詞影片，內容滿好笑得。

不過這影片不能隨便放上，有興趣者在公司跟我要吧～

終於擔任Technical Artists的職務

2010-03-25T05:29:00.000-07:00

昨天被課長任命為Technical Artists。

因為那款作了好幾年的專案，在遊戲開始作pre-load時，

發現到記憶體吃很大。新加坡決定在高雄選一名TA作督導。

在高雄的公司，也只有我能夠勝任。

關於此職務我很爽快接下來，因為我滿喜歡作這種工作，

不過話說回來，那個專案的問題只要導入多執行序就能解決了。

因為公司要推出的「另外那兩個專案」，如果用pre-load的話，

就算有2G的記憶體，也會吃到爆掉。

如果新加坡不改的話，是否由我親自動刀？！

課長還跟我說，是否需要找兩個手下幫忙？

我的回答是，不用。

此工作剛開始會比較累，主要是跟美術部門之間建立好默契。

還有就是要常常跑樓梯XD

個人覺得TA還是從程式當作起跑比較好，

如果從美術當起跑的話，有一些想法會卡在不會寫工具或

比較艱深的技術層面，往往不了了而已，就如同上面的例子。

所以讓我比較忙的情況是TA跟RD之間跑來跑去XD

如果我沒那麼作的話，根本作不出物理和紙娃娃系統的結合。

最後，好好加油吧～

等到一切就緒完畢之後，未來想導入日本對於console game的製成，

尤其是cut scene。

2D人物一點都不簡單

2010-02-26T07:27:00.000-08:00

前一個月，在弄比較高階的技術，是關於人物和物理的結合，

也確保了製作流程，也錄一些影片給新加坡的工程師看，

大概像blade&soul那樣。不過此東西普遍在MMORPG上，要過兩年後吧～

以現今的玩家配備很難去適應此技術，所以連blade&soul也在年底發售。

這個月我又調回維護舊引擎XD

這次比較強調流暢度和效能維護。

尤其是我們的人物，

實在太誇張了：8方向、20多個動作、每一個動作和方向10幾個部位零件。(註)

零件愈多紙娃娃會更加細緻，當然也會更操美術。

所以一個frame中，要建立1萬多筆物件，

也就是呼叫new operator一萬多次，

再加上讀取十幾個檔案，遊戲不停頓才有鬼XD。

只要我們遊戲遇到整個遊戲停頓下來，別懷疑！那就是讀取其他角色。

說實在，我們人物的2D資料比3D資料更加龐大更加複雜XD。

最後，去運用多執行緒把人物的流暢度給解決掉。

這點說實在，我維護舊引擎引來，最自豪的地方吧XD

因為此條thread，滿複雜的。簡單說：玩家瞬間穿脫兩套裝備的狀況。

現在考慮連切場景的地方也使用多執行緒，

慢慢走向艾爾之光那樣。不過還是會有等待過景時間，

因為有其他因素：像等待server初始封包。

我玩thread愈玩愈上癮XD

現今公司今年要推出三款遊戲，我也集中幫助讓遊戲順利推出，

近期不去碰高階技術，一切都是為了公司好，

遊戲趕快推出去，公司才有未來。

註：像其他2d人物只作兩個方向，
如：風色幻想 online和楓之谷 online。所以比較不會複雜且龐大

台東知本之旅

2010-01-09T04:20:00.000-08:00

慢了好幾天才PO上來。主要最近太忙了，一方面弄公司的事情，

還要弄公司的教育訓練內容，回歸正題吧～

這次三天兩夜的台東知本泡溫泉之旅，是跟閃光一起去的。

南迴歸線也如期修完，坐火車可以直達知本。

從高雄坐自強號火車到知本，花了兩小時二十分的時間，

到了知本火車站，坐計程車到飯店的過程，

也問了司機關於知本的觀光狀況：只有慘字可以形容。

到了飯店作check in的動作，就在飯店休息到晚上，

然後在飯店附近的商店逛逛，結果....人潮小貓兩三隻，

其中兩隻小貓就是我們倆＝＝。

心想：司機不是說這邊是鬧區嗎？！唬我...。

在「大頭目」的餐店去吃晚飯，發現到這邊的料理滿不錯的，

連我討厭的青椒也變好吃了，完全吃不到我討厭的味道！

吃完休息一下，就直接去泡溫泉，滿舒服的。

隔天睡到中午才起床，就到隔壁的7-11買中餐，

這次旅行特別感謝7-11的熱情贊助，讓我們至少三餐都保的住。

因為這附近商店晚上才會營業。下午就跟跑去借機車開始逛，

我們往台11線去逛逛海線，結果...路程相當遙遠，

只到一個地方就回程了。

之後，我們往回騎到知本國家森林公園，門票才50元！

相當便宜～

不過這裡面很大，身為老人的我，走的滿累的XD

我們走到最右邊的瀑布地區就回家了，途中有許多植物，

可惜我不是神農控。

到了晚上，我們出去吃晚餐，發覺到....晚上爆多人的＠＠

跟昨晚相差太多了，每間商店幾乎滿滿人潮，

我們也趁這人潮去買些土產回家。

第三天早上，跟飯店作check out，最後我們也是坐火車回家。

這次旅行主要是泡溫泉，發覺我的皮膚的角質少了很多，

滿想每天都去泡，不過不可能XD

新的一年，迎接新的挑戰。這一年已經想好要作哪些事情，

希望能如期順利。

受到公司的轉變影響，身為研發人員，讓我不再專研圖學，

開始往通才的方向去努力，不過還是專注於TA這塊領域。

這兩年來，懂了許多事情：rendering、physical、multi thread、

tool with C#、xsi、jscript、plug in for xsi。

後三者是今年要努力的目標，加油吧！

Multi-Thread

2009-12-16T04:39:00.000-08:00

這一個禮拜為了專案的需求，去研究一下thread的東西。

雖然大學的OS有上過，不過始終還是理論，並沒有去實作過，

所以在研究過程，腦中慢慢浮現教授所講的內容。

經由boost thread的幫助之下，讓我很簡單的在C++底層底下快速建立thread。

花了一個禮拜完成back loading的工作項，花滿多時間在看文件和架構調整，

還有thread safe的問題，不過還會找時間去測試穩定性，

因為開了三條thread去作，說實在整體架構來講，寫的滿不好的，

不過的確確實花在刀口上，剩下粒子那邊會讓遊戲「頓」一下，

說實在不太想改，因為很麻煩XD。

對於是否要繼續研究？滿值得持續研究，因為未來是多執行緒的時代，

不去用它的話，是滿對不起intel和AMD，不過我只知道intel有提供工具作thread除錯。

最近有看到一款遊戲再使用：艾爾之光。說實在，遊戲流暢度真是好到爆，

我滿欣賞那一款！不知道大陸的東遊記有沒有抄到這項XD。

有開始想著設計multi thread frame work，

無意看到關於multi core遊戲的xbox 360和PC的概念圖(註1)，

讓我想起physX的API使用方式，我大概可以得知他們的玩法，

大概會往那方向前進。

thread是既好玩又很危險的技術，它可以讓你的世界更加美好XD。

公司的事情，也不想提了，主管知道我的blog，不想再被約談了。

簡單講：在那個環境之下，不管弄什麼技術，我永遠都是一個人。

註1：在DirectX的說明檔

新目標

2009-11-27T02:44:00.000-08:00

由於公司內部一些事情，導致Steam Age Engine已經開發終止。

這件事情對我來滿傷的，花了一年半多的時間去改引擎。

之後，引擎都用同一種，而且開發引擎方面，全都交給新加坡。

只能說...想在台灣要研發引擎的人，愈來愈難了。

很多公司都會直接買引擎，將所有人物投入到game play。

看起來很簡單的邏輯，但是買了引擎之後，使用的人會百分百發威？！

最近再弄舊引擎的底層並且憂化效能，雖然架構爛到不行，但是為了出專案，

硬著頭皮也要去修改。我也試著評估將這舊引擎導入新技術，可行性很高，

要導入物理引擎也可以，但是被上司給打槍＝＝。

現在沒了研發引擎的工作項，一度自認熱血已經燒完想說要換工作。

但是前陣子看了日本對於console game的製作流程，讓我滿感興趣的XD

尤其是スクウェア・エニックス製作的ラストレムナント的相關流程，

想說試著去實現看看。

所以開始看大量的日文的SDK，深造plugin的技術，

而且明年打算去考J.TEST，將荒廢好一段時間的日文開始重新鍛鍊。

3D電腦圖學方面，暫時擱住吧～

Rag Doll

2009-10-17T12:30:00.000-07:00

這技術常常在國外看到，尤其是暗黑3也有在使用。

主要是讓美術少做一些功夫之外，一方面也減少記憶體的使用量，

而且整體表現也相當好，只是會比較操電腦的CPU。

這兩天為了趕進度，忙到凌晨3點多才睡，為了要搞這東西＝＝。

這東西看來比我想像中的還難弄點，

最主要的問題在於physical engine的globalPose matrix運用錯誤，

害我一直找哪裡算錯咧～明明就是這樣算的。

這技術，不只是demo而已，連製成管線已經弄好了，

因為一切的流程，自己都一手包辦也自己操作過。

之後，就教一下美術怎製作rag doll。

現在基本功夫已經弄好了，再來後面就是真正的重頭戲！

這部分要保密一下XD

人物系統方面，只能在做一個禮拜，因為基於上司的命令，

要去寫back loading部分。

雖然很有挑戰性，但是個人不太喜歡事情作一半。

個人找到一個很有興趣的rag doll demo。

健康要顧好

2009-10-06T22:57:00.000-07:00

今天跟美術討論次世代繪圖製作流程和新人物系統。

尤其已經掌握Ambient Occlusion map和Normal map製作流程，

所以在大量量產上是沒什麼多大問題，未來會陸續導入新的製作流程。

自己現在是physical和render這兩個方面跑來跑去，

說實在.....滿累的。

再加上自己的個性算是完美論的人，長期累積壓力下來，

終於得了輕狀的胃食道逆流。

醫生說：暫時先用藥物控制，大致上會沒問題。

去年是因為script render pipeline而看精神科，這次是看消化內科。

希望明年不要在搞出什麼科了（笑）。

期望所有拼命的遊戲工程師，好好照顧自己的健康。

PS：三大神器當中，剩下HDR。

終於等到了....

2009-09-14T05:07:00.000-07:00

前幾個月正擔心AGE Engine無法用在正式專案上。

現在已經確定要用在正式專案上，讓我感到興奮！

進遊戲業快兩年了，終於要去寫屬於自己的專案。

之前的專案，幾乎都是擦前人的屁屁，擦的很不高興，

那些前人都跑去寫手機遊戲。

一年前，終於不用擦屁屁了。開始學3D圖學一陣子，

然後修改新加坡那邊人寫的engine，

當然整個Level就是不一樣，畢竟那邊有神級工程師在主導。

這一年的經過，修改許多東西，大部分都是render engine。

直到最近一個月之內，本來再弄物理引擎的東西，

不小心接觸美術的領域，然後自己就身兼Technical Artist(TA)的工作XD。

這期間看了許多資料，去補足關於美術領域相關知識。

發覺到，我們的產製流程相當不人性化，讓美術花上大量的功夫。

今天就跟課長提出次世代遊戲的產製流程，

然後一直聽到課長的驚訝聲（其實我前天就已經驚訝過了XD）。

也很清楚老外遊戲對於畫面上跟我們哪裡差別在哪裡。

以前在想說：常用的lighting運算也那幾種，為什麼差別這麼大呢？

然後試著導入強大技術，也無法解決我心中的答案，直到接觸到TA的領域。

未來把Art Pipeline的技術大大提升，讓美術有很大的創意空間，

也增加量產速度，品質也跟著提升。

不過現在先把全新的人物系統給弄好，這可是這次專案的主要技術之一，

也是人物系統的重大突破，跟一般傳統的紙娃娃說掰掰。

它的強大，可以讓美術自己創造他們想要的「外觀」。

跟一般的「變身系統」和大量的骨骼動畫不一樣，

是個不會操死美術的系統，而且又相當不一樣的全新紙娃娃系統。

總之，還有一個月多時間去補足剩下的想要做的東西。

gameplay framework，是一位很厲害的澳門生在弄的，

所以我沒在擔心，他也很受課長寵愛XD。

不在yahoo上班，來這做遊戲，這種人滿少的。

跟老朋友交談

2009-08-31T06:13:00.000-07:00

昨天星期日，跟高中的老朋友在小萱萱店裡聊聊天。

太久沒跟他聊天了，大概有相隔4～5年吧。

因為他才剛台大研究所畢業，所以才抽一天的時間回來看我，

他隔天又要回台北的學校處理一些事情。

在我所認識的朋友裡，是第二位高名氣的學校，

第一位的話，就是大學同學，他現在在台大讀博士班，在網路上頗有名氣，

連我們製作人都有注意此人XD。

回到主題，

那天談的內容，有愛情、工作、創業，還有其他人的近況。

當他提到創業時，滿讓我驚訝的！

我所認識的所有朋友，沒人敢提想創業，很多要嘛就是考公家居多。

讓我感到驚訝的是他的家境和個性上，

我一直以為他是屬於忠厚老實型所會過的人生，真是小看他了XD

當然我也提一些關於創業的意見。這條路是很驚險的。

也希望他能夠慢慢實現自己的夢想：大型全自動管理的精緻農業工廠。

跟他聊了有快5個小時，只有這個話題滿讓我驚訝的XD。

PS：這次不聊工作，下次在聊關於物理引擎的最新突破進展吧～

一些改變

2009-08-06T06:36:00.000-07:00

最近把render engine弄到一個境界了，對於online game來說，

差不多已經是極致了，再搞下去只能做console game了XD。

剩下來就是跟美術去磨和，但是也要等到專案啟動才行。

在這之前，接受上司的命令去搞物理引擎，我當然很爽快的接下來。

這塊也是往後online game的主流，而且又有挑戰性，

趁現在年輕有體力和腦力時，盡量去搞，

以後老了，就用嘴砲寫程式XD。

規劃上，已經大致上是沒問題，比較擔心的是cloth和hair部分。

第一階段不會做到全場場景的物理運算，不過那也是最後階段。

以這款在E3 2009受到注目的遊戲為例：UNCHARTED2

其實物理引擎，並不只是增加遊戲性，還有視覺上也是。

現在只剩下我在「全力」搞新技術，其他人都有雜事在身上，

不能讓他們給失望，因為自己就是沒雜事才能作我喜歡的事情：研發。

追上今世代繪圖技術

2009-07-20T20:23:00.000-07:00

去年，也就是2008的

3D遊戲中，以HDR、動態影子、NormalMap，為三大神器。

而新世代的技術，

也就是PS3和Xbox360常用的技術：GI(Global Illumination)

也就是我今年的最後目標。

以「ソニックワールドアドベンチャー」（簡稱ソニックWA）的遊戲中，

大量使用GI技術、「放射輝度ボリューム」(Irradiance Volume)兩種。

這兩種技術，讓我滿驚訝！

因為除了逼真之外，也可以讓美術減少許多功夫。

不過這要研究的話，要花大量的時間，

因為要從底層到工具層開始打造，而且這當中有許多的技術去組合而成。

只能慢慢來（笑）

PSSM(Parallel-Split Shadow Maps)

2009-07-12T09:32:00.000-07:00

今天總算把PSSM完成了差不多了，

用了512*512的大小，就可以做出很高品質的全場景影子。

在製作的過程，遇到不少問題，

不過也因此而對shadow map有相當的認知，

以前遇到這個都會刻意避開，這演算法算是我第一次作shdow map的經驗。

現在render engine已經全面支援動態「光影」了，我想上司一定很高興XD。

接下來還剩下一個問題，就是在某一光源向量時，

shadow map會全跑掉不見。

以下是我在看的資料，有興趣者可以去看：

Parallel-Split Shadow Maps on Programmable GPUs

Parallel-Split Shadow Maps

PS：未來有時間的話，會嘗試導入VSM，也就是PSSM + VSM。

//////////2009 / 7 / 20

已經把「shadow map會全跑掉不見」的bug修正完畢了，

果然是projection matrix那邊的問題。

至於效能上，大致上會跟nvidia文件所說的，receive方面，只有terrain。

要做到receive object的話，效能上要多多考量，並不是作不到。

現在engine上，已經有靜態光影和動態光影，只要這兩種相互輔助，

在場景設計上，會有相當大的彈性。

比如：非副本的場景，只有靜態光影；反之，副本就是全方面動態光影。

重大巨變

2009-06-26T20:09:00.000-07:00

因為公司最上層的命令，導致次世代引擎要暫時終止開發，

而將主力人才放在重要的專案上。（唉～說起來很複雜）

個人估計最快大概要一年之後，最晚是明年年底才能繼續開發。

我們依造scrum的敏捷開發流程中，跑了8次sprint，

如果繼續跑下去是可以達到我們目標了，唉～可惜。

看著大陸的技術崛起，以劍俠3 OL和天驕3為例，

開始不禁擔心起台灣的水準了。

等到他們的render engine已經達到定位了，就會開始往其他方向發展了，

我們連第一步還沒踏出去，何來的下一步。

個人這幾天都在思考，自己必須要為更遠的目標而踏下第一步。

Memory leak！

2009-06-10T07:04:00.000-07:00

這幾天我的同事(JC)遇到關於記憶體的bug，

我就推薦給他這個工具去找找：Memory Validator。

這工具滿神的，可以找出哪一個物件沒有被釋放完整之外，

還可以紀錄到那一個物件總共幾個尚未被釋放。

還可以看到source code！it's good

可惜我只能拿30天去玩Orz。

工具終於快出第一版了！

2009-06-10T06:24:00.000-07:00

事隔兩個月多，第一個版本的工具要釋出了！

這是我的處女作，因為這是我第一次作工具XD。

此工具是給美術人員去使用的。

除了作一些compress texture之外，還想要作debug的功能。

就是檢查uv coordinate，還有檢查texture的size要多大才是「正確」。

不過要作debug的功能的話，必須要修改render的元件，

當然shader code也是要寫。

恩...只能慢慢來，這工具短期不需要功能完整，最基本的compress是必須的。

看看六月底能作多少算多少。

好忙呀～

2009-04-08T20:08:00.000-07:00

近一個月沒更新文章了。

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

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

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

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

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

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

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

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

尤其是大量使用normalmap的texture。

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

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

about the Graphics Memory

2009-03-15T01:48:00.000-07:00

為了掌控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

2009-03-05T07:37:00.000-08:00

前幾天看到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一樣，會跟特效放在一起。

智冠春酒晚宴

2009-03-01T06:11:00.001-08:00

真是難忘的一個晚上。

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

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

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

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

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

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

團長（最右邊）和組員：

這兩個是團長：

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

PanPan（團長）超high低：

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

抓到外星人XD：

我們的星光大道入場：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

當時我超high的XD

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

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

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

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

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

2009-02-27T06:06:00.001-08:00

因為一些原因，所以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

2009-02-20T08:45:00.000-08:00

這一個禮拜都在搞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

2009-02-11T07:21:00.000-08:00

昨天把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。

real-time shadow整合完畢

2009-02-09T06:07:00.000-08:00

由上一篇文章所提到，AGE engine的shadow是用PSSM的演算法，

並且整合到自己寫的script render pipeline。

今天總算給它完成了，因為這幾天雜事很多，

就是春酒的舞蹈的雜事，所以有些時間被佔去。

不過明天還要多測試一些，像是animation instance object和terrain。

下一個backlog就是dynamic lighting整合到自己寫的redner架構。

Screen Space Directional Occlusion (SSDO)

2009-02-08T05:14:00.000-08:00

在作SSAO的期間，突然發現到有一個論文讓我感興趣的。

也是關於Dynamic Global Illumination的論文，

算是SSAO的進皆版名叫Screen Space Directional Occlusion 。

其實在我還沒看此文章時，就覺得SSAO所增加空間的立體感之外，

但是就是少納入關於direction lighting的計算。

(有實作過SSAO的人，會發覺到這是post-pass的處理)

在光源射入某一個geometry時，某部分因為是處於半亮的狀態，

但是那部分是處於凹槽的，所以經過SSAO所計算的是全暗的，

在視覺上是一個相當不合理，尤其在配上shadow map的運算之後。

那我也不多講，其實那篇論文我還在看XD。

有興趣者請到這：Tobias Ritschel

論文：Approximating Dynamic Global Illumination in Image Space

這次沒有domo影片，有時間再來作看看。

PS：看DX10過程，被此論文給吸引XD

一年之計在於春

2009-01-31T03:58:00.000-08:00

春節9天假期即將結束，馬上又要上班了。

上班第一件事情不是處理工作事情，而是準備春酒跳舞。

因為我是舞蹈負責人兼音樂編輯者XD。

咳～回到主題，

今年的目標呀....除了工作上的backlog之外，

再來就是針對自己的能力有所提升，這樣才不會被淘汰掉。

所以還是一直想提升英文和日文能力，在閱讀文章方面是沒什麼問題，

只是在說的能力方面還是有問題（學語言最難的在於「說」）。

再來就是Direct3d 10了，為了要迎接Direct3d 11的來臨，

當然要好好接觸DX 10囉～

春節這幾天一直在看DX 10，發現到有些地方不太一樣，

光是拿掉fix pipeline這件事情，倒是滿不一樣的。

不知道台灣和大陸有多少間遊戲公司是以HLSL為主要架構的render engine，

因為fix pipeline已經被拿掉了，所以想跨到DX10必須要以此為主。

其他部分本人還在看，也還在等兩本原文書（不用錢，公司買低）。

等到摸熟DX10之後，想實作一下一些DirectX10所特有的範例，

在boost上，也希望能多多去閱讀。雖然在公司只有我在用Orz，

不過它對我的幫助滿大的，給我們工程師相當大的想像空間。

最後好好跟閃光培養感情XD。

跟她交往沒多久，所以今年請多多包涵呀～

HLSL的Text Editor

2009-01-31T03:51:00.000-08:00

如果想在visual studio之下方便撰寫shader code的話，

除了keyword可以自行定義顏色之外，

還有其他好用的功能：自動跳出keyword(像C#)。

請到這網站下載： InteliShade

如果想要衍生出其他副檔名的話(*.fx 或*.hlsl ....等)，

請到他的論壇：InteliShade forums

整合real-time shadow

2009-01-22T20:48:00.000-08:00

最近render engine工作，是要把real-time shadow整合到

script render pipeline，也就是利用script去描述出來。

我們是採shadowmap的技術，不過詳細作法會有不一點，

有興趣者，可以去參考此資料：Parallel Split Shadow Map

將它script化的過程是沒什麼很大的困難點，

只是要多加一些機制，讓往後出現的需求更加的有彈性，

在real-time shadow的技術，我們大致上是不會更加的去鑽研。

最近也買了vista正版（隨機版），花了4千2 ....。

也體會到人人所講的不穩定。我玩crysis時，會常常當機，

在XP相當穩定，後來今早升級到SP1，結果不能上網...。

唉～下午就請個特休去把這問題搞好，不然我無心上班。

這幾天發生的事情...

2009-01-14T08:00:00.000-08:00

這幾天跟因課長理念不同，而產生衝突。

也看清台灣的研發極限（賺最多錢的公司）。

課長的名句：只有好的產品才會賣錢，沒有好的技術會賣錢。

我不太百分百認同此句，沒有技術的支援，怎會有好產品呢？

不要說晶圓技術，造福許多新產品以及開闊新市場，

說說從以前的遊戲到現在，

我唯一所感想的是：此技術是否被市場所接受。

從任天堂到will，還有ps到ps3，技術每年都會提高，

但是市場的接受程度並不一定會跟著提高，也許會被淘汰，

也許只是時機未到。

所以技術提升的價值，來至於開闊未來市場的一個契機。

DVD光碟，從以前不被看好，結果現在呢？都已經再推藍光了。

說了這些，重點在於公司環境不想推高技術，

只想完全專注現有的市場。這對我們engine部門相當大的殺傷力，

我看直接買unreal3還比較快，別開發engine了，一切都以專案為主。

唉～現在只能羨慕韓國的遊戲產業，他們真的很有野心也敢衝，

不過他們背後有強大的財力XD。

我在公司也開始停止技術發展了，一切都配合專案。

其實這樣有好處：我的工作量減少許多XD。

我有很多時間慢慢磨，多餘的時間去看看其他東西，

慢慢給自己一個進修的空間。（好久沒看C++內功心法了）

或許以後會慢慢轉到game play那邊，

其實我滿想作WOW的命令巨集功能。

敗家一下

2009-01-12T06:07:00.000-08:00

在公司1多年，今天剛好可以領滿一年的年終，

也領了不少錢，所以想敗一下家XD。

昨晚跟閃光一起買螢幕，結果是選22吋的，總共4990。

現在在家中跟公司一樣使用雙螢幕，

而且都是神卡階級，差別在於公司是ATI的卡，家中是Nvidia。

在過一陣子打算再買vista家用進階版5千左右，

可能還會再買更大的硬碟。

會買vista的原因，在於年底directX 11的問世，

所以會先摸一下directX 10.0和10.1。

先瞭解一下新的技術，然後未來要踏上directX 11時，

會比較順利點。公司部分，要等到專案差不多時候，

我才會有多餘的時間去裝商業版的vista。

到時候後... AGE Engine的Render Engine部分，

再由我再次打造起來，專屬於DirectX 11，

好讓玩家能夠發揮顯示卡的威能。

終於完成了....物件導向

2009-01-07T00:33:00.000-08:00

剛放完元旦連續假期之後，整個人進入備戰一樣，開始趕shader物件導向。

今天終於給它趕完並且測試完畢，感覺上....滿順利似的XD

這機制的優點有：

1.有效提昇效率。(shader lod)
2.geometry綁的material相當有彈性。
3.管理顯示卡型號和廠商。
4.有彈性地支援特殊的技術。
5.post-pass和pre-pass更佳有彈性。

我就詳細說一下吧～

第一：

物件比較近的話，就執行比較優質的material；

物件離cmaera愈來愈遠時，

則會慢慢愈來愈劣質(fix material或是shader model 1.0)。

第二：

跟lod不一樣的是...他是一種特化方式。

雖然是特化，不過也還是有lod的表現。

如：開啟shadow，並且跟第一點一樣的特性(lod)，

或則當人物碰到某一個物件時，馬上變成透明。

第三：

這點我想是每個遊戲公司很頭痛的事情，

尤其是負責Render Engine的engineerXD。

比如：要管理某張卡某個型號不能跑哪一種material，

或者某張卡某個型號跑此material時，要特別去「特化」。

所以很多遊戲廠商都直接定最低的顯示卡型號，

然後某某張卡不能跑此遊戲。（在console game常常看到）

但是在online game就不能這樣做了！

假如公司想開闊越南市場，如果去設定最低顯示卡為shader model 2.0，

保證會失去許多玩家，自然所賺的錢也會變少。

第四：

一個簡單例子：ATI的Tessellation技術。

（只有ATI的卡才能跑且需要ATI HD 2000以上的型號）

第五：

我負責的Render Engine，

他可以全支援所有關於post-process的shader。

(HDR或DOF還有SSAO....等)

但是有些物件特別奇怪（透明或alphatest），

除了可以完整的呈現出來之外，

還可以針對某些物件不需要納入post-process的運算，以提昇效率。

就這以上...。

這樣就結束了？

回頭看一下自己的backlog.....，恩...還早的很XD。

雖然以現有的機制，可以做出很可怕的東西，

不過課長是很貪心低（小聲說）

當然我也想趕快把架構給作大起來，趁現在還在開發中的時期，

等到專案啟動時，可能會很少去動架構了，必須要跟美術去磨合XD。

希望台灣的研發能量能上升

2009-01-04T02:28:00.000-08:00

我會這樣說是基於課長的一些想法，且也讓我滿認同的。

事由是在於81 keys的正式公測。

這款遊戲我有玩第一次封測，感覺上滿不錯的遊戲，

有些設定滿值得參考與學習。

重點在於：希望上層能重視研發單位。

程式有分兩大種：engine和game play。

網龍是買Unreal2引擎，所以他們工程師可以專心於遊戲製作。

我們公司是由新加坡老外所開發的Typhoon引擎(google找不到低)

是跟81 kyes一樣，是從無到有去打造的，

不過不同的是我們是藉由老外之手，另一個是完全由國人去打造。

不管怎樣，其實我們由衷希望81 keys能成功XD，

雖然是敵對的公司，不過台灣遊戲產業很小，

所以對我來說只是良性競爭。

自己心中也希望台灣的研發能量能夠慢慢提升上去。

買別人的引擎，

有個致命缺點：無法即時去磨合online game市場需求。

而自行研發的話，就可以隨時去磨合。

比如：在Render Engine支援DirectX 10或10.1。

支援ATI或Nvidia的某種技術。

簡單說就是：高技術和高靈活。

高技術不完全等於顯示卡的配備要很好，

而是讓顯示卡充分發揮威力。

可惜DirectX10.0或10.1在歐洲推的很順，

我覺得關鍵點在於綁在Vista，不然我真的很想丟棄DirectX 9.0。

所以我只能期待DirectX 11。

回到主題....，

現在最怕一種現象，上層只專注「賺錢」，

只要能賺錢，我不管過程怎樣。

如果買Engine能夠比較快賺錢（大量出產遊戲的方式），

那麼上層會認為不需要開發Engine的需要。

那這樣....我可能會往國外跑XD。

台灣人才往外跑，因為不受到重視Orz。

所以課長最後提出：技術固然重要，但是遊戲製作也要考量。

雖然我對遊戲製作沒什麼感興趣（就交給企劃和game play人員），

不過能夠將此「技術」大量運用在市場上，才是我接下來的考驗。

所以才有shader物件導向的機制產生。

墾丁三日遊(第二、三天)

2009-01-04T01:29:00.000-08:00

第二天起來，大概已經9點多了，準備一下出門。

首先到我們民宿對面的船帆石逛逛，

發覺到...船帆石不能夠游泳戲水，因為浪打上海灘會有小石頭。

所以那邊只能玩沙灘車，或採採海灘。

我跟閃光想挑戰「摸船帆石」的舉動，

結果...因為中間有個大溝，所以...最多只到達這邊。

之後，開始騎車往北行動，沿途有看到墾丁大街、南灣，

還有夏都（海角七號）。

我們到達恆春的地方去吃吃有名的小杜包子。

為了吃著包子，等了快一個小時，還好有NDS加持XD。

小杜包子有個特色：包子出爐時，會唱歌並且噴出氣泡。

包子的話....，閃光覺得起士包子比較好吃，其他滿一般的。

吃完中餐之後，順路到南灣看看，有看到幾位老外在那邊。

那邊的海灘真的是可以戲水遊玩，海灘上也沒有小石頭。

下午就在民宿休息一下，晚上就出去夜遊，目標是龍盤！

結果當天風過大且下雨，又一片漆黑...，連我騎車都很不安＠＠。

因為龍盤那邊很寬廣，沒有什麼樹有遮掩，而且也沒路燈。

所以...打消夜遊的念頭，直接到墾丁夜市去吃晚餐，

也順便買個名產回家孝敬父母。

最後...回到民宿休息XD

第三天，就是回高雄的時間了。

這次旅遊，雖然沒逛許多景點，但是重點是在於身邊的人，地方是其次。

不過玩的也滿高興的，那個龍盤....真是可怕，必須要有四輪才能過去。

墾丁三日遊(第一天)

2009-01-04T01:07:00.000-08:00

跨年的第一天，就跟閃光一起到高雄火車站坐高雄客運，

準備出發到墾丁。上車前，先吃一下暈車藥。

本來預定上車後要玩NDS，結果...暈車（想兔）XD。

到了墾丁之後，發現到離船帆石還有一段距離，且附近沒有租車。

最後跟閃光走了快3公里的路Orz，路途中看著別人騎摩托車和四輪車，

對閃光說：抱歉～讓妳陪我吃苦。

閃光：沒關係呀～只要以後對我好就行了。

讓我很感動> /// <

終於...看到一顆大大的石頭，那顆就是傳說中的船帆石。

也找到「金華海岸」的民宿，看出去就是海。

休息一陣子之後，馬上跟老闆娘租摩托車，

然後往南邊去前進....。

首先看到鵝鑾鼻的燈塔，可惜我找不道路進去QQ

最後找到最南點的石盃（我沒有到此一尿喔XD）

然後就去尋找看星星的龍磐，結果風太大了，而且也在飄雨，

所以就打消念頭。

往回騎之後，也下午五點多了，晚餐就到smokey joe's去吃，

沒想到墾丁也有呀...（高雄也有一家）

吃完之後，騎車逛一下墾丁夜市，然後直接回到民宿休息。

第一天晚上本來想夜遊的，但是太冷又太累，所以留到隔天...。

終於確定次代 Game Engine名稱了！

2008-12-28T23:07:00.000-08:00

名稱為：時代引擎(AGE Engine)。

時代引擎是：一個遊戲引擎(The AGE Engine is A Game Engine)

它是取A Game Engine的頭一個縮寫字。

其實其中含意，對我來說沒多大的感覺。

只是他的「時代」，對我來說比較有Fu。

因為希望在我們團隊努力之下，希望能跟著時代趨勢去走。

接下來是Engine log圖XD？

大學專題作品

2008-12-26T02:05:00.000-08:00

這是我大學專題作的作品：得第三名。

影片內容都是兩個AI在對打。

順便測試上傳影音。

新架構、新機制

2008-12-24T20:44:00.000-08:00

最近在做shader code的物件導向機制。

聽說此機制在shader model 5.0(DirectX 11)會有此，

不過我等不了這麼久，所以自己親自來實作。

我覺得繼script render pipeline機制之後，

又是另一個可怕機制。

在規劃過程相當順利，只是要向下相容舊有機制，

會有點小麻煩＝＝。

物件導向的機制，除了解決對應顯示卡廠商和底下顯示卡型號的管理之外，

LOD上的管理，Geometry可以做出相當多變化的material(run-time過程)。

恩...他是個可怕的怪物XD。（還可以支援Fix pipeline，支援低階卡）

WOW在畫面上並沒有特別凸顯，但是在架構上相當彈性以及多變化性，

ogre Engine也有此表現，這是我一直相當嚮往。

Scrum

2008-12-17T16:51:00.000-08:00

因為PanPan的加入（澳門生），得知他們公司有個專案管理模式：Scrum。

然後我們引擎部門也試著此方式來進行專案控管。

今天是屬於product backlog的進度，

開了相當久的會議，為了把我們次代引擎的backlog給列出來。

雖然我們還沒正式定名此Engine的名字，

不過光看這些backlog....，靠～好棒好強大！

當然要先從最有價值最重要的backlog先做起，

不然要整個實作出來要花個幾年的時間吧～

此Engine並不是從無開始打造，而是既有的Game Engine為基底開始修改。

所以我們團隊只要針對功能擴充就行了，

當然這些backlog有符合現有以及未來的online game市場去打造的。

這個Engine的特性，讓我覺得有：高技術、高市場、高靈活的存在性。

高技術是指隨著歐美的主流技術流動，

高市場是指可從低到高階的顯示卡配備都可support到。

高靈活是指出產的遊戲相當有變化性，

並不會讓玩家覺得又是一款換湯不換藥的遊戲。

Screen Space Ambient Occlusion

2008-11-16T12:01:00.000-08:00

已經調整到不是針對某些模組，

而是整個遊戲場景的物件，

不管是極大的物件和極小的物件，都有相當棒的AO效果。

為了調這個參數，還複習一下微積分的東西。對了，只有sample 8次而已。

但是還少一些因素還沒實作出來。針對Crysis的SSAO作實驗性的測試，

也讓我察覺到Crysis的SSAO運算的可怕之處！。

那個部分就是加強物體與物體之間距離的AO比例，

並不是單純只算物體與物體之間的連接縫！這點是一般人所忽略的。

因為那部分必須在run-time的過程中，才發覺到此變化的。

假設第一張圖那樣，那個茶壺和「甜甜圈」之間的會有相當深的Occlusion。

但是我這邊並沒有表現的相當亮眼。

別小看這個因素，因為這個因素會讓人覺得說：喔！這是SSAO耶～

最後一張，我加強Occlusion的強度

08/12/29：

更新了一些算式，

並且新增blur效果，是8*8的blur，範圍1.5的pixel size。

最後影片為：

雖然只是擺放幾個物件而已，

不過這效果已經很逼近StarCraftII所呈現的SSAO，

會這樣說是基於在遊戲上有實際去執行過並且所呈現出的結果。

09/01/05：

只計算SSAO

8 * 1 的sample，blur為 15 * 15

先看看nvidia的一個範例影片：Dynamic Ambient Occlusion

再來看看我的部分：

感覺上跟真正的AO還是有一段距離XD。

因為低模組的關係，計算AO的結果無法相當有smooth，

所以可以利用NormalMap來解決此問題：

寫過normalmap的人都瞭解，當geometry是處於「背光」的話，

所呈現出來的凹凸平面相當不明顯，

那我利用SSAO特性來將此缺點給改進過來。

在我寫的Render Engine中，

都可以同時呈現「非normalmap」和「normalmap」的geometry。

09/2/14

最近終於把Terrain的normal給它「正確」運算到，

所以把自己寫的SSAO給放上去。這次的SSAO有點一不一樣，

從上面的影片和圖片看來，只要沒有Occlusion到都是白色，

現在為了在視覺效應上，所以不會是全白色的。這樣的對比不會太強烈，

因為太強烈的話，會讓人覺得說這邊太黑了。

有玩過crysis的編輯器的話，他的terrain跟我運算的結果差不多，

有興趣者，去下載crysis的demo，裡面有附編輯器。

運算上還是一樣，sample 8，1/2 render target，15 * 15 blur，

並且打霧和fake HDR。

第一張：只是單純的diffuse color。

第二章：diffuse color 和 SSAO。

我算的SSAO，其實運算量很少，沒雙迴圈，沒flow control，

在nvida 8400去跑，也沒什麼拖到，主要還是cpu的瓶頸。

所以在scene manage上，我必須要多多做優化。

我有一個測試報告，請看此文章：優化pre-pass和post-pass

最後，此文章不再次更新了，因為有一些原因的關係，

所以就期待產品的推出XD。