開發這個3D engine已經兩年半了,從06年8月剛開始統計的4萬多行，到今年7月份的21萬多行,有一些感慨,感覺有那麼點成就感,不過更多的是惴惴之 心:這些代碼可以很好的在一起工作嗎,足夠快嗎?bug肯定不少,因為測試的強度畢竟不高,這還不是最重要,架構上會不會有致命的疏忽的地方？會不會在未 知的需求面前不堪一擊?前些日子看了看兩年前寫的代碼,覺得不滿意的地方很多,代碼寫出來的一瞬間就開始貶值,兩年多時間,也的確該貶得差不多了,有心要 重寫,似乎又沒多少時間,接下來還有很多事情要做,而自由寬鬆的開發環境不是能永遠維持下去的.還有一些擔心:我是否真的儘力了呢?完成這些功能,是否真 的需要這麼長時間呢?它們是否真的有價值呢?不仔細回憶,都有點想不起來一年前都幹了些什麼.虛度光陰?有這個可能--往消極的一面想,還真能想出不少東 西.不過要積極點呢,也有不少值得欣慰的地方,兩年來至少學到了不少東西,對3D圖形方面的經驗有了些積累,不像兩年前那麼生疏了,指令碼也接觸了一些,編 輯器寫得更熟練了,外觀也更漂亮了(這個很關鍵,寫程式不就是為了寫點好看的東西嗎?),模板也用得比以前熟練多了,有些問題的解決方案自己也挺滿 意...二十多萬行垃圾代碼裡,居然也有那麼些閃光點,若隱若現,叫人安慰.
所以我打算從這個炎熱的夏天開始,關於這個engine寫點什麼,一來可以留作紀念,二來可以整理下思路,並做將來的備忘,三來可以把自己的一些想法公布 出來,用以交流,不敢說高台教化,起碼是勸人向善,教人學好(呵呵,怎麼和郭德綱一個口風),如果能有人看到這些東西,受到些啟發,也是很好的事.
先從最基礎的寫起吧,關於Device的渲染流程.
D3D9的Device就是D3D給我們提供的一個繪製3D圖形的工具,它的繪製流程大致是這樣的:
*.首先Device的使用者要準備好頂點資料,也就是一個頂點的數組,稱為A
*.然後這個數組A被傳入device的渲染管線
*.device內部依次對每個頂點進行處理,有兩種模式,固定管線和shader模式,所謂固定管線就是device內部實現的一個固定的程 序,使用者只能通過設定各種參數(一些RenderState)來控制它,當然這不夠靈活,所以有了shader模式,也就是說,使用者需要寫一個程式片段 (所謂vertex shader),傳給device,然後device使用這個片段對每個頂點進行處理.這個程式片段是在顯卡上執行的.
*.傳入的頂點數組A的每一個元素被轉換後,儲存到另一個數組B中.數組B中的每個元素必須至少包含一個透視空間的位置,用來做裁剪.
*.數組B被傳入到device的下一個計算階段,在這個階段裡,數組B中的(被轉換過的)頂點被組織成一個個三角形,然後對這些三角形進行裁 剪(利用頂點資料裡包含的那一個透視空間的位置),背面剔除(注意背面剔除和頂點的法線是沒關係的),最後剩下的三角形被儲存到一個數組C中.(注意在這 個階段裡頂點數組變成了三角形數組)
*.數組C被傳入到下一個計算階段,光柵化,對於數組C中每一個三角形,首先把它們從透視空間映射到螢幕空間,然後找出它們在螢幕上覆蓋的像素 (一個三角形覆蓋的像素的數量有可能是很多的),對於每一個像素,根據它在三角形中的位置,通過三角形的頂點進行線性插值,計算出一個像素資料(注意像素 資料是通過三角形的頂點資料插值而來,所以它們的資料類型是一致的),所有三角形算出來的像素資料最後被儲存到一個數組D中.(在這個階段裡,三角形的數 組變成了像素資料數組)
*.數組D被傳入到下一個計算階段,在這個階段裡,device會對這些像素做一些初步的過濾,主要是進行stencil test(根據stencil
buffer上的值)和z-test(根據這個像素的Z值和z-buffer上的值進行比較),根據測試結果會對stencil buffer進行一些修改(使用一組render state來控制這個過程),通過這些test的像素被儲存到數組E.
*.數組E被傳入到下一個計算階段,在這個階段裡,device對每個像素資料進行處理,這個階段也有兩種模式,固定管線和shader模式, 與頂點處理階段類似,使用者也可以寫一個程式片段,來對每一個像素資料進行處理,稱為pixel shader.像素資料可能包含各種類型的資料,但經過這一階段的處理後,輸出是很簡單的,一般就是一個顏色值和一個alpha值(透明度),也可以輸出 一個Z值,不過好像不常用.在pixel shader裡還可以使用專門的指令來放棄某一個像素的後續處理.所有的像素資料被處理後,結果存在一個數組F中.
*.數組F進入下一個階段,在這一個階段裡,進行alpha test(根據像素的alpha 值),alpha test是最後一個test了,通過了alpha test的像素可以保證繪製到螢幕上去,通過test的像素會把它們的z值更新到z-buffer中去(具體由一組render state控制),通過test的像素被存入數組G
*.數組G進入下一個階段,在這個階段裡,主要是把數組G裡的像素和螢幕上已有的像素進行混合,具體混合的方式有多種多樣,由一系列render state進行控制.混合以後的像素就被"畫"到螢幕上了
基本上的流程就是這樣了,環節很多,每個環節也有很多技巧,很多需要注意的地方,太多了，就不鋪開來寫了,我覺得這個流程很重要,雖然理解起來 並不困難,但真的能夠非常熟練的記住它,並且運用其中的各個環節來解決實際的問題就不是那麼容易的事了.所以不厭其煩的又把它粗粗的寫了一遍,希望自己也 能進一步加深印象.
最近正在寫關於多線程渲染的代碼,下一回可能寫寫這方面的東西.
謝謝樓下的評論糾正了我的一個錯誤,stencil test和depth test的確是在pixel shader後才進行的,雖然這看上去沒什麼道理, 不過標準的渲染應該是這樣的流程,但好像某些顯卡會在pixelshader前做一些早期的test（early-z和early-stencil)來提高效能,我希望這樣的顯卡越多越好.看來我要去重新check一下引擎中使用stencil buffer提高效能的地方了,不過好像當時的測試的確是提高了一些效能的.
原文地址：http://www.cnblogs.com/ixnehc/archive/2008/09/02/1282350.html
