Ogre 1.7版本重大改進

Ogre新的版本在年後首次釋出了。1.7較之以往的版本有了長足的進步。

由于跟SOC的互動，Ogre 1.7開始慢慢滲透了更多隻有商業引擎才有的功能。這得益于最初優良的架構。

下面一個一個道來。

1.改了個名字，似乎是另外一個怪獸。：） 協定改變，現在是MIT了，總之就是更自由了。

2.Sample Browser的引入，社群裡有篇寫的很詳細的文章。很多商業引擎都有，個人覺得實行用其實一般，屬于引擎的噱頭。以後隻需要進行一次資源重建就可以切換包括渲染系統等等東西，不用重新運作可執行檔案。

3.使用CMake來建構，好處就不說了，社群裡也有文章很詳細。

重點來了啊~~

一.地形系統重大改進。

1. 地形管理從場景管理中獨立出來，成為一個可選組建

2. 内置了可編輯功能 (不過功能還不強大哈)

3. 使用了批量渲染。當頂點數量随着LOD遞減時，渲染的批次也會遞減。最低的Lod渲染批次的數量為1

4. Lod可以實時的與Camera設定進行适配。是以可以友善在不同的視角中使用同樣的地形

5. Skirts技術替代了早期的縫合技術來出來地形的裂縫。

這裡解釋下。Skirts不知道國内通用的翻譯是什麼。直接翻譯成“裙子”也行。大片地形渲染中，不同的Lod層次的地塊由于有不共用的頂點是以一定會造成裂縫（Cracks）。老的解決辦法就是縫合，通過削減進階别Lod地塊的邊緣頂點數或者增加低級别地塊的邊緣頂點數來做過渡。這樣的缺點是，無論哪種方法都要重新周遊整塊地形然後重新進行三角形剖分。對地形的分頁和緩存帶來很大的麻煩。

Skirts的做法，則是對每個分塊的四條邊，在現有的頂點的基礎上再延伸出一圈，并且與單個分塊的邊界共享頂點，而高度值不同，這種延伸出來的一圈叫做“裙子”（Skirts）。蠻形象的把，呵呵。隻要保證頂點的高度值足夠大，兩個分塊的裙子可以把裂縫遮擋住。

這種消除裂縫的方式唯一缺點是會增加繪制的三角形數量，但是對于現在的圖形處理器來講，這種三角形數量的額外增加不會帶來性能上的下降。

6. 内建了地形的儲存和加載，并且是在背景線程裡完成的

7. 支援多層材質融合，可配置的采樣輸入，以及可插件化的材質。

8. 支援生成全局Normal maps和light maps.同樣也是在背景線程完成的。

二.Compositor的重大改進

這也是去年實際做項目中遇到的最麻煩的問題。由于不能共享，導緻過渡的耗費，讓我們不得不放棄了某些後期的效果。現在終于解決了。就是通過了一個叫‘pooled’的東西。

1. 當不同的合成器執行個體使用一個相同大小和格式的表面時可以被共享,這樣可以節省記憶體。

就是說rendertarget如果設的一樣的話，就可以被用來用去了。

2. 系統會幫你偵測這個合成器執行個體鍊以避免互相依賴。

3. "pooled"需要在定義紋理時顯式被激活。注意下，這個激活不是預設的。因為一旦它被激活，你就沒法完全看到那些作為中間過程的紋理了。（因為他們可以通過共享的方式互相傳遞（ping-ponging），或者叫反射吧）；但是如果使用者又恰好需要，是以就設定了預設不激活。

其實很好了解，就是說如果"pooled"被激活，那麼那些被用來ping-ponging的紋理就得不到了，因為不作為最終結果的圖不會被儲存，那個被共享的rendertarget會被反複擦寫。是以說，你如果到最後又想用那些圖，就不能激活"pooled"也就是說，使用預設了就可以了。

4. 另外一個就是可以在運作時，交換兩個Compositor。Technique現在都有一個自己的名字"scheme"。交換的時候隻要通過名字來是以就可以了。不用麻煩的再去用大量的宏定義去判斷什麼的，以前做法是判斷硬體是否支援啊，或者自定義幾種表現方式啊。現在都不用了。因為那樣看起來會很亂。

5. 現在也可以儲存和共享一個用過的紋理，保證向前向後交換都變得更快。

另外還有一些細節修改：

a.不想繼承FSAA的，需要設定下'no_fsaa'。

b.支援逐紋理sRGB gamma校正。

c.跨Compositor的通信。

i.使用chain_scope 或 global_scope 直接可以定義紋理來自于其他的地方。

ii.使用texture_ref，可以直接從其他Compositor或公共部分引用一個紋理。

d.Compositor代碼之間連接配接被改進了

i.可以自定義一個合成器pass。不僅僅是quad/scene/clear啦。要用render_custom來激活這個自定義的類型。

ii.可以自動使用CompositorLogics，來使compositor和相關的代碼連接配接（例如使用一個compositor監聽者）

PS:compositor這種東西在其他引擎中還很少見到，原因是涉及的東西太複雜，不好抽象，如果限制太多，後期做起來就很困難。Ogre算是一個嘗試把，不是實際用起來還是有不少地方不太友善使用。等大牛們慢慢重構把，希望以後對後期制作方面的設計是個幫助。

