}
首先，RibbonTrail创建了两个链，每个最多包括80个元素，尾巴长400个世界单位。创建了一个结点animNoade。为这个结点创建了一个动画,使得这个结点可以根据关键帧的设计在场景中不断变化位置。并把一个RibbonTrail与这个结点联结起来，于是RibbonTrail可与animNode一起运动。又创建了一个灯，并联结到这个结点，灯随结点也一起运动，于是怪物头会有明暗变化。最后用一个布告板来形象表示刚创建的灯，因为灯在场景中是不可见的。因为灯被挂到animNode结点上，所以布告板bbs也挂到同样的结点上。当然别忘了使用了动画状态来推进动画。

    }
    void postRenderTargetUpdate(const RenderTargetEvent& evt)
    {
        // Show plane
        mPlaneEnt->setVisible(true);
    }
最后要提的是，在每一帧，都要使两个相机的位置，朝向保持一致:
frameStarted:
 mReflectCam->setOrientation(mCamera->getOrientation());
  mReflectCam->setPosition(mCamera->getPosition());

初始化
在初始化之前，必须创建至少一个渲染窗口。因为在分析脚本时可能会创建GPU资源，而后者需要渲染
上下文。
// initialize all of the previously defined resource groups
ResourceGroupManager::getSingleton().initialiseAllResourceGroups();
// or, alternately, initialize the defined resource groups one at a time
ResourceGroupManager::getSingleton().initialiseResourceGroup("General");
ResourceGroupManager::getSingleton().initialiseResourceGroup("Bootstrap");
卸载
可以在任何时候卸载资源（以组或单个的方式）,正在使用的资源不会被卸载。
以组的方式卸载
ResourceGroupManager::getSingleton().unloadResourceGroup("Bootstrap", true);
ResourceGroupManager::getSingleton().
unloadUnreferencedResourcesInGroup("Bootstrap", true);
true表示只卸载资源数据，不删除资源实例，它可以被reloaded。有些资源在创建时被标为
"nonreloadable",这种类型的资源不能使用上述方法卸载。
清理或销毁资源组
清理仅是卸载资源与分离资源索引，销毁不仅做清理的工作，还包括从资源组中把自己移除。
ResourceGroupManager::geSingleton().clearResourceGroup("Bootstrap");
ResourceGroupManager::geSingleton().destroyResourceGroup("Bootstrap");
以个体方式卸载
// assume that pEntity is a valid pointer to an instance of Entity
MeshPtr meshPtr = pEntity->getMesh();
meshPtr->unload();
加载/重载资源组
ResourceGroupManager::getSingleton().loadResourceGroup("Bootstrap", false, true)
二个布尔变量不同资源类型资源加载开关，一针对"Normal"资源，二针对"World geometry"
资源组加载通知
class LoadingProgressListener : public ResourceGroupListener
{
   public: 
        // fired when a group begins parsing scripts
                void resourceGroupScriptingStarted(const String& groupName,
                                                                        size_t scriptCount) {}
       // fired when a script is about to be parsed
               void scriptParseStarted(const String& scriptName) {}
       // fired when the script has been parsed
               void scriptParseEnded() {}
       // fired when all scripts in the group have been parsed
              void resourceGroupScriptingEnded(const String& groupName) {}
      //还有一些接口
}
//实现之后，进行注册
LoadingProgressListener listener(m_progressMeter);
ResourceGroupManager::getSingleton().addResourceGroupListener(&listener);

纹理别名

