名稱為：時代引擎(AGE Engine)。
時代引擎是：一個遊戲引擎(The AGE Engine is A Game Engine)
它是取A Game Engine的頭一個縮寫字。
其實其中含意，對我來說沒多大的感覺。
只是他的「時代」，對我來說比較有Fu。
因為希望在我們團隊努力之下，希望能跟著時代趨勢去走。
接下來是Engine log圖XD？
FastScene
1 週前
2008年12月28日 星期日
2008年12月24日 星期三
新架構、新機制
最近在做shader code的物件導向機制。
聽說此機制在shader model 5.0(DirectX 11)會有此，
不過我等不了這麼久，所以自己親自來實作。
我覺得繼script render pipeline機制之後，
又是另一個可怕機制。
在規劃過程相當順利，只是要向下相容舊有機制，
會有點小麻煩＝ ＝。
物件導向的機制，除了解決對應顯示卡廠商和底下顯示卡型號的管理之外，
LOD上的管理，Geometry可以做出相當多變化的material(run-time過程)。
恩...他是個可怕的怪物XD。（還可以支援Fix pipeline，支援低階卡）
WOW在畫面上並沒有特別凸顯，但是在架構上相當彈性以及多變化性，
ogre Engine也有此表現，這是我一直相當嚮往。
聽說此機制在shader model 5.0(DirectX 11)會有此，
不過我等不了這麼久，所以自己親自來實作。
我覺得繼script render pipeline機制之後，
又是另一個可怕機制。
在規劃過程相當順利，只是要向下相容舊有機制，
會有點小麻煩＝ ＝。
物件導向的機制，除了解決對應顯示卡廠商和底下顯示卡型號的管理之外，
LOD上的管理，Geometry可以做出相當多變化的material(run-time過程)。
恩...他是個可怕的怪物XD。（還可以支援Fix pipeline，支援低階卡）
WOW在畫面上並沒有特別凸顯，但是在架構上相當彈性以及多變化性，
ogre Engine也有此表現，這是我一直相當嚮往。
2008年12月17日 星期三
Scrum
因為PanPan的加入（澳門生），得知他們公司有個專案管理模式：Scrum。
然後我們引擎部門也試著此方式來進行專案控管。
今天是屬於product backlog的進度，
開了相當久的會議，為了把我們次代引擎的backlog給列出來。
雖然我們還沒正式定名此Engine的名字，
不過光看這些backlog....，靠～好棒好強大！
當然要先從最有價值最重要的backlog先做起，
不然要整個實作出來要花個幾年的時間吧～
此Engine並不是從無開始打造，而是既有的Game Engine為基底開始修改。
所以我們團隊只要針對功能擴充就行了，
當然這些backlog有符合現有以及未來的online game市場去打造的。
這個Engine的特性，讓我覺得有：高技術、高市場、高靈活的存在性。
高技術是指隨著歐美的主流技術流動，
高市場是指可從低到高階的顯示卡配備都可support到。
高靈活是指出產的遊戲相當有變化性，
並不會讓玩家覺得又是一款換湯不換藥的遊戲。
然後我們引擎部門也試著此方式來進行專案控管。
今天是屬於product backlog的進度，
開了相當久的會議，為了把我們次代引擎的backlog給列出來。
雖然我們還沒正式定名此Engine的名字，
不過光看這些backlog....，靠～好棒好強大！
當然要先從最有價值最重要的backlog先做起，
不然要整個實作出來要花個幾年的時間吧～
此Engine並不是從無開始打造，而是既有的Game Engine為基底開始修改。
所以我們團隊只要針對功能擴充就行了，
當然這些backlog有符合現有以及未來的online game市場去打造的。
這個Engine的特性，讓我覺得有：高技術、高市場、高靈活的存在性。
高技術是指隨著歐美的主流技術流動，
高市場是指可從低到高階的顯示卡配備都可support到。
高靈活是指出產的遊戲相當有變化性，
並不會讓玩家覺得又是一款換湯不換藥的遊戲。
2008年11月16日 星期日
Screen Space Ambient Occlusion
已經調整到不是針對某些模組，
而是整個遊戲場景的物件，
不管是極大的物件和極小的物件，都有相當棒的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。
而是整個遊戲場景的物件，
不管是極大的物件和極小的物件，都有相當棒的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上，我必須要多多做優化。
最後，此文章不再次更新了，因為有一些原因的關係，
所以就期待產品的推出XD。
訂閱：
文章 (Atom)
發表文章
