Ogre新的版本在年后首次發(fā)布了。1.7較之以往的版本有了長足的進步。
由于跟SOC的互動，Ogre 1.7開始慢慢滲透了更多只有商業(yè)引擎才有的功能。這得益于最初優(yōu)良的框架。
下面一個一個道來。
1.改了個名字，似乎是另外一個怪獸。：） 協(xié)議改變，現(xiàn)在是MIT了，總之就是更自由了。
2.Sample Browser的引入，社區(qū)里有篇寫的很詳細的文章。很多商業(yè)引擎都有，個人覺得實行用其實一般，屬于引擎的噱頭。以后只需要進行一次資源重建就可以切換包括渲染系統(tǒng)等等東西，不用重新運行可執(zhí)行文件。
3.使用CMake來構(gòu)建，好處就不說了，社區(qū)里也有帖子很詳細。
重點來了啊~~
一.地形系統(tǒng)重大改進。
1. 地形管理從場景管理中獨立出來，成為一個可選組建
2. 內(nèi)置了可編輯功能 (不過功能還不強大哈)
3. 使用了批量渲染。當頂點數(shù)量隨著LOD遞減時，渲染的批次也會遞減。最低的Lod渲染批次的數(shù)量為1
4. Lod可以實時的與Camera設(shè)置進行適配。因此可以方便在不同的視角中使用同樣的地形
5. Skirts技術(shù)替代了早期的縫合技術(shù)來出來地形的裂縫。
這里解釋下。Skirts不知道國內(nèi)通用的翻譯是什么。直接翻譯成“裙子”也行。大片地形渲染中，不同的Lod層次的地塊由于有不共用的頂點所以一定會造成裂縫（Cracks）。老的解決辦法就是縫合，通過削減高級別Lod地塊的邊緣頂點數(shù)或者增加低級別地塊的邊緣頂點數(shù)來做過渡。這樣的缺點是，無論哪種方法都要重新遍歷整塊地形然后重新進行三角形剖分。對地形的分頁和緩存帶來很大的麻煩。
Skirts的做法，則是對每個分塊的四條邊，在現(xiàn)有的頂點的基礎(chǔ)上再延伸出一圈，并且與單個分塊的邊界共享頂點，而高度值不同，這種延伸出來的一圈叫做“裙子”（Skirts）。蠻形象的把，呵呵。只要保證頂點的高度值足夠大，兩個分塊的裙子可以把裂縫遮擋住。
這種消除裂縫的方式唯一缺點是會增加繪制的三角形數(shù)量，但是對于現(xiàn)在的圖形處理器來講，這種三角形數(shù)量的額外增加不會帶來性能上的下降。
6. 內(nèi)建了地形的保存和加載，并且是在后臺線程里完成的
7. 支持多層材質(zhì)融合，可配置的采樣輸入，以及可插件化的材質(zhì)。
8. 支持生成全局Normal maps和light maps.同樣也是在后臺線程完成的。
二.Compositor的重大改進
這也是去年實際做項目中遇到的最麻煩的問題。由于不能共享，導致過渡的耗費，讓我們不得不放棄了某些后期的效果?，F(xiàn)在終于解決了。就是通過了一個叫‘pooled’的東西。
1. 當不同的合成器實例使用一個相同大小和格式的表面時可以被共享,這樣可以節(jié)省內(nèi)存。
就是說rendertarget如果設(shè)的一樣的話，就可以被用來用去了。
2. 系統(tǒng)會幫你偵測這個合成器實例鏈以避免相互依賴。
3. "pooled"需要在定義紋理時顯式被激活。注意下，這個激活不是默認的。因為一旦它被激活，你就沒法完全看到那些作為中間過程的紋理了。（因為他們可以通過共享的方式互相傳遞（ping-ponging），或者叫反射吧）；但是如果用戶又恰好需要，所以就設(shè)置了默認不激活。
其實很好理解，就是說如果"pooled"被激活，那么那些被用來ping-ponging的紋理就得不到了，因為不作為最終結(jié)果的圖不會被保存，那個被共享的rendertarget會被反復(fù)擦寫。所以說，你如果到最后又想用那些圖，就不能激活"pooled"也就是說，使用默認了就可以了。
4. 另外一個就是可以在運行時，交換兩個Compositor。Technique現(xiàn)在都有一個自己的名字"scheme"。交換的時候只要通過名字來所以就可以了。不用麻煩的再去用大量的宏定義去判斷什么的，以前做法是判斷硬件是否支持啊，或者自定義幾種表現(xiàn)方式啊。現(xiàn)在都不用了。因為那樣看起來會很亂。
5. 現(xiàn)在也可以保存和共享一個用過的紋理，保證向前向后交換都變得更快。
另外還有一些細節(jié)修改：
a.不想繼承FSAA的，需要設(shè)置下'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和相關(guān)的代碼連接（例如使用一個compositor監(jiān)聽者）
PS:compositor這種東西在其他引擎中還很少見到，原因是涉及的東西太復(fù)雜，不好抽象，如果限制太多，后期做起來就很困難。Ogre算是一個嘗試把，不是實際用起來還是有不少地方不太方便使用。等大牛們慢慢重構(gòu)把，希望以后對后期制作方面的設(shè)計是個幫助。
三：增加了幾個很牛X的組件
1.RTSS組件。
這個太強了，以前材質(zhì)腳本都需要一個懂美術(shù)&懂技術(shù)的人員來搞定?，F(xiàn)在不用了，在畫面上點點UI，保存下，就完成了一個Shader文件。并且里面支持per-pixel lighting, normal mapping and shadows等更多內(nèi)容。
已經(jīng)有點gamebryo的意思了。GB里做的只是把這個生成Shader的方式跟Max結(jié)合到了一起。而作為Ogre我也覺得應(yīng)該有自己的一套pipeline，并且集成好用的工具提供給游戲開發(fā)人員。現(xiàn)在看到個雛形，挺高興。
實現(xiàn)過程其實還是蠻復(fù)雜的，特別是構(gòu)建一個ShaderTree系統(tǒng)，具體的關(guān)于Gamebryo的實現(xiàn)，做個廣告，http://www.guibian.com。可以去我Blog看羅。
另外，我覺得這還不夠帥，按照這樣發(fā)展下去，SOC2010應(yīng)該能作出類似UE3的東西，就是拖拖拉拉出Shader。至少我覺得在Ogre現(xiàn)有框架下實現(xiàn)并不復(fù)雜。
2.分頁組建。
新的分頁組件從場景管理器中獨立開，分拆成為幾個不同的可選組件。
插件化的策略組件來控制場景中的分頁。插件化的內(nèi)容組件來控制分頁的內(nèi)容。
插件化的集合組件用來組合不同的分頁(比如 在一個頁中分出多個LOD級別)
四：支持Iphone
估計地球人都知道了，自己去看代碼把。很多Objective C的東西，看起來很親切把。：） 我的Ip已經(jīng)能跑起來了。就是速度還有待提升。另外別忘了先預(yù)解析一下材質(zhì)腳本，不然解析Shader很費電。 - -||
五：幾個不加解釋的翻譯
1. 場景管理器的修改，可以中途暫停一幀的渲染（比如通過在一個過程中使用回調(diào)函數(shù)），暫停后可以觸發(fā)另一個渲染，最后在恢復(fù)。這是之前在商業(yè)引擎中看到的。而且是個很有用的功能。
2.添加了一個選項可以手動觸發(fā)陰影圖的更新，比方在有特殊光照的時候。
兩個方法結(jié)合起來很有用。當有多重shadowmap的時候，紋理就可以被重用了。
其實還是Compositor里的東西，另外跟DS有關(guān)。
抗鋸齒的改變
1.支持CSAA，dx9和10中可以使用。
2.簡化了并標準化了AA的設(shè)置。
在Root的config選項里。所有情況下都加FSAA，組合上一個采用方式和一個提示字符串。通過空格分隔。
在createRenderWindow的miscParams參數(shù)上你可以提供 "FSAA" 和 "FSAAHint"參數(shù),前面是這個采樣的倍數(shù)，后面是一些提示(例如質(zhì)量)
PS：怎么跟gamebryo越來越像，懷疑google code這些家伙是GB的倒戈。
光照的改變
1.陰影攝像機的遠近裁減面設(shè)置支持每盞燈光。
2.可以通過調(diào)用MovableObject::setLightMask來設(shè)置渲染物體mask光照,一個可渲染物體的掩碼與燈光掩碼按位求與，如果是0，燈光就被排除。
LOD的改變
LOD不再使用距離作為度量來區(qū)分了。
LOD策略現(xiàn)在在材質(zhì)和網(wǎng)格上都能被設(shè)置，或者按照距離，或者按照像素數(shù)。當然也可以很方便的添加新的策略。
STL容器
所有的STL 容器現(xiàn)在使用自定義的內(nèi)存分派。
優(yōu)化
固定管線的光照狀態(tài)更加智能化，為了處理物體數(shù)量巨大的時能發(fā)揮更好的性能。
著色器參數(shù)更新現(xiàn)在更加有選擇性了，減少不必要的更新。
GpuProgramParameters改變
多個cg程序或者材質(zhì)基本中需要共享的參數(shù)可以在一個地方定義和更新。代碼看這里：GpuProgramManager::createSharedParamerers
當Gpu程序的基類被改變或者重加載以后，參數(shù)會自動被移植。改變后任然可以使用的參數(shù)將合并到新的參數(shù)中去。
文件系統(tǒng)的改變
支持創(chuàng)建和移除文件（僅在FileSystem中有效）
DataStream的改變
可寫數(shù)據(jù)流也支持了（同樣僅在FileSystem中有效）
加了一個新的類StreamSerialiser，是讀寫二進制數(shù)據(jù)格式的新方法。
PS：看到Ogre開始也要用流格式來管理數(shù)據(jù)了
RenderWindow的改變
可以自定義v-sync的刷新頻率。并且硬件也要支持。
視口的改變
增加了一個clear方法來手動清除任何 顏色/深度/模板的組合，這個指定值不執(zhí)行更新操作。
圖片的改變
增加了 loadTwoImagesAsRGBA 和 combineTwoImagesAsRGBA 這兩個方法，使用它可以更容易的構(gòu)造 法線/高度圖 和 漫反射/高光圖等組合
線程也做了修改，大家自己去看把。
總結(jié)下，這次新版本作出的改變。感謝SOC的那幫牛人，Ogre越來越向著一個易用的引擎靠攏。開始借鑒很多商業(yè)引擎不錯的地方。開始慢慢解決在實際項目中遇到的問題。而他優(yōu)良的擴展性被體現(xiàn)的很明顯。最初項目開發(fā)的時候，我們發(fā)現(xiàn)Ogre其實有很多"bug"，之所以有個引號，是因為那不叫真正的Bug，由于Ogre在游戲項目中不太經(jīng)常的出場率，造成很多引擎設(shè)計上沒有考慮到的問題，不過我發(fā)現(xiàn)這個版本很多的新功能都彌補了那些缺陷。這些可喜的結(jié)果我相信在SOC2010后還會有個飛躍~
方法一：
CEGUI的字符串類設(shè)計的初衷是以32個字符為分界點, 低于32個字符使用固定buffer, 高于才使用棧分配內(nèi)存存儲字符串. 不過因為CEGUI使用utf32,兼容性雖然很好,但是在VC調(diào)試器里無法顯示是個很大的問題.
這里參考了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調(diào)試器中看到CEGUI字符串內(nèi)容, 不過中文還是暫時無法支持
方法二：
CEGUI的String不是std::string或std::wstring，而是自己實現(xiàn)的一個字符串類，他的功能跟std的string很接近。
但是，他支持unicode，內(nèi)部存儲是使用utf32編碼規(guī)范來存儲unicode字符，也就是說 typedef uint32 utf32; utf32* d_buffer;用這個32位無符號整型的數(shù)組來保存unicode字符串。優(yōu)點是顯而易見的，就是世界上所有字符都可以包囊進去，畢竟是32位??！但是，缺點也出來了，有兩點：
第一、內(nèi)存占用過多，一個字符就要占4個字節(jié)，也太浪費了點；
第二、調(diào)試不方便，由于VS2005的調(diào)試窗口只支持ansi和utf16的格式，所以，CEGUI的String在調(diào)試器中只能看到一堆數(shù)字數(shù)組，而看不到字符，這是很郁悶的，每次要查看都要翻到內(nèi)存那里看，而且還一堆亂碼，超級麻煩。
解決辦法：修改String類，使用utf16來代替CEGUI的utf32。
優(yōu)點：
解決了內(nèi)存占用過多的問題，一個字符只要2個字節(jié)就可以了；
解決了調(diào)試問題，VS2005直接支持utf16的顯示。
缺點：
可能不支持全世界的字符，因為utf16不能表示超過16位的字符，但是，對于大多數(shù)國家的字符來說，已經(jīng)足夠了，畢竟windows2000/xp也是基于utf16編碼的。
然后，下面是修改后的字符串類：
CEGUIString