在源材质被clone时，每个texture unit可以被赋于一个Texture alias(别名）。可以用这个别名来指定使用什么纹理。格式： texture_alias <name> 缺省： texutre_unit <name>( 纹理单元的名字)
texture_unit DiffuseTex
{
  texture diffuse.jpg
}
在这种情况下，texture_alias为DiffuseTex.
material TSNormalSpecMapping
{
  technique GLSL
  {
    pass
    { 
      texture_unit NormalMap
      {
        texture defaultNM.png
        tex_coord_set 0
        filtering trilinear
      }

       texture_unit DiffuseMap
      {
        texture defaultDiff.png
        filtering trilinear
        tex_coord_set 1
      }

        texture_unit SpecMap
      {
        texture defaultSpec.png
        filtering trilinear
        tex_coord_set 2
      }
    } 
  }

  technique HLSL_DX9
  {
    pass
    { 
        texture_unit
      {
        texture_alias NormalMap
        texture defaultNM.png
        tex_coord_set 0
        filtering trilinear
      }

      texture_unit
      {
        texture_alias DiffuseMap
        texture defaultDiff.png
        filtering trilinear
        tex_coord_set 1
      }

      texture_unit
      {
        texture_alias SpecMap
        texture defaultSpec.png
        filtering trilinear
        tex_coord_set 2
      }
    } 
  }
}
例子中有两个技术，都使用相同的纹理,第一个技术使用缺省的方式定义了纹理别名，第二个技术显式地指定纹理别名。两者都有相对应的同样的纹理别名。如果想定义一个材质只是想使用不同的纹理,那么copy父材质时可以使用set_texture_alias来重新指定新纹理。
material fxTest : TSNormalSpecMapping
{
  set_texture_alias NormalMap fxTestNMap.png
  set_texture_alias DiffuseMap fxTestDiff.png
  set_texture_alias SpecMap fxTestMap.png
}
上面代码就对拥有指定别名的texture unit所使用的纹理图片进行了重新指定。

我们知道地形总是起伏不平的，当主角在上面行走时需要根据地形的高度调整，可以光线查询来实现。
原理比较简单：向主角脚下执行光线查询，与地形有一个交点，根据交点的高度调整主角位置。
Terrain Clamping
void Entity::clampToTerrain() {
static Ogre::Ray updateRay;
updateRay.setOrigin(m_controlledNode->getPosition() + Ogre::Vector3(0, 15, 0));
updateRay.setDirection(Ogre::Vector3::NEGATIVE_UNIT_Y);
m_raySceneQuery->setRay(updateRay);
Ogre::RaySceneQueryResult& qryResult = m_raySceneQuery->execute();
if (qryResult.size() == 0) {
// then we are under the terrain and need to pop above it
updateRay.setOrigin(m_controlledNode->getPosition());
updateRay.setDirection(Ogre::Vector3::UNIT_Y);
m_raySceneQuery->setRay(updateRay);
}
qryResult = m_raySceneQuery->execute();
Ogre::RaySceneQueryResult::iterator i = qryResult.begin();
if (i != qryResult.end() && i->worldFragment)
{
Ogre::SceneQuery::WorldFragment* wf = i->worldFragment;
m_controlledNode->setPosition(m_controlledNode->getPosition().x,
i->worldFragment->singleIntersection.y,
m_controlledNode->getPosition().z);
}
}
void Entity::init()
{
// lots of other irrelevant entity init stuff goes here
m_raySceneQuery = sm->createRayQuery(
Ogre::Ray(m_controlledNode->getPosition(),
Ogre::Vector3::NEGATIVE_UNIT_Y));
// move this node is such a way that it is above the terrain
clampToTerrain();
}

下列参数用于提供自己的着色程序时使用，这会提供自己定义的material，那么先前定义的
WorldTexture 与 DetailTexture的设置不再用到，多余的了。

MorphLODFactorParamName=morphFactor　
//假设VertexProgramMorph被设为yes,定制的material中包括一个高级顶点程序。它指定了一个顶点
//程序的参数名，这个参数用于融合LOD,参数值从0－1，0表示不调整，1表示完全调整到下一级LOD
MorphLODFactorParamIndex         //用于materail中包含低级顶点程序的情况，意义同上
CustomMaterialName               //指定的materail名字

上述配置文件定义了基于高度图的地形。这些参数定义可概括为两类：Ogre使用第一类从高度图产生地形
mesh与材质。第二类是定制材质与GPU顶点程序，这可以代替ogre自动产生的着色程序。
另外的说明：
TerrainScenceManager会把高度图分为向个pages,每个page由几个tiles组成.而它们也不过是个方便的名字，
它们都定义了在产生的mesh中一组构成正方形的顶点集。
WorldTexture定义的纹理不必与目标地形一样大。
PageWorldX，PageWorldZ可以缩放世界中的地形。
MaxHeight 在Y方向缩放地形。
DetailTexture 只使用一个纹理，如使用多层纹理，应该使用自定义materail。

从程序加载地形
setWorldGeometry()有重载形式，一种用于加载配置文件，另一种我们可在程序中使用，以
达到手工加载的功能。这里，SceneData被 typedef 为std:map,它存储了如我们在terrain.cfg
中看到那些值对。假设我们已经从某个二进制文件读入我们想要的内容到SceneData中。我们要做
的就是把读入的内容转换成setWorldGeometry()需要的类型。先看一下函数原型：
Ogre::SceneManager::setWorldGeometry (  DataStreamPtr &  stream, 
  const String &  typeName = StringUtil::BLANK
 ) 
DataStreamPtr是一个智能指针,因此从局部变量中返回是安全的,程序相当直观，不再多说了。

Ogre::DataStreamPtr Process_Loader::getSceneDataStream(SceneData &data) {
// create what looks like a config file for the edification of Ogre
std::string mem;
SceneData::iterator it;
for (it=data.begin(); it!=data.end(); it++) {
mem += it->first;
mem += "=";
mem += it->second;
mem += "\n";
}
void *pMem = (void *)new unsigned char[mem.length()+1];
memset(pMem, 0, mem.length()+1);
memcpy(pMem, mem.c_str(), mem.length() + 1);
// stuff this into a MemoryDataStream
Ogre::DataStreamPtr pStr(new Ogre::MemoryDataStream(pMem, mem.length() + 1));
return pStr;
}
// and then elsewhere in the world loader:
Ogre::DataStreamPtr pStr = getSceneDataStream(terrainDef);
m_sceneMgr->setWorldGeometry(pStr);

场景管理器类型

以分析源码的方式讨论一下插件的加载机制与特定场景管理器是如何进行运用的。
上一章提到了以手工的方式初始化ogre,包括手工加载场景管理器：
root->loadPlugin("Plugin_OctreeSceneManager");
其实所谓的自动方式下，Root:Root()中也会间接调用到loadPlugin()方法，这已在前面的笔记
(配置文件Plugins.cfg )中提到过。既然特定管理器以插件的形式（dll文件）给出，下面先看如何
加载dll. 进入源码：标号表明执行顺序。
void Root::loadPlugin(const String& pluginName)
 {
 // Load plugin library
　　　 DynLib* lib = DynLibManager::getSingleton().load( pluginName ); //(1)
  // Store for later unload
 mPluginLibs.push_back(lib); //(4)
 // Call startup function
　　　　DLL_START_PLUGIN pFunc = (DLL_START_PLUGIN)lib->getSymbol("dllStartPlugin"); //(5)
 // This must call installPlugin
 pFunc(); //(6)

 }
DynLib* DynLibManager::load( const String& filename)  //(2)
{
        DynLib* pLib = new DynLib(filename);
 pLib->load();       
        mLibList[filename] = pLib;
 return pLib;
}
void DynLib::load() //(3)
{
m_hInst = (DYNLIB_HANDLE)DYNLIB_LOAD( name.c_str() );
}
第(3)中的宏定义如下：
#if OGRE_PLATFORM == OGRE_PLATFORM_WIN32
#    define DYNLIB_HANDLE hInstance
#    define DYNLIB_LOAD( a ) LoadLibrary( a )
到此，DLL被加载到内存,第(4)步，mPluginLibs是个STL容器，它存放动态库指针。
第(5)步，进入源码可以看到
void* DynLib::getSymbol( const String& strName ) const throw()
    {
        return (void*)DYNLIB_GETSYM( m_hInst, strName.c_str() );
    }
其中宏定义：define DYNLIB_GETSYM( a, b ) GetProcAddress( a, b )，很显然，它取得一个名为
dllStartPlugin的函数指针：不防再看看宏定义： typedef void (*DLL_START_PLUGIN)(void);
说明DLL_START_PLUGIN为参数为空，返回值为空的函数指针。
每个注册到ogre的dll都实现了这个约定函数。对于我们当前讨论的场景管理器Plugin_OctreeSceneManager
来讲，我们可以找到其相应的定义:它在第(6)步中执行

OctreePlugin* octreePlugin;
extern "C" void _OgreOctreePluginExport dllStartPlugin( void )
{
    // Create new scene manager
    octreePlugin = new OctreePlugin();　//(6-1)

    // Register
    Root::getSingleton().installPlugin(octreePlugin); //(6-2)

}
程序执行到(6-1)步，new 来一个OctreePlugin,我们看一下它的定义：
class OctreePlugin : public Plugin
{
 public:
  OctreePlugin();
  const String& getName() const;
  void install();
   void initialise();
   void shutdown();
   void uninstall();
 protected:
  OctreeSceneManagerFactory* mOctreeSMFactory;
  TerrainSceneManagerFactory* mTerrainSMFactory;
  TerrainPageSourceListenerManager* mTerrainPSListenerManager;

};

我们会注意到它包含两个工厂类指针:OctreeSceneManagerFactory,TerrainSceneManagerFactory
他们就是用来生产特定ScenManager的，稍后讨论。先看(6-2)步：
void Root::installPlugin(Plugin* plugin)
{
 mPlugins.push_back(plugin);　　//(6-2-1)
 plugin->install();             //(6-2-2)
 // if rendersystem is already initialised, call rendersystem init too
 if (mIsInitialised)
 {
 plugin->initialise();         //(6-2-3)
 }
}
//(6-2-1)步把插件放到容器中。看看(6-2-2)做了什么：
void OctreePlugin::install()
 {
  // Create objects
  mOctreeSMFactory = new OctreeSceneManagerFactory();
  mTerrainSMFactory = new TerrainSceneManagerFactory();
  mTerrainPSListenerManager = new TerrainPageSourceListenerManager();

 }
呵，刚才还说两个工厂类指针，现在把两个工厂建起来，以后可以用来生产东西了。
继续看看(6-2-3):
void OctreePlugin::initialise()
 {
  // Register
  Root::getSingleton().addSceneManagerFactory(mOctreeSMFactory);
  Root::getSingleton().addSceneManagerFactory(mTerrainSMFactory);
 }
哦，把这两个工厂注册到Root中，让Root可以使用它们。啊这句话有点问题，Root只是间接的用到，
直接雇主是 SceneManagerEnumerator* mSceneManagerEnum;它被包含在Root中。于是我们可以看到
void Root::addSceneManagerFactory(SceneManagerFactory* fact) //(6-2-3-1)
 {
  mSceneManagerEnum->addFactory(fact);
 }

工厂已经有了，我们如何利用这个工厂生产出我们想到的东西(SceneManager)呢？
回忆上一章的手工初始化过程中，我们一般用以下语句来创建SceneManager:
  SceneManager *sceneMgr = root->createSceneManager(ST_GENERIC); //(A)
也可以这样用
  sceneMgr = ogre->createSceneManager("OctreeSceneManager"); //(B)
每个工厂类都用一个字符串表示其类型。上面说的两个工厂分别使用的字符串为：“TerrainSceneManager”，"OctreeSceneManager"
(A)语句肯定会调用工厂类的方法来产生实际的SceneManager,下面看源码验证一下：
SceneManager* Root::createSceneManager(const String& typeName,
  const String& instanceName)
 {
  return mSceneManagerEnum->createSceneManager(typeName, instanceName);
 }
继续挖：
SceneManager* SceneManagerEnumerator::createSceneManager(
  const String& typeName, const String& instanceName)
 {
  SceneManager* inst = 0;
  for(Factories::iterator i = mFactories.begin(); i != mFactories.end(); ++i)
  {
   if ((*i)->getMetaData().typeName == typeName)
   {
    if (instanceName.empty())
    {
     // generate a name
     StringUtil::StrStreamType s;
     s << "SceneManagerInstance" << ++mInstanceCreateCount;
     inst = (*i)->createInstance(s.str());
    }
    else
    {
     inst = (*i)->createInstance(instanceName);
    }
    break;
   }
  }
 }
上述代码很简单：因为执行(6-2-3-1)已经过实际工厂类实例进行了注册。于是遍历每个工厂实例，
找到类型相符的。找到之后，如果没有传场景管理器实例的名字，就起个名字。然后用这个名字
生产出一个实例来。CreateInstance没干什么，new　呗。
SceneManager* OctreeSceneManagerFactory::createInstance(
 const String& instanceName)
{
 return new OctreeSceneManager(instanceName);
}
就是这样。OctreeSceneManager and TerrainSceneManager 的功能都是由一个DLL提供的。它们的关系是：class _OgreOctreePluginExport TerrainSceneManager : public OctreeSceneManager，按照一般的类关系逻辑，
我们知道派生类一般功能都比父类强大，父类应用于一般场景，子类针对特定场景。这个逻辑在这里是对的。本来是写读书笔记，跑题了，打住。

 // tell Root not to load from any plugins or settings file
 Root *root = new Root("", "");

 // Load feature plugins. Scene managers will register
 // themselves for all scene types they support
 root->loadPlugin("Plugin_CgProgramManager");
 root->loadPlugin("Plugin_OctreeSceneManager");

 // load rendersystem plugin(s). The order is important in that GL
 // should be available on on platforms, while D3D9 would be available
 // only on Windows -- the try/catch will intercept the exception in this
 // case where D3D9 is not available and continue gracefully.
 try {
  root->loadPlugin("RenderSystem_GL");
  root->loadPlugin("RenderSystem_Direct3D9");
 }
 catch (...) {}

 try {
  // We'll simulate the selection of a rendersystem on an arbirtary basis; normally
  // you would have your own code to present the user with options and select the
  // rendersystem on that basis. Since a GUI is beyond the scope of this example, we'll
  // just assume the user selected OpenGL.
  RenderSystemList *rList = root->getAvailableRenderers();
  RenderSystemList::iterator it = rList->begin();
  RenderSystem *rSys = 0;

  while (it != rList->end()) {
   
   rSys = *(it++);
   if (rSys->getName().find("OpenGL")) {
   
    root->setRenderSystem(rSys);
    break;
   }
  }

  // check to see if a render system was selected; if we reached the end of the list
  // without selecting a render system then none was found.
  if (rSys == 0) {
   delete root;
   std::cerr << "No RenderSystem available, exiting..." << std::endl;
   return -1;
  }

  // We can initialize Root here if we want. "false" tells Root NOT to create
  // a render window for us
  root->initialise(false);

  // set up the render window with all default params
  RenderWindow *window = rSys->createRenderWindow(
   "Manual Ogre Window", // window title
   800,     // window width, in pixels
   600,     // window height, in pixels
   false,     // fullscreen or not
   0);      // use defaults for all other values

  // from here you can set up your camera and viewports as normal
  // get a pointer to the default base scene manager -- sufficient for our purposes
  SceneManager *sceneMgr = root->createSceneManager(ST_GENERIC);

  // create a single camera, and a viewport that takes up the whole window (default behavior)
  Camera *camera = sceneMgr->createCamera("MainCam");
  Viewport *vp = window->addViewport(camera);
  vp->setDimensions(0.0f, 0.0f, 1.0f, 1.0f);
  camera->setAspectRatio((float)vp->getActualWidth() / (float) vp->getActualHeight());
  camera->setFarClipDistance(1000.0f);
  camera->setNearClipDistance(5.0f);

  // Run the manual render loop. Since we are not using a frame listener in this case, we
  // will count to 15 seconds and then instead of exiting, we'll change the render window settings
  // and re-initialize it.
  bool renderLoop = true;
  Timer *timer = Ogre::PlatformManager::getSingleton().createTimer();
  timer->reset();
  float s = 0.0f;

  while (renderLoop && window->isActive()) {

   renderLoop = root->renderOneFrame();

   // accumulate total elapsed time
   s += (float)timer->getMilliseconds() / 1000.0f;

   // if greater than 15 seconds, break out of the loop
   if (s >= 15.0f)
    renderLoop = false;

   // we must call the windowing system's message pump each frame to
   // allow Ogre to process messages
   //PlatformManager::getSingleton().messagePump();
  }
 }
 catch (Exception &e) {
  std::cerr << e.getFullDescription() << std::endl;
 }

 delete root;
 return 0;
}