三：增加了幾個很牛X的元件

1.RTSS元件。

這個太強了，以前材質腳本都需要一個懂美術&懂技術的人員來搞定。現在不用了，在畫面上點點UI，儲存下，就完成了一個Shader檔案。并且裡面支援per-pixel lighting, normal mapping and shadows等更多内容。

已經有點gamebryo的意思了。GB裡做的隻是把這個生成Shader的方式跟Max結合到了一起。而作為Ogre我也覺得應該有自己的一套pipeline，并且內建好用的工具提供給遊戲開發人員。現在看到個雛形，挺高興。

實作過程其實還是蠻複雜的，特别是建構一個ShaderTree系統，具體的關于Gamebryo的實作，做個廣告，http://www.guibian.com。可以去我Blog看羅。

另外，我覺得這還不夠帥，按照這樣發展下去，SOC2010應該能作出類似UE3的東西，就是拖拖拉拉出Shader。至少我覺得在Ogre現有架構下實作并不複雜。

2.分頁組建。

新的分頁元件從場景管理器中獨立開，分拆成為幾個不同的可選元件。

插件化的政策元件來控制場景中的分頁。插件化的内容元件來控制分頁的内容。

插件化的集合元件用來組合不同的分頁(比如 在一個頁中分出多個LOD級别)

四：支援Iphone

估計地球人都知道了，自己去看代碼把。很多Objective C的東西，看起來很親切把。：） 我的Ip已經能跑起來了。就是速度還有待提升。另外别忘了先預解析一下材質腳本，不然解析Shader很費電。 - -||

五：幾個不加解釋的翻譯

1. 場景管理器的修改，可以中途暫停一幀的渲染（比如通過在一個過程中使用回調函數），暫停後可以觸發另一個渲染，最後在恢複。這是之前在商業引擎中看到的。而且是個很有用的功能。

2.添加了一個選項可以手動觸發陰影圖的更新，比方在有特殊光照的時候。

兩個方法結合起來很有用。當有多重shadowmap的時候，紋理就可以被重用了。

其實還是Compositor裡的東西，另外跟DS有關。

抗鋸齒的改變

1.支援CSAA，dx9和10中可以使用。

2.簡化了并标準化了AA的設定。

在Root的config選項裡。所有情況下都加FSAA，組合上一個采用方式和一個提示字元串。通過空格分隔。

在createRenderWindow的miscParams參數上你可以提供 "FSAA" 和 "FSAAHint"參數,前面是這個采樣的倍數，後面是一些提示(例如品質)

PS：怎麼跟gamebryo越來越像，懷疑google code這些家夥是GB的倒戈。

光照的改變

1.陰影錄影機的遠近裁減面設定支援每盞燈光。

2.可以通過調用MovableObject::setLightMask來設定渲染物體mask光照,一個可渲染物體的掩碼與燈光掩碼按位求與，如果是0，燈光就被排除。

LOD的改變

LOD不再使用距離作為度量來區分了。

LOD政策現在在材質和網格上都能被設定，或者按照距離，或者按照像素數。當然也可以很友善的添加新的政策。

STL容器

所有的STL 容器現在使用自定義的記憶體分派。

優化

固定管線的光照狀态更加智能化，為了處理物體數量巨大的時能發揮更好的性能。

着色器參數更新現在更加有選擇性了，減少不必要的更新。

GpuProgramParameters改變

多個cg程式或者材質基本中需要共享的參數可以在一個地方定義和更新。代碼看這裡：GpuProgramManager::createSharedParamerers

當Gpu程式的基類被改變或者重加載以後，參數會自動被移植。改變後任然可以使用的參數将合并到新的參數中去。

檔案系統的改變

支援建立和移除檔案（僅在FileSystem中有效）

DataStream的改變

可寫資料流也支援了（同樣僅在FileSystem中有效）

加了一個新的類StreamSerialiser，是讀寫二進制資料格式的新方法。

PS：看到Ogre開始也要用流格式來管理資料了

RenderWindow的改變

可以自定義v-sync的重新整理頻率。并且硬體也要支援。

視口的改變

增加了一個clear方法來手動清除任何 顔色/深度/模闆的組合，這個指定值不執行更新操作。

圖檔的改變

增加了 loadTwoImagesAsRGBA 和 combineTwoImagesAsRGBA 這兩個方法，使用它可以更容易的構造 法線/高度圖 和 漫反射/高光圖等組合

線程也做了修改，大家自己去看把。

總結下，這次新版本作出的改變。感謝SOC的那幫牛人，Ogre越來越向着一個易用的引擎靠攏。開始借鑒很多商業引擎不錯的地方。開始慢慢解決在實際項目中遇到的問題。而他優良的擴充性被展現的很明顯。最初項目開發的時候，我們發現Ogre其實有很多"bug"，之是以有個引号，是因為那不叫真正的Bug，由于Ogre在遊戲項目中不太經常的出場率，造成很多引擎設計上沒有考慮到的問題，不過我發現這個版本很多的新功能都彌補了那些缺陷。這些可喜的結果我相信在SOC2010後還會有個飛躍~

本文隻發表在此處與http://class.gd    是以如果轉載請著名出處