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的重大改進
這也是去年實際做項目中遇到的最麻煩的問題。由于不能共享，導致過渡的耗費，讓我們不得不放棄了某些后期的效果?，F在終于解決了。就是通過了一個叫‘pooled’的東西。
1. 當不同的合成器實例使用一個相同大小和格式的表面時可以被共享,這樣可以節省內存。
就是說rendertarget如果設的一樣的話，就可以被用來用去了。
2. 系統會幫你偵測這個合成器實例鏈以避免相互依賴。
3. "pooled"需要在定義紋理時顯式被激活。注意下，這個激活不是默認的。因為一旦它被激活，你就沒法完全看到那些作為中間過程的紋理了。（因為他們可以通過共享的方式互相傳遞（ping-ponging），或者叫反射吧）；但是如果用戶又恰好需要，所以就設置了默認不激活。
其實很好理解，就是說如果"pooled"被激活，那么那些被用來ping-ponging的紋理就得不到了，因為不作為最終結果的圖不會被保存，那個被共享的rendertarget會被反復擦寫。所以說，你如果到最后又想用那些圖，就不能激活"pooled"也就是說，使用默認了就可以了。
4. 另外一個就是可以在運行時，交換兩個Compositor。Technique現在都有一個自己的名字"scheme"。交換的時候只要通過名字來所以就可以了。不用麻煩的再去用大量的宏定義去判斷什么的，以前做法是判斷硬件是否支持啊，或者自定義幾種表現方式啊?，F在都不用了。因為那樣看起來會很亂。
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組件。
這個太強了，以前材質腳本都需要一個懂美術&懂技術的人員來搞定?，F在不用了，在畫面上點點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后還會有個飛躍~
方法一：
CEGUI的字符串類設計的初衷是以32個字符為分界點, 低于32個字符使用固定buffer, 高于才使用棧分配內存存儲字符串. 不過因為CEGUI使用utf32,兼容性雖然很好,但是在VC調試器里無法顯示是個很大的問題.
這里參考了mybios博客中的文章,給CEGUI字符串做一個patch
然后需要找到vs2008的autoexp.dat文件
XP下位于:C:\Program Files\Microsoft Visual Studio 9.0\Common7\Packages\Debugger\autoexp.dat
用記事本等工具打開, 在AutoExpand段中像這樣添加:
[AutoExpand]
; CEGUI String
CEGUI::String = str =<d_quickbuff,su> length =<d_cplength>
即可在VC調試器中看到CEGUI字符串內容, 不過中文還是暫時無法支持
方法二：
CEGUI的String不是std::string或std::wstring，而是自己實現的一個字符串類，他的功能跟std的string很接近。
但是，他支持unicode，內部存儲是使用utf32編碼規范來存儲unicode字符，也就是說 typedef uint32 utf32; utf32* d_buffer;用這個32位無符號整型的數組來保存unicode字符串。優點是顯而易見的，就是世界上所有字符都可以包囊進去，畢竟是32位??！但是，缺點也出來了，有兩點：
第一、內存占用過多，一個字符就要占4個字節，也太浪費了點；
第二、調試不方便，由于VS2005的調試窗口只支持ansi和utf16的格式，所以，CEGUI的String在調試器中只能看到一堆數字數組，而看不到字符，這是很郁悶的，每次要查看都要翻到內存那里看，而且還一堆亂碼，超級麻煩。
解決辦法：修改String類，使用utf16來代替CEGUI的utf32。
優點：
解決了內存占用過多的問題，一個字符只要2個字節就可以了；
解決了調試問題，VS2005直接支持utf16的顯示。
缺點：
可能不支持全世界的字符，因為utf16不能表示超過16位的字符，但是，對于大多數國家的字符來說，已經足夠了，畢竟windows2000/xp也是基于utf16編碼的。
然后，下面是修改后的字符串類：
CEGUIString