视口
通过视口上的一点与相机的原点产生世界空间中的一条光线
// x and y are in "normalized" (0.0 to 1.0) screen coordinates
Ray getCameraToViewportRay(Real x, Real y) const;

视口,创建多个视口，通过Z序（越高越在上）　确定覆盖效果，每个视口可以有不同的背景。
// assume window is a valid pointer to an existing render window, and
// a valid pointer to an existing camera instance
Viewport *vpTop, *vpBottom;
// second parameter is z-order, remaining params are position and size,
vpBottom = window->addViewport(camera, 0);
// create a smaller viewport on top, in the center, 25% of main vp size
vpTop = window->addViewport(camera, 1,
0.375f, 0.375f,
0.25, 0.25);
// set the background of the top window to blue (the default is black
// need to set the bottom window explicitly)
vpTop->setBackgroundColour(ColourValue(0.0f, 0.0f, 1.0f));
// an alternate way to set the color is to use the manifest constant
// vpTop->setBackgroundColour(ColourValue::Blue);
在多视口情况下，overlay缺省在每个视口中渲染。可以关掉。Skybox, Shadow也是如此。
vpTop->setOverlaysEnabled(false);
vpTop->setSkiesEnabled(false);
vpTop->setShadowsEnabled(true);

子系统概览
Root Object
Root 是程序进入点，它是一个façade 类，提供了访问子系统的方便的方法。通过它可以开启ogre,也可能通过它关闭ogre。
资源管理
在渲染场景中使用的任何东西都被视为资源。所有的资源最终都被一个单个类对象管理：ResourceGroupManager，它负责定位资源，初始化资源（不真正装载）。
在缺省情况下，Ogre认识以下类型的资源：
Mesh: 二进制格式，它也可包含 morph 和　pose 动画数据
Skeleton: 　可以被Mesh文件引用，也可单独使用，包含骨骼层次结构信息，关键帧信息。
Material: 　定义了渲染一组几何体时的渲染状态，可以被mesh文件引用，也可以手工使用。
GPU 程序：.program 支持HLSL, GLSL,Cg 与低级的 .asm ，这些文件会在任何.material之间被剖析，因此在一个material之中被引用的Gpu程序总是有效的。
Compositor: 与Material很相似，扩展名不同.
Font: 用字体定义文件去定义在overlay中使用的字体，扩展名 .fontdef
每种资源都有自己的特定的ResourceManager,如，MaterialManager, FontManager。ResourceGroupManager负责通过名字查找资源，它不负责实际的内存管理任务。这些任务是由ResourceManager基类来完成的。ResourceGroupManager允许通过组名来加载，释放整组资源。
默认情况下，Ogre认为资源以一个磁盘文件的形式存在。然而，有些类型的资源可以手工管理，当前只有mesh, font 有手工资源加载的实现。其他类型的可以自己实现，Ogre已经在它的框架中保留了这种功能。
场景管理
所有的具体实现都从SceneManager派生而来，程序中常与此类交互。，可以有多个活动的SceneManager。它们用来管理SceneNode, SceneNode可以在场景中被移动。SceneNode也可以有层次结构。
场景实际内容经常也Entity实例的形式存在。它们被Scene Manager创建，MovableObject实现。一个有效的Entity可以被attach 到SceneNode上面。Entity 经常从磁盘上以 mesh文件加载。然后也可以手工创建内容对象，如plane.当Entity被attach到SceneNode上时，进行移动等操作是针对SceneNode的，而不是内容对象。
也可以把非内容对象(灯，相机等)attach 到SceneNode上面。
渲染系统与渲染对象
RenderSystem 是Ogre与底层API的接口, RenderTarget 是　渲染窗口与渲染纹理的概括。
Ogre 扶持多个渲染窗口。窗口可以通过Root对象自动、手动地创建，也可能通过RenderSystem创建。

Ogre 管理器
Manager 是一个可以访问相关类型对象，管理其生命周期的类。例如，ArchiveManager管理Archive实现的创建与注册，访问注册的Archive实现实例。Root对象创建的副作用之一就是初始化所有ogre Manager对象。
LogManager : 发送日志信息到输出流。
ControllerManager: 管理 controllers,后者是基于各种输入，为别的类产生状态值以供使用。
DynLibManager: 　管理动态链接库
PlatformManager: 把抽象的访问转换成底层硬件与操作系统相关的细节。
CompositorManager: 访问管理　Compoitor framework.
ArchiveManager: 　文件系统目录，ZIP文件
ParticleSystemManager: 粒子系统，发射器，影响器（affector）
SkeletonManager:  允许同名的skeleton对象重用
MeshManager :  管理mesh, 允许同名mesh重用
HighLevelGpuProgramManager: 维护，加载，编译高级GPU程序
GpuProgramManager: 维护低级GPU程序，把编译的高级GPU程序转为汇编
ExternalTextureSourceManager:  管理外部纹理源类实例，如视频流
FontManager:  管理Overlay中使用的字体
ResourceGroupManager: 加载，生命期管理，所有注册的程序资源
OverlayManager: 加载，创建，2D Overlay 类实例
HardwareBufferManager: 管理共享硬件缓冲，　顶点缓冲，像素缓冲，索引缓冲等。
TextureManager: 管理纹理
总结： 这一章无意覆盖关于Ogre的所有东西，只说明了一些普遍需要的Ogre对象，和一些不太常打交道的ogre 对象。

设计哲学
传统上，使用 Direct3D 或 OpenGL 来渲染场景和对象，需要遵循一系列程序处理流的步骤：调用 API 设置渲染状态，调用 API 发送几何体信息，通知 API 或 GPU 去渲染几何体。对每个几何体都是如此返复，直到当前帧被完全渲染。在一下帧同样如此。
使用面向对象的方法来渲染几何体简化了上述过程。通过处理组成场景的各种对象而不是原始的几何体。这些对象包括：可运动对象，静态对象（构成世界布局），光，相机等。那些 3D API 则不再需要：只是把这些对象放到场景中， Ogre 负责处理琐碎的细节。而且，可以用更加直观的方法来操纵对象，而不是使用矩阵。总的说来，我们可以处理对象，它的属性，调用更直观的方法，而不再用顶点列表，三角形列表，旋转矩阵等手段来管理了。
Ogre 提供了面向对象的框架，包括了对象模型中的渲染处理的所有部分。渲染系统抽象了底层 3D 　 API 的复杂性。场景图形功能被抽象成单独的接口，这样一来，各种不同的场景图形管理算法可以即插即用。在场景中的所有可渲染对象，无论是可移动的，还是静态的，都被一组公共接口抽象，这些接口提供了实际的渲染操作（例如 techniques 和它所包含的 passes ） .
设计亮点
一“设计模式”的合理使用
Ogre 中大量使用了经典的设计模式。例如，使用“ Observer ”模式来通知应用程序特定事件的发生，在 demo 中 FrameListener 的使用使得程序可以接收　 frame-started and frame-ended 　事件通知。“ Singleton ”模式强制实现类的单实例。“ Iterator ”模式用来遍历数据结构的内容。
“Visitor” 模式用来在对象上执行某种操作。 Façade 模式用来抽象底层，提供一个单一类接口。
“ Factory” 　用来创建实例。
二 场景图与内容分离
传统上，场景图与内容同处于同一继承体系下。它要求从场景结点子类化内容类，也就是说内容类从场景结点继承。实践证明这种设计非常糟糕。 首先， Ogre 操作场景图形在接口层 , 它不假设特定图形算法的实现。实际上， Ogre 操作场景图形仅仅通过它的签名（方法），完全忽略底层的算法实现。
第二， Ogre 的图形接口只关心图形结构，不包含任何内在的访问或管理功能。后者被推到 Renderable 中，场景中的所有几何（ movable or otherwise ）都从它继承。这些 Renderalbes 的渲染属性（材质， materials ）被包含到 Entity 对象中去。 Entity 可以包含一个或多个 SubEntity 。这些子实体是实际的可渲染对象。下面是各对象的一个关系图：

