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