Posted on 2008-12-14 20:46
Condor 閱讀(3492)
評論(2) 編輯 收藏 引用
最近拿到SpeedTree資料,開始學習,并用到項目里去.
1. 該插件的特點:
api無關。它本身只是數據結構和邏輯架構,沒有任何渲染語句子,因此為了把它應用到自己的引擎里,需要為之添加渲染相關的語句。而根據sdk的講解,推薦用戶為之搭建中間架構,用來聯系SPEEDTREE與自己的引擎。這樣做起碼有兩點好處,搭建的中間架構(也推薦別加任何api相關的語句),因此,即使你以后換了api(譬如從gl換成dx),中間架構還是可以繼續沿用的。還有一個好處就是,當speedtree更新版本的時候,你也無須修改你的引擎,而只需要修改相對簡單而且穩定的中間架構。
2. 該插件的具體特性:
注意,下面具體特性分析都是基于SDK里一個叫“DirectX9”的例子進行的,在這個例子里,它給出了最基本的使用方法,同時也向用戶展示了它的基本特性。
A. 樹的基本渲染
通過大場景的測試,DP的個數大致是樹木棵數的兩到三倍。詳細分析下,發現
它一棵樹分三部分繪制:樹干和大樹枝(branches),小樹枝(fronds),樹葉(leaves)
Branches:使用模型來繪制
Fronds:使用兩個十字交叉的面模擬小樹枝,為了節省三角形。
Leaves:使用billboard方式繪制,這樣就能產生視覺效果比較好的葉子了。
它這樣劃分是出于以下三方面的考慮:這幾部分的渲染狀態不一樣,動畫的狀態不一樣,做LOD的時候也不一樣。具體看下面的介紹。
B. 樹的陰影系統
它包括兩方面的陰影。首先是樹干上的陰影。其次是整棵樹在地面的投影。
樹干的自陰影(self shadow)是預先生成的,至于生成的算法,可能是可以根據可穿透的光線跟蹤,也可能是結合shadow map的逐象素地生成光照貼圖(把樹干的面都展開后,在對應的地方畫上陰影).有了該光照貼圖,那渲染樹干的時候就可以跟樹干本身的紋理進行混合產生比較真實的效果。
而整棵樹在地面的透影子,則是使用一個矩形畫出來的,陰影貼圖也是預先生成好。渲染的時候浮在地面。
C. 樹的動畫
樹的三部分的動畫狀態都是不一樣的。這對優化有極其重要的作用。風小的時候,或是樹離眼睛比較遠的時候,可以不動樹枝,而只是動樹葉。而具體他們是怎么動的:
樹葉的動畫:就是一個billboard的來回平移以及他本身繞視坐標系統Z軸的轉動。
樹枝的動畫:通過它引擎本身計算出來的矩陣進行動畫。
而至于它具體怎么渲染動畫的,它提供了基于CPU和GPU的方法。
基于CPU的方法是:創建頂點緩沖的時候, 使用D3DUSAGE_DYNAMIC | D3DUSAGE_WRITEONLY標記(這種方法能提高CPU修改和更新該緩沖的速度),渲染的時候實時更新頂點位置。
基于GPU的方法是:通過自定義的頂點shader程序進行,更新動畫的時候,向shader傳遞常量數組。
D. 樹的光照
它可以打開和關閉實時光照,對于實時光照,樹干部分又分兩種情況,對于沒有法線貼圖的樹干,使用per-vertex的光照。而對于有法線貼圖的,則使用per-pixcel光照。至于給不給樹干渲染法線貼圖,則根據具體的程序決定。
而對于樹葉的渲染,因為它是一個billboard,因此也無法通過其法線來計算光照。它其實是根據這個 billboard的位置來確定其亮度的。通過把整棵樹當成一個球來分析,而每個billboard的位置就相當于是球上的一點,結合光的方向,計算出該點的亮度。
E. LOD的特點
其強大的LOD系統,為實現大規模的場景提供了有力的支持。這里的LOD分三方面:頂點的LOD,紋理的LOD,動畫的LOD。
(1) 頂點的LOD:首先是針對樹干,因為這里的樹干是實實在在的模型。至于樹干的建立,它里面是采用貝塞爾曲線來描述整個mesh的,貝塞爾曲線的描述方式無疑給即時高效率的LOD計算提供了可行性。同時這還針對樹枝,遠了之后,小樹枝就不渲染了。到了一定的距離的時候,整棵樹其實就變成一個billboard了。
(2) 紋理的LOD:樹干上在最高精度的時候會有三套紋理:基本紋理,光照貼圖,法線貼圖。隨著LOD的進行,可以依次減去法線貼圖,光照貼圖,最后是本身貼圖,最后只為樹干渲染一種顏色。
(3) 動畫的LOD:現在有三種動畫,大樹枝(模型)的動畫,小樹枝(兩個交叉面)的動畫,以及樹葉的動畫。隨著LOD的進行,依次去掉大樹桿的動畫,小樹桿的動畫,最后是樹葉的動畫。這也是符合視覺效果的。
F. 文件系統
用場景來分析的話,一個場景是.stf文件(Speed Tree Forest).該文件描述了每棵樹的相關屬性。而一棵樹是通過一個.spt(Speed Tree)文件來描述的.用文本編輯器打開,就能看到里面記錄了該樹的所有信息。而該插件為此開發了配套了樹木編輯器材。使用該編輯器,打開.spt文件之后,就可以對該樹進行瀏覽以及編輯。
3.Speedtree使用實踐
它提供給用戶的一個最主要的類就是CSpeedTreeRT.這是一個speedtree對外界的接口,從SpeedTreeRT.h中可以看到,這個類其實是包括了該插件的核心類.因此,我們在使用該插件的時候,其實全都是通過這個接口。
譬如CSpeedTreeRT::SetCamera(eye, viewDir),通知它內部現在的攝像機的信息,然后它內部就根據這些信息計算出正確的billboard.
而如何加載一棵樹呢?使用CSpeedTreeRT::LoadTree(const char *treefile);輸入一個”.spt”文件,然后我們設置光照和風效果的方法如CSpeedTreeRT::SetBranchWindMethod,SetFrondWindMethod,SetBranchLightingMethod,SetLeafLightingMethod, SetLodLimits等,接著執行CSpeedTreeRT::Compute(),然后它里面就開始進行黑盒處理,最后我們就可以獲取其幾何數據(CspeedTreeRT::GetGeometry)進行渲染。獲取之前還可以手動去設置LOD級別CSpeedTreeRT::SetLodLevel,然后你獲取到的就是經過LOD處理的幾何數據。
不過有一點需要要注意的是,speedtree里面用的是右手坐標系(盡管它說可以通過define Y_UP來改變坐標系統,但我沒發現define改了之后有什么變化,很奇怪)。筆者開始的時候完全沒注意到這點,發現搬到自己的架構后,樹全都是橫著的。當時死活發現不了問題,就去旋轉每棵樹。然后又發現那些樹葉也無法正常地旋轉成billboard,又查了很久。后來終于發現,是因為speedtree內部使用右手坐標系進行計算。而我的架構是使用左手,這樣一來,連傳給speedtree camera的數據都要修改了, CSpeedTreeRT::SetCamera(eye, viewDir),其中的eye,eyeDir,都得經過變換再傳進去:
float3 viewDir=pCamera->GetViewDir();
float3 eye=pCamera->GetEye();
float afDirection[3];
afDirection[0] = viewDir.x;
afDirection[2] = viewDir.y;
afDirection[1] = -viewDir.z;
CSpeedTreeRT::SetCamera(eye, afDirection);
4.把speedtree加到自己的引擎中去
以上所說的CSpeedTreeRT接口,筆者在使用的時候都是讓一個CSpeedTreeRT對象匯聚到自己設計的一個tree類里。通過這種方式來封裝speedtree,搭建中間架構。CSpeedTreeRT這接口也許多靜態函數,譬如SetCamera,參照它的DEMO,
直接“CSpeedTreeRT::SetCamera(eye, eyeDir);”但要實現完美地跟自己的引擎相結合,也并不是一件容易的事情。主要是,自己的引擎本來就有一套完整的渲染系統,LOD系統,動畫系統,而且跟speedtree的方式也不一樣。一個極端的做法就是,對于SpeedTreeRT,屏蔽其實時計算,而是根據自己引擎的系統計算,這樣的話, 其實是只利用了SpeedTree的數據結果了。而另外一個極端就是,不管 speedtree和自己引擎的關系,只保留簡單的耦合,各自使用各自的系統,只是讓他們的渲染行為(LOD,光照效果等)保持一致性。至于更好的辦法,筆者也是在研討中,我非常希望能跟讀者進行探討,這也是筆者寫本筆記的動機之一。