通过这样的设计，场景管理与场景内容充分解藕。过于场景图来说，通过 Movable Object 几何，渲染属性变得有效。注意到 Movable 不是从 Scene Node 继承而来的。 Movable Object 是 attached 到 Scene Node 上去的 . 当扩展，改变，重构场景图形实现时对场景内容对象的设计与实现没有任何影响。
从另一方面来说，由于场景图形不需要知道内容类的任何变化。只要实现一些简单的场景图形“确实“需要知道的一些接口。因此，我们可以任意的 attached 一些自定义的东西到场景结点上，比如声音信息等。（听说有个 OgreAL, 它包装了 OepnAL ，猜想就是这样做的吧）。
三　插件结构
OGRe 被设计成可扩展的。 Ogre 通过“基于契约的设计 ” 来完成。 Ogre 可以被设计成一组共同工作的组件，它们通过一些已知接口来相互交流。这带来极大的灵活性，某种功能的不同实现与改变非常容易。举例来讲，由于 ogre 处理场景图元管理是在接口级，用户可以随意的选择特定算法的实现。而且，当用户创建一个新的实现，可以很容易的以插件的形式提供给 Ogre, 　实现时只要遵循 ogre 定义的一些接口 . File archives , render systems 也以插件的形式提供，粒子系统也是。 插件形式的吸引人之处是，为了加入插件，不需要重新编译 Ogre 库 . 插件可以在运行时加载。
四　硬件加速的渲染支持
Ogre 被设计成只支持硬件加速图形渲染，直接软件渲染不是它的选项。 Ogre 使用完整的硬件加速能力，包括可编程 shaders 。 Unreal 引擎能做什么， Ogre 就能做什么！！（ ^_^, 作者说的）。引擎直接支持的全局光照 (precomputed Radiance Transfer 等 ) 还没有实现，因为这些多数用于非实时计算场合，因此不是什么问题 .Ogre 现在和未来将可能只使用 Direct3D 与 OpenGL 。
五，灵活的渲染队列结构
Ogre 　采取一个新方法来解决场景中各部分渲染次序问题。粗略地看，标准过程通常如下工作：渲染地形或世界几何，渲染可移动对象，渲染各种特效，渲染 OverLay, 渲染背景或天空盒 . 然而，正如典型的实现一样（像集成电路处理模块），这个过程很难改变 . 在许多例子中， 很难改变渲染的顺序，导致难以维护与不灵活的设计的。 渲染队列的概念是： Ogre 以一次一个的方式渲染一组可以排序的队列，也已同样的方式渲染每个队列中的内容。也就是队列本身有优先级，同样队列中的对象也有自己的优先级。

上图中，队列由后向前渲染（ Background à OveryLay ） , 在最前的队列中从左至右渲染。
在这种机制下重新组织渲染顺序非常简单，只要重新分配优先级就可以了。队列可以定制，队列中的对象也可以。整个队列可以“ turned on” and “turned off” ，队列中的对象也可以。 每个队列提供了事件通知（如 prerender and postrender ） , 应用程序有机会改变队列中的对象渲染。这个机制对于开发和维护复杂程序都相当有用。
六　健壮的材质系统
Ogre 的材质由一个或多个 technique 组成， technique 是 pass 的集合。 Pass 是材质级别的渲染单元，导致一次图形硬件的 ”draw” 调用。可以有多个 pass, 每个 pass 是一次全新的渲染操作，包括硬件渲染状态改变。
最吸引人的特性是 automatic fallback 。 Ogre 自上向下地（ technique 列出的顺序）寻找最适当的 technique.Ogre 还能尽力地重新组织 technique 中的 pass, 以迎合最小的技术需求。例如，当前硬件只支持单纹理单元，而你程序中最小复杂度的技术，需要至少两个纹理单元，那么 ogre 会把一个 pass 拆分成两个，通过混合两个单元纹理的方式达到同样的效果。
Ogre 材质系统也支持 schemes 的概念。 Schemes 可以理解作为普遍的“非常高，高，中，低“不同等级的图形设置。在这种情况下，可以定义四个 schemes , 并为每一个分配 techniques( 复数 ) 。这样就可以 ogre 的所谓 technique fallback 查找那些属于特定 schemes 的 techniques 。使得材质管理更容易点。
用材质脚本完成的事，同样也可以用代码的方式完成。代码的方式也支持 schemes 与 technique fallback 。
七　本地优化的几何与骨骼格式
Ogre 使用它单独的 mesh 与骨骼格式。不能直接加载第三软件包生成的数据。社区中有转换第三文件格式的工具，但它不是 Ogre 库的一部分。 Ogre 使用自己的格式是为了效率。
八　　多种类型的动画
Ogre 支持三种类型的动画：骨骼动画，变形动画， Pose 动画
骨骼动画，把顶点绑定到骨骼上。对象的每个顶点可以受到四个独立的骨头影响。每种影响被赋于一个用数量表示的权重。骨骼动画只在关键帧上执行前向运动学模式。 Ogre 当前不支持逆向动画 .
Morph 动画是一种顶点动画技术，他储存关键帧上的绝对的顶点位置信息，在运行时在两个关键帧之间插值。这与 Pose 动画不同， Pose 动画存储的是偏移数据而不是绝对位置。 Pose 动画可以混合以形成复杂动画。 Morph 动画比 Pose 动画功能有限，因为他存储的是绝对值，因此难以与其他 Morph 动画混合。 Morph 动画与 Pose 动画之间也不能混合 .
所有的动画类型都可以与骨骼动画混合使用 .
所有动画类型都可使用软件执行或是利用 GPU 硬件执行。
Ogre 动画是基于关键帧的，内插方式有线性与立方样条这两种选择。
九　 Compositor Postprocessing ( 怎么翻译 ~?)
用来在一个视口中创建二维的，全屏的后处理效果 . 例如模糊，黑白电视，等等效果（ Ogre 有个很好的示例） Compositor 也有类似于材质系统的 technique 与 pass 的概念。在视口最终被输出前，多个计算与渲染可被执行。像材质的 fallbacks,Compositor framework 提供了 fallback 处理，例如，当输出的像素格式无效时。理解 compositor 最容易的方法是把它当成片段程序（像素渲染）的扩展。不同之处在于：传统的图形管线每个材质 pass 只充许一个片段程序，而 Compositor framework 则可以像打乒乓球一样来来回回好多次。 Compositor 脚本扫行在 ViewPort 上，因此它可以面向任何的 render target, 可以是可渲染纹理，主，副渲染窗口。与材质系统一样，它除了利用脚本实现，也可以使用代码实现。
十   扩展资源管理
在 ogre 中，资源定义为：渲染几何体到可渲染目标上用到任何东西。很明显包括： mesh, 　 skeleton, material , overlay script , font , Compositor script, GPU program , texture 。
每种资源都有自己的 manager, 它主要负责控制特定类型资源在内存中的占用数量。换句话说，它控制着资源实例的生命期。不过仅仅在一点上控制：首先，它只能储存同样多的实例，取决于这种类型的资源所分配的内存。第二， ogre 不会删除正被其他部分引用的实例。
资源本身实际负责加载自己。这是资源系统的一个设计特性：手工资源加载。手工加载意味着资源加载，处理，是利用一个方法调用实现的而不是从文件系统中隐式地加载。
资源在 ogre 中有四种状态：未定义，　声明，未加载，　加载。
未定义，说明 ogre 对它一无所知。
声明，它已经在档案中进行了索引。
未加载，已经进行了初始化（脚本，已经被解析过了），引用已经被创建
加载，已经在它的资源 manager 所管理的内存池中占用空间了。
可以用“组”来管理管理各类资源。组中资源之间的关系是任意的，完全取决于程序员：创建 GUI 的所有资源可以分为一组，以 A 字母开头的资源也可以分为一组，等等。有个 缺省的组：General
在 ogre 中查找某个资源实例时，不会考虑，资源所在的组。有时，我们可以将资源组命当成某种的 ” 命名空间来用“。
Archives 中的资源是非手动加载的。 Archives 是普通文件容器的简单抽象。它包括文件系统与 ZIP 档案。用户可以实现自定义类型的 archive 。

