原作者 : Kevin Lynx
BLOG:
http://blog.csdn.net/kevinlynx第一部分：
HGE helper類中的GUI：
引擎版本：1.60release。
文件：hgegui.h , hgegui.cpp, hgeguictrls.h , hgeguictrls.cpp
大致類圖：
其中，hgeGUIObject是抽象基類，具體的控件類如按鈕，文本標簽，都是從它派生而來。HgeGUI屬于整個GUI系統(tǒng)的manager，它會保存所有的控件。
關于hgeGUIObject的8個成員變量，文檔里已經有所描述：
int id; //控件ID
bool bStatic; //是否可以接受鍵盤焦點
bool bVisible; //是否可見
bool bEnabled; //是否有效
hgeRect rect; //控件大小
hgeGUI *gui; //其屬于的 manager ，相當于父對象
hgeGUIObject *next; //用于雙向鏈表，把所有控件連接在一起
hgeGUIObject *prev;
static HGE *hge; //方便使用HGE接口
關于其部分接口的描述：
Render: 用于渲染控件到屏幕上
Update: 用于更新其動畫
Enter: 控件剛顯示時的動畫
Leave: 控件要消失時的動畫
IsDone: 控件剛顯示和消失時的狀態(tài)查詢函數(shù)
該類也就是提供了一個抽象而已，利用C++語言的多態(tài)機制來方便hgeGUI管理所有的控件。其他具體的控件繼承了hgeGUIObject后，必須實現(xiàn)構造函數(shù)和Render函數(shù)。
關于hgeGUI：
這個類應該屬于manager。它負責管理所有的控件。
其數(shù)據成員：
hgeGUIObject *ctrls; //保存所有控件
hgeGUIObject *ctrlLock; //可能是用來保存當前被鼠標操作的控件
hgeGUIObject *ctrlFocus; //保存焦點控件
hgeGUIObject *ctrlOver; //用來保存鼠標指針所指的控件
int navmode;
int nEnterLeave;
hgeSprite *sprCursor; //渲染鼠標指針用的
float mx,my; //鼠標坐標
int nWheel; //滾輪偏移量
bool bLPressed, bLLastPressed;//本幀左鍵狀態(tài)，上一幀的左鍵狀態(tài)
bool bRPressed, bRLastPressed;
其Update方法會負責控件的進入和離開動畫，還會負責整體的狀態(tài)設置---哪些控件擁有焦點，哪些控件被鼠標正在操作，哪些控件正被鼠標指針指著，這些控件它都會保存起來。（也就是說，我們還是可以通過檢查控件的狀態(tài)來設置當鼠標指針在其上時的新動畫。）
總體而言，該引擎的GUI還是很簡單的。一個manager，負責管理所有的控件，然后一個抽象基類，用來協(xié)助manager管理---其他具體的控件都必須從那個抽象基類派生。
下面具體看一個Button控件：
Button類的定義如下：
class hgeGUIButton : public hgeGUIObject
{
public:
hgeGUIButton(int id, float x, float y, float w, float h, HTEXTURE tex, float tx, float ty);
virtual ~hgeGUIButton();
void SetMode(bool _bTrigger) { bTrigger=_bTrigger; }
void SetState(bool _bPressed) { bPressed=_bPressed; }
bool GetState() const { return bPressed; }
virtual void Render();
virtual bool MouseLButton(bool bDown);
private:
bool bTrigger;
bool bPressed;
bool bOldState;
hgeSprite *sprUp, *sprDown;
};
其中bTrigger表示該按鈕的行為是否象一個RadioButton，bPressed表示當前按鈕是否被按下，bOldState表示上一次按鈕狀態(tài)，特別用來實現(xiàn)bTrigger的，sprUp,sprDown分別用來繪制彈起和按下時的按鈕外觀。這兩個精靈的創(chuàng)建都是從構造函數(shù)的tex上創(chuàng)建而來的，它要求兩個狀態(tài)必須保存在一幅紋理上，且順序為從左至右。
按鈕的實現(xiàn)代碼也很簡單：
void hgeGUIButton::Render()
{
if(bPressed) sprDown->Render(rect.x1, rect.y1);
else sprUp->Render(rect.x1, rect.y1);
}
bool hgeGUIButton::MouseLButton(bool bDown)
{
if(bDown)
{
bOldState=bPressed; bPressed=true;
return false;
}
else
{
if(bTrigger) bPressed=!bOldState;
else bPressed=false;
return true;
}
}
聯(lián)系起來，當hgeGUI::Update里處理ProcessCtrl時，如果鼠標左鍵按下且其指針在按鈕范圍內，那么就調用hgeGUIButton::MouseLButton( true )，這個時候button的bPressed=true,那么在渲染的時候，自然就表現(xiàn)出被按下時的狀態(tài)。
事實上對于這種類型的按鈕---如同windows下的窗體按鈕，我們一般不檢查其是否被按下，而是檢查其是否發(fā)生了clicked 這個事件，而這個事件是在先按下在彈起的情況下發(fā)生的。因此，判斷該事件發(fā)生的條件就為：上一幀狀態(tài)被按下，這一幀沒被按下。
雖然HGE引擎的GUI很簡單，但是其擴展性很好。因為hgeGUI::Update基本上派發(fā)了所有控件需要的消息---鍵盤操作，以及鼠標操作；而hgeGUIObject基類的很多成員函數(shù)都會處理這些消息，我們只需要派生hgeGUIObject，然后重載我們需要的消息處理即可。
第二部分：
HGE擴展GUI庫，從HGE官方論壇下載（作者不明）：
工程結構：
其中，guitest.cpp為測試文件。
類結構：
整個系統(tǒng)的工作原理：
用戶繼承抽象基類GUIApp，實現(xiàn)具體的OnEvent函數(shù)，然后該類會管理所有的GUIAppWindow對象，GUIAppWindow窗口對象會管理其上的所有子控件。
相應地，GUIApp派生類會直接得到鼠標和鍵盤消息，然后派發(fā)給所有窗口對象，然后窗口對象再把消息派發(fā)到具體的控件對象上。
這種Parent-Child關系大致為：
GUIAppWindow類保存有其所屬的GUIApp對象指針，每個具體的控件又保存有其所屬的GUIAppWindow 的對象指針。
當一個控件處理了某個事件后，例如按鈕處理了鼠標單擊事件，它就需要告訴外界用戶單擊了這個按鈕。這里采用的方法是：在基類GUIAppObject里定義了一個虛函數(shù)OnEvent( int id)
，然后在其派生類GUIAppWindow里把這個函數(shù)重載為純虛函數(shù)，函數(shù)有一個參數(shù)，那就是控件ID。當一個控件處理了某個事件后，就通過其內部保存的父窗口指針來調用OnEvent函數(shù)，然后GUIAppWindow的派生類---如果該類能產生對象，那么其必然實現(xiàn)了OnEvent的具體代碼（這就是為什么在GUIAppWindow里要把OnEvent又重載為純虛函數(shù)的原因），然后在此代碼里，窗口根據傳進來的控件ID來得知哪個控件發(fā)生了事件！
GUIAppWindow里有一個容器，它保存了所有該窗口上的控件。
所有控件再創(chuàng)建時，都是以其父窗口為參考坐標系的，也就是相對坐標，但是其實際保存的坐標卻是絕對坐標—既相對于整個屏幕的坐標（如果是窗口程序，就相對于整個窗口）。大致過程為：在GUIAppWindow派生類中創(chuàng)建子控件時，給子控件指定的坐標為相對坐標，然后當 AddCtrl 時就會重新把子控件的坐標改變?yōu)榻^對坐標。
GUIApp里直接有了BeginScene和EndScene的渲染代碼。
要使用該擴展庫，大致步驟為：
1． 繼承GUIAppWindow類，在這個派生類里重載具體的處理OnEvent的函數(shù)，并創(chuàng)建所有該窗口上的子控件。
2． 繼承GUIApp類，在這個派生類中創(chuàng)建窗口對象，并把窗口對象AddCtrl，在這里可以進行其他的初始化工作
3． 在FrameFunc里調用GUIApp::FrameFunc函數(shù)。
總體而言，這個擴展GUI主要是擴展了GUI Manager以及GUI Object，并且加入了Parent-Child機制。比較經典的部分在于提供了一個 OnEvent 函數(shù)，這樣就可以讓客戶程序員能夠得知窗體上的控件發(fā)生的事件。 ----其實這種方法的目的就跟Windows中的消息機制，Qt中的signal/slot機制一樣。
近日很多朋友咨詢Overlay中文顯示問題，回答的多了想索性再寫個文檔算了，放在網上共享，于是就有了本篇。
在Ogre1.2.5版本中，通過與Ogre官方論壇的開發(fā)者討論實現(xiàn)了Overlay的中文顯示，當初的實現(xiàn)非常的怪異，具體的實現(xiàn)可以參見Ogre官方論壇。
隨著Ogre的更新，現(xiàn)在Ogre已經發(fā)布了1.4.7，1.4系列版本有一個重要的改進，就是加入了UTFString，這為Ogre中文顯示予以很大的幫助。為了便于演示，我直接使用Ogre自帶的Overlay，也就是大家熟悉的DebugOverlay，測試工程我選擇Demo_ParticleFX，選擇其他的也沒有關系。現(xiàn)在編譯它，運行后得到下圖：
圖的最左下角顯示的就是英文DebugOverlay，接下來我們的任務就是把它編程中文的，^_^。
Overlay中文化操作步驟如下
1. 打開OgreSDK\media\packs\ OgreCore.zip。
2. 打開C:\WINDOWS\Fonts，把simhei.ttf添加到OgreCore.zip，（什么，沒有simhei.ttf這個文件，那就還其他的中文ttf字體吧）。
3. 打開OgreCore.zip中的Ogre.fontdef，里面有BlueHighway這個字體定義塊，在他的下面添加我們的SimHei，code_points里面的一大堆數(shù)字看不明白沒關系，隨后文章會解釋。
SimHei
{
type truetype
source simhei.ttf
size 16
resolution 96
code_points 33-166 24403-24403 21069-21069 24103-24103 36895-36895 29575-29575 24179-24179 22343-22343 26368-26368 39640-39640 20302-20302 19977-19977 35282-35282 24418-24418 25968-25968 37327-37327 25209-25209 27425-27425
}
4. 打開OgreCore.zip中的OgreDebugPanel.overlay，把BlueHighway全部替換成SimHei，我們要使用中文字體了，嘿嘿。
5. 修改完成后，確保所做的修改已經保存到OgreCore.zip。
6. 進入Ogre解決方案，打開文件ExampleFrameListener.h，把54-59行的代碼替換如下：
static String currFps = "Current FPS: ";
static String avgFps = "Average FPS: ";
static String bestFps = "Best FPS: ";
static String worstFps = "Worst FPS: ";
static String tris = "Triangle Count: ";
static String batches = "Batch Count: ";
static DisplayString currFps = L"當前幀速率: ";
static DisplayString avgFps = L"平均幀速率: ";
static DisplayString bestFps = L"最高幀速率: ";
static DisplayString worstFps = L"最低幀速率: ";
static DisplayString tris = L"三角形數(shù)量: ";
static DisplayString batches = L"批次: ";
7. 最后重新編譯工程，下面是我運行的截圖，是不是已經顯示中文了，^_^。
現(xiàn)在再來看看SimHei中的code_points是如何生成的，這個可以參考我上次寫的這篇文章http://www.cnblogs.com/gogoplayer/archive/2008/05/09/1189795.html，至此，實現(xiàn)Overlay中文顯示。
轉載請注明出處：
作者：gogoplayer
E-mail : gogoplayer@163.com
QQ : 78939328
http://www.gogoplayer.com.cn
OGRE主要渲染流程簡介
謝偉亮 feiyurainy@163.com
轉載請注明出處
很早以前就想寫一些關于OGRE的文章了，一直沒機會。
理解一個渲染引擎，我覺得最重要的是先抓住了它的主架構，它的主線，渲染流程，不然的話，一個引擎幾萬行，甚至幾十萬行的代碼，光是打開solution就能嚇你一跳了，OGRE也有十幾萬行的代碼量，我一開始看它的時候也是無從下手，感覺代碼太多了，不知道從哪開始看好，這個class看看，那個class看看，由于對整個引擎沒有一個清晰的認識，看過了也印象不深，所以，最后，還是決定先找出它的主線，了解它的渲染流程，這樣才能有機地把各個部分聯(lián)系起來。
這篇短文也是對OGRE的主要渲染流程的一個介紹，可能對一些class不會太多地去介紹具體的實現(xiàn)細節(jié)。我所用的代碼都是取自于OGRE的最新的CVS版本。
讀者最好對OGRE有一定的了解，至少得看懂它的example，不然可能一些東西理解起來比較困難。對D3D，OPENGL有一定了解更好。
如果你看過D3D SDK中帶的例子，你一定知道一個比較簡單的3D程序要運行起來，至少都會涉及以下的幾部分：
首先是數(shù)據的來源，包括頂點數(shù)據，紋理數(shù)據等，這些數(shù)據可以從文件中讀取，也可以在程序運行時生成。
接下來，我們會建立頂點緩沖區(qū)把頂點保存起來，建立texture對象來表示texture，對頂點組成的物體設置它在世界坐標系下的坐標，設置攝像機的位置，視點，設置viewport的位置和大小，然后就可以在渲染循環(huán)中開始調用渲染操作了，經過了front buffer和back buffer的交換，我們就能在屏幕上看到3D圖形了，偽代碼如下：
setupVertexBuffer
setWorldTransform
setCamera
setProjectionTransform
setViewport
beginFrame
setTexture
drawObject
endFrame
以下就是渲染一個物體的主要步驟，在我看來，這就是3D程序的主線，同樣道理，無論你多復雜的渲染引擎，都得實現(xiàn)上述的這些步驟，其他的一些效果如陰影，光照等，都是附著在這條主線上的，所以，如果你能在你所研究的渲染引擎上也清晰地看到這條主線，可能對你深入地研究它會大有幫助，下面，我們就一起來找到OGRE中的這條主線。
OGRE的渲染循環(huán)都是起源于Root::renderOneFrame，這個函數(shù)在OGRE自帶的example中是不會顯式調用的，因為example都調用了Root::startRendering，由startRendering來調用renderOneFrame，如果你用OGRE來寫真正的游戲，或者編輯器，你可能就需要在的消息主循環(huán)中調用renderOneFrame了，顧名思義，這個函數(shù)就是對整個OGRE進行一幀的更新，包括動畫，渲染狀態(tài)的改變，渲染api的調用等，在這個函數(shù)中，會包括了我們上述偽代碼的幾乎全部內容，所以是本文的重點所在。
進入renderOneFrame，可以看到頭尾兩個fire函數(shù)，這種函數(shù)在OGRE中經常出現(xiàn)，一般都是fire…start和fire…end一起出現(xiàn)的，在這些函數(shù)中，可能會處理一些用戶自定義的操作，如_fireFrameStarted就會對所以的frameListener進行處理，這些fire函數(shù)可以暫時不用理會，繼續(xù)看_updateAllRenderTargets，在這個函數(shù)中，會委派當前所用的renderer對所有創(chuàng)建出來的render target進行update，render target也就是渲染的目的地，一般會有兩種，一種是render texture，一種是render buffer，接著進入RenderSystem::_updateAllRenderTargets，可以看到在render system中，對創(chuàng)建出來的render target是用RenderTargetPriorityMap來保存的，以便按照一定的順序來對render target進行update，因為在渲染物體到render buffer時，一般會用到之前渲染好的render texture，所以render texture形式的render target需要在render buffer之前進行更新。
進入render target的update，可以看到，它仍然把update操作繼續(xù)傳遞下去，調用所有掛在這個render target上的viewport的update。
Viewport其實就是定義了render target上的一塊要進行更新的區(qū)域，所以一個render target是可以掛多個viewport的，以實現(xiàn)多人對戰(zhàn)時分屏，或者是畫中畫等效果，可以把OGRE中的viewport看成是保存camera和rendertarget這兩者的組合，把viewport中所定義的camera所看到的場景內容渲染到viewport所定義的render target的區(qū)域里。
Viewport還有一個重要信息是ZOrder，可以看到RenderTarget中的ViewportList帶有一個比較函數(shù)，所以在RenderTarget::update中，ZOrder越小的，越先被渲染，所以，如果兩個viewport所定義的區(qū)域互相重疊了，而且ZOrder又不一樣，最終的效果就是ZOrder小的viewport的內容會被ZOrder大的viewport的內容所覆蓋。
繼續(xù)進入Viewport::update，就像前面所說，它調用它所引用的camera來渲染整個場景，而在Camera::_renderScene中，是調用SceneManager::_renderScene(Camera* camera, Viewport* vp, bool includeOverlays)。SceneManager::_renderScene里就是具體的渲染流程了。從函數(shù)名稱還有參數(shù)也可以看出來，這個函數(shù)的作用就是利用所指定的camera和viewport，來把場景中的內容渲染到viewport所指定的render target的某塊區(qū)域中。根據camera，我們可以定出view matrix，projection matrix，還可以進行視錐剔除，只渲染看得見的物體。注意，我們這里只看標準的SceneManager的方法，不看BspSceneManager派生類的方法，而且，我們會拋開跟主線無關的內容，如對shadow的setup，骨骼動畫的播放，shader參數(shù)的傳遞等，因為我們只注重渲染的主流程。
在SceneManager::_renderScene中所應看的第一個重要函數(shù)是_updateSceneGraph，OGRE對場景的組織是通過節(jié)點樹來組織的，一個節(jié)點，你可以看成是空間中的某些變換的組合，如位置，縮放，旋轉等，這些變換，會作用到掛接在這些節(jié)點上的具體的物體的信息，也就是說，節(jié)點保存了world transform，對具體的物體，如一個人，在空間中的定位，都是通過操作節(jié)點來完成的。同時節(jié)點還保存了一個世界坐標的AABB，這個AABB能容納所有它所掛接的物體的大小，主要是用于視錐裁減的，如果當前攝像機看不見某個節(jié)點的AABB，那么說明攝像機看不見節(jié)點所掛接的所有物體，所以在渲染時可以對這個節(jié)點視而不見。
_updateSceneGraph的內部處理比較繁瑣，我們只需知道，經過了_updateSceneGraph，場景節(jié)點樹中的每個節(jié)點都經過了更新，包括位置，縮放，和方位，還有節(jié)點的包圍盒。
繼續(xù)回到SceneManager::_renderScene，接下來要看的是setViewport，它會調用具體的renderer的setviewport的操作，設置viewport中所掛接的render target為當前所要渲染的目標，viewport中的區(qū)域為當前所要渲染的目標中的區(qū)域。
接下來要碰到OGRE渲染流程中的一個重要的概念，Render Queue。這個東西實在內容比較多，還是以后有機會單獨提出來說吧，你可以簡單把它想成是一個容器，里面的元素就是renderable，每個renderable可以看成是每次調用drawprimitive函數(shù)所渲染的物體，可以是一個模型，也可以是模型的一部分。在RenderQueue中，它會按材質來分組這些renderable，還會對renderable進行排序。
在每一次調用SceneManager::_renderScene時，都會調用SceneManager::prepareRenderQueue來清理RenderQueue，然后再調用SceneManager::__findVisibleObjects來把當前攝像機所能看見的物體都加入到RenderQueue中。
SceneManager::__findVisibleObjects是一個遞歸的處理過程，它從場景的根節(jié)點開始，先檢查攝像機是否能看見這個節(jié)點的包圍盒（包圍盒在_updateSceneGraph時已經計算好了），如果看不見，那么這個節(jié)點，還有它的子節(jié)點都不用管了。如果能看見，再檢測掛在這個節(jié)點上的所有MovableObject，如果當前所檢測的MovableObject是可見的，就會調用它的_updateRenderQueue方法，一般在這個方法里就可以把和這個MovableObject相關的renderable送入RenderQueue了。
這里要說說MovableObject，MovableObject主要是用于表示場景中離散的物體，如Entity，顧名思義，能移動的物體，不過它的“能移動”這個能力是要通過SceneNode來實現(xiàn)的，所以MovableObject來能顯示出來，首先得先掛接在某個場景節(jié)點上，通過場景節(jié)點來定位。你可以控制MovableObject的一些屬性，如某個MovableObject是否要顯示，是否要隱藏，都可以通過MovableObject::setVisible方法來實現(xiàn)。
檢測完該節(jié)點上的MovableObject之后，就繼續(xù)調用所有子節(jié)點的_findVisibleObjects方法，一直遞歸下去。這樣，就能把場景中所有要渲染的renderable所加入到RenderQueue中了。
至此，我們就擁有了要渲染的物體的信息了，接下來就是對這些物體進行渲染了，你會發(fā)現(xiàn)跟D3D或OpenGL的代碼很類似的調用：
mDestRenderSystem->clearFrameBuffer
mDestRenderSystem->_beginFrame
mDestRenderSystem->_setProjectionMatrix
mDestRenderSystem->_setViewMatrix
_renderVisibleObjects();
mDestRenderSystem->_endFrame();
這些api的作用和D3D中的類似調用的作用都差不多，這里再說一下_renderVisibleObjects()，在這個函數(shù)中，會對RenderQueue中的每個renderable進行渲染，用的是visitor模式來遍歷操作每個renderable，最終在SceneManager::renderSingleObject中取出每個renderable所保存的頂點，索引，世界矩陣等信息，來進行渲染。這其中還包括了查找離該renderable最近的光源等操作，比較復雜。
到這里，SceneManager::_renderScene的流程基本走完了，也就是說，OGRE一幀中的渲染流程差不多也結束了，你應該也發(fā)現(xiàn)，這個流程跟你用D3D寫一個簡單程序的流程基本是一樣的，在這個流程的基礎上，再去看具體的實現(xiàn)，如怎么樣設置紋理，怎么樣調用你熟悉的D3D或OpenGL的API來渲染物體，應該會簡單得多。
對OGRE的渲染流程的大概介紹到這里也結束了，很多細節(jié)都沒涉及，以后有機會再寫吧。