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