在以前的笔记中已经对 CEGUI 的使用做了简单的介绍，这里为了完整性还是把它 C ＆ P 一下：
使用 cegui 来制作界面 , 不论在何种平台下 , 有基本的三大步骤要做 :
1, 创建一个 CEGUI::Render 实例
2, 创建 CEGUI::System 对象
3, 调用各种方法来渲染用户界面
第一步 , 在我使用的 ogre 环境下使用以下代码来创建 CEGUI::Render 实例
Ogre3D
CEGUI::OgreCEGUIRenderer* myRenderer =
       new CEGUI::OgreCEGUIRenderer(myRenderWindow);
第二步相当简单 , 可使用 new CEGUI::System(myRenderer);
第三步，基本上来讲，大部分平台下，如 direct3D, OpenGL, 我们在渲染循环的尾部调用 CEGUI::System::renderGUI 来开始界面的渲染。如果我们使用 ogre3d 引擎，这一步不需要 我们显示的执行。 创建 CEGUI 窗口，我们可以使用两种形式，一是 C ＋＋代码，二是编辑 XML layout 文件。
CEGUI 本身侦测用户输入，这些不是 CEGUI 的责任，而是程序的员的责任。当有用户外部输入时，我 们可以选择将这些消息告知 CEGUI ，这样 CEGUI 才会响应。
CEGUI 使用回调机制来进行消息处理。可以为某个窗体的特定事件注册一个函数，当窗体事件发生时， CEGUI 会自动调用所注册的函数。
DEMO 中需要注意的是 Render To Texture 的实现。
先创建在 ogre 中的 RTT:
RenderTexture * rttTex = mRoot->getRenderSystem()->createRenderTexture( "RttTex", 512, 512, TEX_
TYPE_2D , PF_R8G8B8 );
再转换成CEGUI可识别的:
// Retrieve CEGUI texture for the RTT
        CEGUI::Texture* rttTexture = mGUIRenderer->createTexture((CEGUI::utf8*)"RttTex");
根据这个Texture生成了一个ImageSet;
在ImageSet中定义了一个Image（名为RttImage）;其大小与上边的Texutre同样大小。
当在窗口中增加一个static Image时，把其image属性设为 ” RttImage ” 即可。

　　1. 在主程序类的 Application :: createScene ( ) 场景创建方法中进行以下工作：

　　Animation * Ogre::SceneManager::createAnimation (
　　 const String & name, // 动画名称
　　 Real length // 动画长度(秒)
　　 ) [virtual]

　　(2) 使用 createTrack 方法为动画创建轨迹动画：
　　 AnimationTrack * Ogre::Animation::createTrack (
　　 unsigned short handle, // 分配给轨迹动画的索引句柄，用于以后可能的调用
　　 Node * node // 指定要沿着这条轨迹运动的节点
　　 )

　　(3) 使用 createKeyFrame 方法为轨迹动画创建一系列关键帧：
　　 KeyFrame * Ogre::AnimationTrack::createKeyFrame (
　　 Real timePos // 时间位置
　　 )
　　
　　 (4) 使用 setTranslate 、 setScale 、 setRotation 三个方法来设置关键帧每个时间位置上节点的位置、缩放、旋转属性：
　　 void Ogre::KeyFrame::setTranslate ( const Vector3 & trans )
　　 void Ogre::KeyFrame::setScale ( const Vector3 & scale )
　　 void Ogre::KeyFrame::setRotation ( const Quaternion & rot )
　　
　　 (5) 使用 createAnimationState 方法创建一个动画状态来追踪这个轨迹：
　　 AnimationState * Ogre::SceneManager::createAnimationState ( const String & animName ) [virtual]
　　
　　 (6) 使用 setEnabled 方法来激活动画状态：
　　 void Ogre::AnimationState::setEnabled ( bool enabled )

　　2. 在接收器类的 Listener::frameStarted(const FrameEvent& evt) 方法中刷新动画状态：
　　 void Ogre::AnimationState::addTime ( Real offset )

资源是 OGRE 应用程序渲染过程中需要用到的纹理图片、网格模型文件、骨骼动画文件的总称。 OGRE 应用程序需要在渲染前将这些资源载入内存，那就需要让 OGRE 引擎知道资源的搜索路径。特别的是 OGRE 引擎支持直接读取 Zip 压缩文件中的内容，所以 Zip 文件也必须被当成搜索路径来指定。在 OGRE 引擎中具有虚拟文件系统的概念，引擎内部载入资源文件都是通过虚拟文件系统来进行的，引擎并不关心资源文件来自一个普通文件夹、 zip 压缩包甚至网络映射。真正的文件读取功能是通过插件来实现的，所以大家在运行环境里可以发现 Plugin_FileSystem.dll ，早期的 OGRE 版本还有 Plugin_Zip.dll ，在新的版本里被实现到引擎内部了。目前还没有实现对网络文件的直接访问。

为了方便 OGRE 程序在运行期间查找资源，使用了资源配置文件 resources.cfg 。这是一个文本文件，我们可以在 OGRE 程序的可执行文件的同一文件夹下找到它。它的内容就是对资源路径的指定，示例如下：

Zip=../../../Media/dragon.zip

Zip=../../../Media/knot.zip

Zip=../../../Media/skybox.zip

FileSystem=../../../Media/

如果资源在一个 Zip 文件中，就写 Zip=****** ，如果资源在一个普通的硬盘文件夹里就写 FileSystem=****** ，通常这两种情况都有。例如在 OGRE 自带的 Demo 中，就将大部分资源放在一个文件夹里，特殊的资源该文件夹中的 Zip 文件里。

在 OGRE 自带的例子框架 setupResources() 展示了 Resources.cfg 文件的使用：先利用 ConfigFile 类对文件内容进行了解析，将资源目录用ResourceGroupManager:: addResourceLocation()向OGRE进行提交;

Plugins.cfg

Ogre的许多功能是以插件的形式提供的.Ogre提供的以Plugin_开头的许多.DLL文件都是所谓的插件。
Plugins.cfg指定了插件的路径和插件文件名, 它们可以放在其它文件夹里，但必须在本文件里指定路径。

