}
首先，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 以一次一个的方式渲染一组可以排序的队列，也已同样的方式渲染每个队列中的内容