做商業網路遊戲的話,效率是乙個不可避免的話題,為了留更多的空間給客戶端的邏輯,那麼渲染模組就應該盡量高效. 小弟只**一下ogre的渲染優化,以大家熟悉的天龍八部為例. 以網上流傳版本的天龍**來看,ogre和cegui部分的渲染都有嚴重的效能問題, ogre: 地形的實現,乙個tile,只按材質做了批次優化,並沒有按材質做攝像機的裁剪,導致遊戲視角下批次增加很多 靜態實體的合併,完全錯誤的做法,同地形一樣,只優化了批次,沒做攝像機的裁剪. cegui: 由於cegui本身對字體重繪處理的缺陷,導致快取的字型沒用,每幀都會計算位置排版之類,效率其低,改進的方法當然有, 比如普通字型可以當去快取,最好的方式還是移植到0.75，效率立馬提高n倍. cegui我就懶得說了,只談談ogre部分的優化.
優化之前,先理解優化的原理.
1).renderable和渲染批次:
渲染批次是神馬?自己去看教程,簡單講,他極大地影響渲染的效率,所以渲染批次盡量少.比如10個批次,渲染10000個三角形,比10000個批次,渲染10個三角形速度快得多,
怎麼才算乙個批次?渲染乙個renderable就算乙個批次,renderable是ogre中最小的渲染單元,所有需要渲染的物件都繼承與此.
一句話:乙個renderable等於乙個batching(渲染批次),減少場景中的renerable,就減少了批次.
怎麼減少renderable?比如2棵材質一樣的樹(2個renderable),我可以合成乙個棵樹(1個renderable),合成辦法2種,一種是美工在max裡面靜態合併,一種是程式動態合併(staticgeometry)
值得一提的是,乙個mesh不一定是乙個批次,submesh才是,如果乙個mesh有2個不同材質的submesh,正常,
如果有2個同材質的submesh,不好,應該立即找美工,罵他一頓.說:為什麼不把同材質的2個submesh合成乙個?
2)movableobject和攝像機裁剪
ogre的octreescenemanager的攝像機裁剪,是以包圍盒為準,那麼就意味著有包圍盒的物件才可以被裁剪,renderable有包圍合麼?沒有!但是movableobject就有,movableobject是移動物件的基本,同時繼承shadowcaster,可以投射陰影.
值得一提的是,攝像機的裁剪並不是以movableobject而單位,而是以scenenode為單位,只有掛接到scenenode上的movableobject才
會被裁剪,
3)要渲染,renderable,要移動,moveable,如果都要,最簡單的物件應該就是******renderable : public movableobject, public renderable
想起以前自己做地形用mesh去做,很笨,效率不行,應該mesh類太大,包含了太多不需要的東西,用******renderable是最高效率的.
地形的實現,一種是用拼格仔,每個格仔乙個四邊形,不共用頂點,不能lod,但是乙個格仔就可以多層紋理,適合2.5d視角遊戲,比如魔獸3和天龍
另一種就是主流3d遊戲做法,共用頂點,lod,缺點是乙個地形page的紋理層數和前面那種地形的乙個格仔一樣多...比如8層,其實已經足夠,紋理過渡也很自然.拼格仔的紋理過渡始終很醜.
1)天龍的地形實現原理如下.
整個地形分很多tile組合而成,class terraintile : public ogre::movableobject
乙個tile是乙個movableobject,用來攝像機裁剪.
每個tile包含乙個renderablelist;乙個tile裡面,同材質的格仔會被做成乙個renderable,
tile大小事32，那麼有32*32 個格仔,假如這些格仔用了10種不同的材質,那麼這些格仔就被做成10個renderable
渲染沒問題,按材質分批次渲染,10個批次,
但是攝像機裁剪有問題,攝像機只能按tile去裁剪,因為tile是movableobject,而那10個renderable卻不能單**剪
這樣的話,比如,攝像機只看到這個tile.32*32格仔中最邊上的乙個格仔,也會把整個tile渲染,10個批次....
如果把10個renderable都做成movableobject,可以裁剪,那麼只看到最邊上這個格仔的話,只會渲染最邊上的那個renderable,1個批次.
實踐證明,對於2.5d視角遊戲,地形的批次幾乎可以降低一半
2)tile的大小
tile設想多大,效率最高?這和攝像機有關,最好是遊戲視角,攝像機剛好看那麼大的範圍再大一點點,天龍的32，對於他的視角,是合理的.
3)texture atlas
天龍的地表的紋理很小,128*256 導致材質很多,批次就很多,如果做texture atlas把小紋理合成大紋理,批次就會減少很多,但是也會有其他一些附加問題,比如mipmap導致的縫隙,解決縫隙,國外其實有不少解決方法, 比如可以寫shader,在不同的mipmap下調整紋理座標，或者預留紋理座標,在已有紋理上加一圈和邊緣相同的畫素,這樣就不會取到其他紋理畫素,導致縫隙.
天龍2增加了天空視角,即使看到很多場景,渲染效率卻沒有受到多大影響,所以個人認為,他應該做了texture atlas,減少了整個場景的批次,不然實現不了天空視角.
Ogre的渲染優化心得 一 前言
做商業網路遊戲的話,效率是乙個不可避免的話題,為了留更多的空間給客戶端的邏輯,那麼渲染模組就應該盡量高效.小弟只 一下ogre的渲染優化,以大家熟悉的天龍八部為例.以網上流傳版本的天龍 來看,ogre和cegui部分的渲染都有嚴重的效能問題,ogre 地形的實現,乙個tile,只按材質做了批次優化,...
轉 ogre 渲染流程
ogre渲染流程 1.fireframestarted 2.按某種優先順序更新所有渲染目標 2.1 firepreupdate 2.2 更新所有視口 2.2.1 fireviewportpreupdate 2.2.2 場景管理的渲染函式 2.2.2.1 更新陰影 2.2.2.2 更新動畫 2.2.2...
Ogre 渲染佇列（一）
渲染佇列在 ogre 中是乙個重要的概念，在場景中的所有物體都會在繪製前被 ogre 放入到乙個特定的渲染佇列中。渲染佇列主要起兩個作用 1.確保正確的繪製順序。比如先繪製天空盒再繪製一般物體，最後繪製介面。2.提高渲染效率。ogre 將具有相同 pass 的物體放在一起進行繪製，目的是盡可能減少渲...