在 windows 平台插件的装入过程如下：
Root::()
{
   if(!pluginFileName.empty())
   loadPlugins(pluginFileName);
｝
――――――＞
void Root::loadPlugins(const String& pluginsfile)
{
   ConfigFile cfg;
   cfg.load(pluginsfile);
    ...........................
   // 解析文件，处理后将目录与文件名联接
  for(;;)
   loadPlugin(plugindir + (*it))

} ――――――＞

Root::loadplugin(const string&  pluginName)
{
   DyLibmanager::getsinleton.load(pluginName);
}
――――――＞

DynLibManager::load(const string& filename)

{
        DynLib* pLib=new DynLib(filename);
        pLib->load();
}

――――――＞

void DynLib::load()

{
      m_hInst=(DYNLIB_HANDLE)DYNLIB_LOAD(name.cstr());
}

在 windows 平台下有如下定义：

#define  DYNLIB_LOAD(a)     LoadLibrary(a)

到此， x.dll 插件被加载到内存中，可以使用插件的功能了^_^
以下为一个典型的 Plugins.cfg 文件的内容：

# Defines plugins to load
# Define plugin folder
PluginFolder=.
# Define plugins

Plugin=RenderSystem_Direct3D9
Plugin=RenderSystem_GL
Plugin=Plugin_ParticleFX
Plugin=Plugin_BSPSceneManager
Plugin=Plugin_OctreeSceneManager
Plugin=Plugin_CgProgramManager
Plugins.cfg 文件内容相当直观，不再赘述。

Ogre::Root::showConfigDialog() 会有下述行为：如果程序运行之间已存在一个有效的 ogre.cfg ，那么它会在显示对话框之前将配置文件的内容载入，如果用户对对话框进行了操行，改变的配置参数， showConfigDialog() 会根据用户的新选择依次调用 Root::setRenderSystem, RenderSystem::setConfigOption and Root::saveConfig （在 ogreWin32ConfigDialog.cpp 中实现，写自己的配置对话框时可以参考），需要注意的是配置好的参数，只是在 RenderSystem::initialise or RenderSystem::reinitialise 调用之后才被激活。 以下为典型的 ogre.cfg 文件的内容
Render System=Direct3D9 Rendering Subsystem
[Direct3D9 Rendering Subsystem]
Allow NVPerfHUD=No
Anti aliasing=None
Floating-point mode=Fastest
Full Screen=No
Rendering Device=ATI MOBILITY RADEON X300
VSync=No
Video Mode=800 x 600 @ 32-bit colour

[OpenGL Rendering Subsystem]
Colour Depth=32
Display Frequency=N/A
FSAA=0
Full Screen=No
RTT Preferred Mode=FBO
VSync=No
Video Mode=1024 x 768

方括号中为可以选择的渲染子系统，而第一行指出了当前的选择是哪个子系统，方括号下面为各子系统的可选参数，在上的例子中分别列出了 Direct3D 9 与 OpenGL 子系统的可选配置参数。
Root(const String& pluginFileName = "plugins.cfg", const String& configFileName = "ogre.cfg", const String& logFileName = "Ogre.log");         ~Root();
Root 的构造函数传递了ogre.cfg,只是简单的将文件名保存下来，供其它方法使用，如上面曾经提到过的 Root:saveConfig(void);

1.  Create the DirectInput object. You use methods of this object to enumerate devices and create DirectInput device objects.

2.  Enumerate devices. This is not an essential step if you intend to use only the system mouse or keyboard. To ascertain what other input devices are available on the user's system, have DirectInput enumerate them. Each time DirectInput finds a device that matches the criteria you set, it gives you the opportunity to examine the device's capabilities. It also retrieves a unique identifier that you can use to create a DirectInput device object representing the device.

3.  Create a DirectInputDevice object for each device you want to use. To do this, you need the unique identifier retrieved during enumeration. For the system mouse or keyboard, you can use a standard GUID.

4.  Set up the device. For each device, first set the cooperative level, which determines the way the device is shared with other applications or the system. You must also set the data format used for identifying device objects, such as buttons and axes, within data packets. If you intend to retrieve buffered data—that is, events rather than states—you also need to set a buffer size. Optionally, at this stage you can retrieve information about the device and tailor the application's behavior accordingly. You can also set properties such as the range of values returned by joystick axes.

5.  Acquire the device. At this stage you tell DirectInput that you are ready to receive data from the device.

6.  Retrieve data. At regular intervals, typically on each pass through the message loop or rendering loop, get either the current state of each device or a record of events that have taken place since the last retrieval. If you prefer, you can have DirectInput notify you whenever an event occurs.

7.  Act on the data. The application can respond either to the state of buttons and axes or to events such as a key being pressed or released.

8.  Close DirectInput. Before exiting, your application should unacquire all devices and release them, then release the DirectInput object.

了解了这些基本步骤，下面我们打开OIS的源码，看看上面这8步骤封装到了哪里。然后我们返回 ExampleFrameListener, 看看 demo 中是如何使用 OIS 的 .
第一个要看的是InputManager类。他提供了平台无关的接口，负责输入系统的创建。没啥好说的，看源码吧(只列出核心代码)：
InputManager * InputManager::createInputSystem( ParamList &paramList )
{    
      InputManager* im = 0;
      #elif defined OIS_WIN32_PLATFORM 
           im = newWin32InputManager();
    #endif 
       im->_initialize(paramList); 
    return im;
}
自然，我们只关心windows平台下的。于是找到源码继续看:
void Win32InputManager::_initialize( ParamList &paramList )
{ 
  //Create the device 
   hr = DirectInput8Create(hInst, DIRECTINPUT_VERSION, IID_IDirectInput8, (VOID**)&mDirectInput, NULL );
   /Ok, now we have DirectInput, parse whatever extra settings were sent to us 
    _parseConfigSettings( paramList ); 
    _enumerateDevices();
}

首先，完成了8步骤中的第1步， Create the DirectInput object 。 在_parseConfigSettings ( paramList ); 中对以后将要创建的设备（键盘，鼠标等）的属性，例如独占模式，前台模式等。这些属性列表paramList   经过处理后，之后在创建设备的时候传入。
void Win32InputManager::_enumerateDevices()
{     //Enumerate all attached devices 
    mDirectInput->EnumDevices(NULL, _DIEnumKbdCallback, this, DIEDFL_ATTACHEDONLY);
}

完成了8步骤中的第2　部分 Enumerate devices ，它是针对游戏杆这类设计的，对于键盘，鼠标并不需要。InputManager 创建之后，就可以用它来创建键盘，鼠标了。它提供了如下的方法：
Object * Win32InputManager::createInputObject( TypeiType, boolbufferMode )
{   
  Object* obj = 0;   
    switch( iType ) 
    { 
    case OISKeyboard: obj = newWin32Keyboard( this, mDirectInput, bufferMode, kbSettings ); break; 
    case OISMouse: obj = newWin32Mouse( this, mDirectInput, bufferMode, mouseSettings ); break; 
    obj->_initialize(); 
    return obj;
}

鼠标，键盘都有各自的类封装。下面以键盘为例，看看它的源码中都做了些什么：
void Win32Keyboard::_initialize()
{

1      mDirectInput->CreateDevice(GUID_SysKeyboard, &mKeyboard, NULL);

2      mKeyboard->SetDataFormat(&c_dfDIKeyboard)

3      HWNDhwin = ((Win32InputManager*)mCreator)->getWindowHandle();

4      mKeyboard->SetCooperativeLevel( hwin, coopSetting)))

5      mKeyboard ->SetProperty( DIPROP_BUFFERSIZE, &dipdw.diph )))

6      HRESULThr = mKeyboard->Acquire(); 

}

这里可是做了不少的工作,看看方法名就可以明白。为说明方便加上了标号。
1， 它做了8步骤中的第3步， Create a DirectInputDevice object for each device you want to use 。
2, 3 4,5它们共同做了8步骤中的第4步－ Set up the device 。这里面包括：设置键盘的数据格式，协作模式，其他属性。很明显，6做了8　步步骤中的第5步－ Acquire the device 。 意思是告诉DirectInput,我准备从设备上获取数据了，给我做好生伺侯着。准备工作都做好了，可以获取数据了，通过设备提供的下面这个方法来做这件事。这就是8　步骤中的第6件事- Retrieve data
void Win32Keyboard::capture()
{     if( mBuffered ) 
       _readBuffered(); 
       else 
       _read();
}

从源码中我们可以看到，根据数据的不同，进行了不同的处理。呵，什么不同呢，再从MSDN上抄一段吧，一看就明白： Buffered and Immediate Data
DirectInput supplies two types of data: buffered and immediate. Buffered data is a record of events that are stored until an application retrieves them. Immediate data is a snapshot of the current state of a device. You might use immediate data in an application that is concerned only with the current state of a device - for example, a flight combat simulation that responds to the current position of the joystick and the state of one or more buttons. Buffered data might be the better choice where events are more important than states - for example, in an application that responds to movement of the mouse and button clicks. You can also use both types of data, as you might, for example, if you wanted to get immediate data for joystick axes but buffered data for the buttons.

呵，清楚了吧。继续看代码, capture()有两个分枝，分别处理缓冲数据与立即数据。
首先是缓冲数据，主干代码如下：
void Win32Keyboard::_readBuffered()
{
  DIDEVICEOBJECTDATA diBuff[KEYBOARD_DX_BUFFERSIZE]; 
    DWORD entries = KEYBOARD_DX_BUFFERSIZE;  
   mKeyboard->GetDeviceData( sizeof(DIDEVICEOBJECTDATA), diBuff, &entries, 0 ); 
    //Update keyboard and modifier states.. And, if listener, fire events 
    for(unsignedinti = 0; i < entries; ++i ) 
    { 
       KeyCode kc = (KeyCode)diBuff[ i ].dwOfs; 
                     if( diBuff[ i ].dwData & 0x80 ) 
       { 
          if( listener ) 
            istener->keyPressed( KeyEvent( this,kc,_translateText(kc) ) ); 
       } 
       else
       { 
           //Fire off event 
           if( listener ) 
            listener->keyReleased( KeyEvent( this, kc, 0 ) ); 
       } 
    }
}

这段代码中，GetDeviceData( sizeof(DIDEVICEOBJECTDATA), diBuff, &entries, 0 );取得了缓冲数据,添入了一个数组：尺寸是EYBOARD_DX_BUFFERSIZE,可以看到entries也等于此值。Entries的作用除了开始调用时说明数组的大小，同时在函数调用返回时说明数组里有多少个数据填入（没有足够多的缓冲数据，当然填不满啦，假如entries返回6，说明还有6个按键信息在缓冲里等待处理）。很明显，for循环就是对这些未处理的信息进行处理。KeyCode kc = (KeyCode)diBuff[ i ].dwOfs; 这是看看，这个事件是由哪个键引走.KeyCode是个枚举型：
enum KeyCode 
    { 
    　  C_1           = 0x02, 
       KC_2            = 0x03, 
       KC_3            = 0x04, 
       KC_A            = 0x1E, 
       KC_S            = 0x1F, 
       KC_D            = 0x20, 
    }

确定了是哪个键，接下来就要问了，是按下还是释放？
 if ( diBuff[ i ].dwData & 0x80 ) 　回答了这个问题,下面做的是
if ( listener ) 
            istener->keyPressed( KeyEvent( this,kc,_translateText(kc) ) );

