圖形子系統(tǒng)是渲染層中圖形相關(guān)子系統(tǒng)的最高層. 它基本上是Mangalore圖形子系統(tǒng)的下一個版本, 但是現(xiàn)在整合進(jìn)了Nebula, 并且與低層的渲染代碼結(jié)合得更加緊密. 最基本的思想是實(shí)現(xiàn)一個完全自治的圖形”世界”, 它包含模型, 燈光, 還有攝像機(jī)實(shí)體, 而且只需要與外部世界進(jìn)行最少的通信. 圖形世界的最主要操作是加入和刪除實(shí)體, 還有更新它們的位置.
因?yàn)镸angalore的圖形子系統(tǒng)跟Nebula2的完全分界線從Nebula3中移除了, 很多設(shè)想都可以用更少的代碼和交互來實(shí)現(xiàn).
圖形子系統(tǒng)也會為了異步渲染而多線程化, 它和所有的底層渲染子系統(tǒng)都會生存在它們自己的fat-thread中. 這本應(yīng)是Nebula3層次結(jié)構(gòu)中更高級的東西, 但是我選擇了這個位置, 因?yàn)檫@是游戲跟渲染相關(guān)通信最少的一部分代碼. 正是因?yàn)閳D形代碼有了更多的”自治權(quán)”, 游戲相關(guān)的代碼可以跟圖形以完全不同的幀率來運(yùn)行, 不過這需要實(shí)踐來證明一下. 但是我一定會嘗試, 因?yàn)橥耆珱]有必要讓游戲邏輯代碼運(yùn)行在10幀以上(格斗游戲迷們可能會反對吧).
圖形子系統(tǒng)中最重要的公有類有:
- ModelEntity
- CameraEntity
- LightEntity
- Stage
- View
一個ModelEnity表示了一個可見的圖形對象, 它包括位置, 包圍體和內(nèi)嵌的Model資源. 一個Model資源是一個完全的3D模型, 包括幾何體, 材質(zhì), 動畫, 層級變換等…(后面會提到).
一個CameraEntity描述了圖形世界中的一個視景體, 為渲染提供View和Project矩陣.
一個LightEntity描述了一個動態(tài)光源. Nebula3的光源屬性還沒有最終確定, 但是我的目標(biāo)是一個相對靈活地近似(最后一個光源不會超過幾個shader參數(shù)).
Stage和View是Nebula3圖形子系統(tǒng)新增的內(nèi)容. 在Mangalore中, 圖形實(shí)體是生存在一個單獨(dú)的圖形Level類里, 任何時候只能有一個Level和一個攝像機(jī). 這對于只需要渲染一個世界到幀緩存(frame buffer)的情況來說還是不錯的. 但許多游戲程序需要更復(fù)雜的渲染, 如在GUI中渲染一個使用單獨(dú)燈光的3D對象, 而它又跟其它的圖形世界是隔離的. 還有反射或像監(jiān)視器之類的東西都需要一個額外的視口, 諸如此類. 在Mangalore中, 這個問題通過OffscreenRenderer類得到解決, 雖說比較容易使用, 但是具有一些使用限制并且需要更多事后的思考.
Nebula3提供了一個基于State和View的更加簡潔的解決方案. 一個Stage就是一個圖形實(shí)體的容器, 表示一個圖形世界. 同一時間可能存在多個Stage, 但是它們之間是互相隔絕的. 每個實(shí)體在一個時刻只連接到了一個Stage(雖說克隆一個已有實(shí)體是一件很簡單的事情). 除了簡單地把實(shí)體組織到一起外, Stage的主要工作是根據(jù)它們之間的關(guān)系來加速可見性查詢. 應(yīng)用程序可以派生Stage的子類來實(shí)現(xiàn)完全不同的可見性查詢方案.
一個View對象通過一個CameraEnity渲染stage到一個RenderTarget. 任何stage都可以連接任意數(shù)量的View對象. View對象可能會互相依賴(也可能是連接到不同stage的View), 所以更新一個View會首先強(qiáng)制更新另一個View的RenderTarget(這在一個View渲染需要使用另一個View的RenderTarget做為紋理時很方便). View對象完全實(shí)現(xiàn)了自己的渲染循環(huán). 應(yīng)用程序可以在View的子類中方便地實(shí)現(xiàn)它自己的渲染策略(如每個light一個pass VS 每個pass多個light, 渲染到cubemap, 等等).
總而言之, 一個Stage完全控制了可見性查詢流程, 而一個View則完全控制了渲染流程.
圖形子系統(tǒng)的一個最主要的工作就是根據(jù)可見性查詢的結(jié)果來決定哪些實(shí)體需要被渲染. 一個可見性查詢在實(shí)體間建立了一個雙向的鏈接, 它有兩種形式: 攝像機(jī)鏈接和燈光鏈接. 攝像機(jī)鏈接把一個攝像機(jī)和在它視景體內(nèi)的模型連接到了一起. 因?yàn)殒溄邮请p向的, 所以攝像機(jī)知道所有的在它視景體范圍內(nèi)的模型, 而模型也知道所有可以看到它的攝像機(jī). 燈光鏈接在燈光與模型之間建立了相似的關(guān)系, 一個燈光具有所有受它影響的模型的鏈接, 一個模型也知道所有影響它的燈光.
加速可見性查詢最重要的類就是Cell類. 一個Cell是一個圖形實(shí)體和子Cell的可見性容器, 它必須遵循2條簡單的規(guī)則:
- 如果一個Cell是完全可見的, 那么它所有的圖形實(shí)體和子Cell都必須可見.
- 如果一個Cell是完全不可見的, 那么它所有的圖形實(shí)體和子Cell都必須不可見.
Cell是附屬于Stage的, 它們形成了一棵有根Cell的樹形層次結(jié)構(gòu). 標(biāo)準(zhǔn)的Cell支持簡單的空間劃分方案, 如四叉樹和八叉樹, 但如果像其它的可見性方案, 如portal, 就需要派生Cell的子類來實(shí)現(xiàn)了. 子類唯一的功能限制就是上面標(biāo)出的那兩條規(guī)則.
當(dāng)一個圖形體連接到一個Stage時, 它會被插入”接受” (通常僅僅是容納)它的最低級的Cell中. 當(dāng)更新圖形實(shí)體的變換信息或改變包圍體時, 它會根據(jù)需要改變在Cell層次中的位置.
Stage居住在StageBuilder類當(dāng)中, 應(yīng)用程序應(yīng)當(dāng)派生StageBuilder來創(chuàng)建一個Stage的初始狀態(tài)(通過加入Cell和實(shí)體). Nebula3會提供一些標(biāo)準(zhǔn)的StageBuilder集合, 這應(yīng)該能夠滿足大多數(shù)應(yīng)用程序的需要了.
這只是圖形子系統(tǒng)的一個粗略的概述. 因?yàn)楫?dāng)前只有一個最基本的實(shí)現(xiàn), 很多細(xì)節(jié)接下來可能會有所更改.