它把相关的信息内容包装成KeyEvent，作为参数发给了，已经注册了的侦听者.可能不太明白，解释一下：当我们按下了某个键，可以认为是发生了个KeyEvent,程序里会响应这个事件，方法就是把某个类实例注册为侦听者(listener),说白了就是告诉OIS,当键盘按下释放的时候你告诉我啊，我要响应他。这里OIS检测到按键事件发生了，根据侦听者的请求，调用侦听者的方法(keyPressed)。也许有疑问，OIS 怎么知道侦听者实现了keypressed（）方法呢？不急先看以下代码，在GUI demo里：
class GuiFrameListener : publicExampleFrameListener, publicOIS::KeyListener, publicOIS::MouseListener
看到了吧，它继承自  OIS:KeyListener ,从OIS的源码中找到它：
class _OISExport KeyListener 
    { 
    public: 
       virtual ~KeyListener() {} 
       virtual bool keyPressed( constKeyEvent &arg ) = 0; 
       virtual bool keyReleased( constKeyEvent &arg ) = 0;    
    };
哈哈，他正是定义了这两个接口，既然继承自他，当然也就拥有了这两个接口，于是GuiFrameListener成了合理合法的Listener了。
哦，它在哪里注册的呢？很简单.在GuiFrameListener的构造函数里我们看到：
{
       mMouse ->setEventCallback(this); 
       mKeyboard->setEventCallback(this);
}
继续挖源码：
virtual void Keyboard : ：setEventCallback ( KeyListener *keyListener ) {listener=keyListener;}
这下应该就明白了吧。很明显GUI Demo里使用了缓冲模式.
剩下来就是立即模式的数据了，他很好理解：
void Win32Keyboard::_read()
{ 
  mKeyboard->GetDeviceState( sizeof(KeyBuffer), &KeyBuffer ); 
}
它把键盘当下的状态保存到缓冲中去，要想知道哪个键是否按下，只要对照缓冲“按图索骥”就可以了。
 bool Win32Keyboard::isKeyDown( KeyCodekey )
{ 
    return (KeyBuffer[key] & 0x80) != 0;
}
这个键按下了吗？那个键按下了吗？那那个呢？呵，真啰嗦，得一个个的问。
于是我们 GUI Demo 中可以看到下列的代码：
virtual bool processUnbufferedKeyInput(const FrameEvent& evt) 
       { 

            if(mKeyboard->isKeyDown(KC_A)) 
                      mTranslateVector.x = -mMoveScale;    // Move camera left 
            if(mKeyboard->isKeyDown(KC_D)) 
                    mTranslateVector.x = mMoveScale;      // Move camera RIGHT 
              if(mKeyboard->isKeyDown(KC_UP) || mKeyboard->isKeyDown(KC_W) ) 
                     mTranslateVector.z = -mMoveScale;     // Move camera forward 
              if(mKeyboard->isKeyDown(KC_DOWN) || mKeyboard->isKeyDown(KC_S) )  
                    mTranslateVector.z = mMoveScale;      // Move camera backward
｝

我们用键盘要不是缓冲模式，要么立即模式，不可能一起上，这所有在 demo 中都能看到， demo 的作者懒得多写代码 ( 嘿嘿 ) ，它继承了 ExampleFrameListener 的许多功能，而 ExampleFrameListener 也实现了些立即模式的按键处理。 Demo 没有用到。写了这么多了，还得 8 　大步骤？？ 该第 7 步了吧： ―― Act on the data ， 这有什么好说的呢？爱咋咋地！最后一步，第 8 步――天龙八部 ! 呵错了，是 Close DirectInput      其实很简单， OIS 把他们封装在各个类的析构函数里了，想当然，源码也不用贴了 . 说了 OIS 　如何把 DirectInput 封装起来，参考 8 大步骤，如何使用 OIS 也基本很明白了。OIS ，就学到这里，接下来该主角上场 CEGUI 得休息了，打字，翻资料，看代码，很累了。

下面直接涉及到相关类

首先看一下 ExampleFrameListener, 下面是类间关系图

 
ExampleFrameListener 继承了 FrameListener, 因此拥有了它的两个方法

virtual bool frameStarted(constFrameEvent& evt)

virtual bool frameEnded(constFrameEvent& evt)

在 ExampleApplication 中将它们注册到 ogre 中，在适当的时候， ogre 会调用这两个方法 . 下面是注册地点与时机

virtual void ExampleApplication::createFrameListener(void)

    {

        mFrameListener= newExampleFrameListener(mWindow, mCamera);

        mFrameListener->showDebugOverlay(true);

        mRoot->addFrameListener(mFrameListener);

}

createFrameListener 在 ExampleApplication::setup() 中被调用.

ExampleFrameListener 又继承了 WindowEventListener.

WindowEventListerner 在ogre 1.4中是新加的。按照手册：它是一个 Callback class used to send out window events to client app. 它定义以下四个接口,而显然例子程序中只用到了两个
virtual void windowMoved(RenderWindow* rw)   {}

virtual void windowResized(RenderWindow* rw) {}

virtual void windowClosed(RenderWindow* rw)  {}

virtual void windowFocusChange(RenderWindow* rw) {}

这种所谓的回调类如何实现？下面只说明windows操作系统的情况。

我们知道，windows操作系统监视系统中发生的一切，通过消息的方式通知相应的窗口。每个窗口类注册的时候，都指明一个回调过程，在那里处理传来的消息。应用程序又有各自的消息队列，从消息队列中取得消息，然后分开给各窗口.

不防从ogre的源码中看看上述windows基本过程如何实现，这有助理解回调类的实现过程：

首先，ogre可以为我们创建一个窗口：

mWindow = mRoot->initialise(true);//

于是我们进入到initialise()中看看吧，它倒底做了些什么事情。

RenderWindow * Root::initialise(boolautoCreateWindow, constString& windowTitle)

{

// ……

mAutoWindow =  mActiveRenderer->initialise(autoCreateWindow, windowTitle);

// 这里：RenderSystem* mActiveRenderer

// ……

}

mActivaRenderer 只是接口，不用实际的事情，实际的工作由它的子类完成，现只看DirectX实现:

RenderWindow * D3D9RenderSystem::initialise( boolautoCreateWindow, constString& windowTitle )

{

// ……………………

autoWindow = this->createRenderWindow( windowTitle, width, height,

              fullScreen, &miscParams );

// ………………… ..

}

好，继续下去,看看createRenderWindow做了些什么

RenderWindow * D3D9RenderSystem::createRenderWindow(constString &name,

       unsigned int width, unsignedintheight, boolfullScreen,

       const NameValuePairList *miscParams)

{

// …………… ..

RenderWindow * win = newD3D9RenderWindow(mhInstance, mActiveD3DDriver,

           mPrimaryWindow ? mpD3DDevice : 0);

win ->create( name, width, height, fullScreen, miscParams);

// ………………

}

继续

void D3D9RenderWindow::create(constString& name, unsignedintwidth, unsignedintheight,

       bool fullScreen, constNameValuePairList *miscParams)

{

// Register the window class

// NB allow 4 bytes of window data for D3D9RenderWindow pointer

    WNDCLASS wc = { 0, WindowEventUtilities::_WndProc, 0, 0, hInst,

           LoadIcon(0, IDI_APPLICATION), LoadCursor(NULL, IDC_ARROW),

              (HBRUSH)GetStockObject(BLACK_BRUSH), 0, "OgreD3D9Wnd" };

           RegisterClass(&wc);

// 定义了窗口类，并且进行注册，需要注意的是，你看看它把窗口类的回调函数的值设为了什么？先记住，一会儿讨论它吧。

           // Create our main window

           // Pass pointer to self

           mIsExternal = false;

           mHWnd = CreateWindow("OgreD3D9Wnd", title.c_str(), dwStyle,

              mLeft, mTop, mWidth, mHeight, parentHWnd, 0, hInst, this);

// 调用win32API把窗口真正Create出来了

WindowEventUtilities ::_addRenderWindow(this);

// 这一步也要注意到

}

继续

void WindowEventUtilities::_addRenderWindow(RenderWindow* window)

{

    _msWindows.push_back(window);

}

_msWindows 定义为：

typedef std::vector<RenderWindow*> Windows;

 static Windows _msWindows;

，没什么，只是个stl容器，把生成的窗口放进去了.

到现在，容器类注册好了，回调函数也指定了，窗口也创建出来了。现在我们继续思考我们最最初的问题： WindowEventListerner 这个回调类是如何实现所谓的回调机制的，也就是说windowEventListerner不是定义了四个接口，它响应特定的windows事件，我们要讨论的就是这四个接口方法如何被调用起来，实现所谓的回调机制。 还记得注册窗口类的回调函数是什么吧，

WindowEventUtilities::_WndProc ， 呵呵，只要在那里调用上述四个接口函数就好了。

哪问题又来了，_WndProc到哪里找这四个接口函数呢？

在 ExampleFrameListener 类的构造函数里我们可以看到如下代码

//Register as a Window listener

WindowEventUtilities::addWindowEventListener(mWindow, this);

啊，这就是奥秘所在!到源码中看看吧。

void WindowEventUtilities::addWindowEventListener( RenderWindow* window, WindowEventListener* listener )

{

    _msListeners.inser t(std::make_pair(window, listener));

}

-msListeners 被定义成这样子：

typedef std::multimap<RenderWindow*, WindowEventListener*> WindowEventListeners;

static WindowEventListeners _msListeners;

没有什么，就是STL容器，它使得窗口(RenderWindow)与(WindowEventListener)

组成了亲密派对，窗口有了什么消息，就可以用对应的回调类响应。

只剩下一点秘密了，到底怎么调用起来的呢，某某某说过，源码之下，了无秘密，那就看源码吧：

LRESULT CALLBACK WindowEventUtilities::_WndProc(HWNDhWnd, UINTuMsg, WPARAMwParam, LPARAMlParam)

{

WindowEventListeners ::iteratorstart = _msListeners.lower_bound(win),

                     end = _msListeners.upper_bound(win);

// 为遍历做准备

    switch( uMsg )   // 消息真的来了

  {

case WM_MOVE:

       //log->logMessage("WM_MOVE");

       win->windowMovedOrResized();

       for( ; start != end; ++start )

           (start->second)->windowMoved(win);

       break;

    case WM_SIZE:

       //log->logMessage("WM_SIZE");

       win->windowMovedOrResized();

       for( ; start != end; ++start )

           (start->second)->windowResized(win);

       break;

}

}

就这样，四个接口函数被调用起来了！

也许，也许，关于消息还有些要说明的。消息如何泵出来的？

当看到了如下代码，突然就想找个朋友，会心一笑.

void WindowEventUtilities::messagePump()

{

    MSG   msg;

    while( PeekMessage( &msg, NULL, 0U, 0U, PM_REMOVE ) )

    {

       TranslateMessage( &msg );

       DispatchMessage( &msg );

    }

}

打破铁锅问到底吧，它又如何被调用起来？

void Root::startRendering(void)

    {

        while( !mQueuedEnd )

        {

           //Pump messages in all registered RenderWindow windows

           WindowEventUtilities::messagePump();

           if (!renderOneFrame())

                break;

        }

}

就是这里了。写的乱七八糟，脑子也乱七八糟，梳理一下吧。

首先，mWindow = mRoot->initialise(true);初始化，随便通过一系统连锁反应create出来一个窗口，并把它的回调函数设定为 WindowEventUtilities::_WndProc.

ExampleFrameListener 继承了 WindowEventListener 的四个约定接口函数。并且在它的构造函数里调用 WindowEventUtilities::addWindowEventListener(mWindow, this); 进行了注册，以便特定窗口消息发生时进行响应. Root ::startRendering （）进入了渲染循环，渲染每一帧前，检测widnows消息，并进行分发。于是消息进入到窗口类的回调函数_WndProc,在函数内部根据消息的不同，分别调用已注册的侦听器的约定接口函数。
先写到这里吧，原来只是想写写CEGUI的使用，谁知已经写了这么多了，CEGUI还一字未提。脑子乱了，先休息吧。下面还得说说OIS,CEGUI又得靠后了.

    if (ImmIsIME(GetKeyboardLayout(0)))
    {
     CEGUI::DbcsSupport::injectChar(Key);
    }
    else
    {
     CEGUI::System->injectChar((CEGUI::utf32)Key);
    }

    ImmIsIME(GetKeyboardLayout(0))目的是用于检则现在的输入法是否打开的。如果是在输英文状态我想你不会画蛇添足的。使用这个需要imm32.lib的支持。MSDN上面也有说明。
5:最后就是添加一份代码到你的CEGUI使用项目里，如下：
namespace CEGUI{
bool DbcsSupport::injectChar(utf32 code_point )
 {
#ifndef UNICODE
  static char     s_tempChar[3]  = "";
  static wchar_t  s_tempWchar[2] = L"";
  static bool s_flag = false;
  unsigned char  uch  = (unsigned char)code_point;
  if( uch >= 0xA1 )
  {
   if( !s_flag )
   {
    s_tempChar[0] = (char)uch; //第一个字节
    s_flag = true;
    return true;
   }
   else if( uch >= 0xA1 )
   {
    s_tempChar[1] = (char)uch; //第二个字节
    s_flag = false;
    MultiByteToWideChar( 0, 0, s_tempChar, 2, s_tempWchar, 1); //转成宽字节
    s_tempWchar[1] = L'\0';
    utf32 code = (utf32)s_tempWchar[0];
    //Font* fnt = System::getSingleton().getDefaultFont();
    return CEGUI::System::getSingleton().injectChar( code );
   }
   else
   {
    return CEGUI::System::getSingleton().injectChar(code_point);
   }
  }
  else
  {
   s_flag = false;
   return CEGUI::System::getSingleton().injectChar(code_point);
  }
#else
  return CEGUI::System::getSingleton().injectChar(code_point );
#endif
 }
}

Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=1509217

EventClicked :: 系统预定义的事件 . subscribeEvent:: 注册函数，它事件与响应函数联接在一起。
在 ogre 程序中，当侦听器收到键盘，鼠标消息时，首先经过适当的转换（ CEGUI 可以识别）再传递给 CEGUI 。下面这个函数执行鼠标键标识转换。
CEGUI::MouseButton convertOgreButtonToCegui(int buttonID)
{
       switch (buttonID)
       {
       case MouseEvent::BUTTON0_MASK:
              return CEGUI::LeftButton;
       case MouseEvent::BUTTON1_MASK:
              return CEGUI::RightButton;
       case MouseEvent::BUTTON2_MASK:
              return CEGUI::MiddleButton;
       case MouseEvent::BUTTON3_MASK:
              return CEGUI::X1Button;
       default:
              return CEGUI::LeftButton;
       }
}

将 CEGUI 需要知道的键盘，鼠标消息告知它。即在 OGRE 处理这些消息时通知 CEGUI 。以下这函数说明了用法。
       void mouseMoved (MouseEvent *e)// 鼠标移动
       {
              CEGUI::System::getSingleton().injectMouseMove(
                   e->getRelX() * mGUIRenderer->getWidth(),
                   e->getRelY() * mGUIRenderer->getHeight());
                   e->consume();
       }

       void mousePressed (MouseEvent *e)// 鼠标按下
       {
              CEGUI::System::getSingleton().injectMouseButtonDown(
               convertOgreButtonToCegui(e->getButtonID()));
             e->consume();
       }
       void mouseReleased (MouseEvent *e)// 鼠标弹起
       {
              CEGUI::System::getSingleton().injectMouseButtonUp(
              convertOgreButtonToCegui(e->getButtonID()));
              e->consume();
       }

       void keyPressed(KeyEvent* e)// 键按下
       {
              CEGUI::System::getSingleton().injectKeyDown(e->getKey());
              CEGUI::System::getSingleton().injectChar(e->getKeyChar());
              e->consume();
       }
       void keyReleased(KeyEvent* e)// 键弹起
       {
             CEGUI::System::getSingleton().injectKeyUp(e->getKey());
             e->consume();

       }
在 CEGUI 中使用中文的问题：   现在总结了一下在 CEGUI 中显示中文需要注意的事项 :
    1 、将 simhei.ttf copy to \ogrenew\Samples\Media\gui
    2 、将 simhei-12.font  拷到上目录内容为
<?xml version="1.0"  ?>
<Font Name="SimHei-12" Filename="simhei.ttf" Type="Dynamic" Size="12" NativeHorzRes="800" NativeVertRes="600" 
AutoScaled="true">
<GlyphSet Glyphs=" 你好世界退出演示渲染到新材质建编辑窗口 " /> （ <---- 自己要用到的汉字）
</Font>
注意大小写！！ GlyphSet Glyphs 是在程序中要用到的汉字，它是让 cegui 预生成一个字符图像集用的（想当然的 :-P ）如果修改了这个文件，注意要用 Unicode （ UTF-8 ）的编码来保存，在 vc7.1 中：文件 -> 高级保存选项   的   编码   栏中选择。
    3 、在 TaharezLook.scheme 中
     <Font Name="Tahoma-12" Filename="tahoma-12.font" /> 后加入
     <Font Name="SimHei-12" Filename="simhei-12.font" />  注意大小写
     以上是一些准备工作
    4 、在自己的应用中设置默认字体
    mGUISystem->setDefaultFont((CEGUI::utf8*)"Tahoma-12"); 改为
    mGUISystem->setDefaultFont((CEGUI::utf8*)"SimHei-12");
    5 、在自己的应用程序中就可以把相关的 Text 属性该为中文了，如：
    item = new CEGUI::ListboxTextItem((CEGUI::utf8*)" 退出 ", 6);
    同样要注意的是要保存为 Unicode （ UTF-8 ）的编码。同时这些字要是在 simhei-12.font 中定义过的字，当然也可以象那个 CEGUIChieseDemo
那样用动态生成如：
    gfont->defineFontGlyphs(gfont->getAvailableGlyphs() + (utf8*)" 当前最佳坏平均的框架率三角 ");
    编译自己的程序，应该就可以看到中文了，罗嗦一下，记住只要有汉字出现的文件就保存为 Unicode （ UTF-8 ）编码的！！！