Ogre中Mesh的加载与渲染流程

 

  如果新开始写一个3D渲染引擎，Mesh应该是一个很好的切入点。当一个看似简单的Mesh渲染到窗口时，说明引擎的架构已经确定，并验证了。想了解Ogre内部的机制， 可以先看看Mesh的加载过程，这里主要涉及到Resource是如何管理的，Material是怎样处理的，Resource和HardwareBuffer是如何关联的。对于前面教程代码的执行过程做一下分析：

创建一个Entity（加载Mesh及其相关的Material）的调用流程如下：

 

SceneManager::createEntity()

->SceneManager::createMovableObject()

->MovableObjectFactory::createInstance()

->EntityFactory::createInstanceImpl()

主要的操作就在这个函数中完成，其中第一步为加载Mesh，Mesh包含若干SubMesh，此时并不加载相关的材质，只是记录所关联的材质名称；

-->MeshManager::load()

-->Mesh::load()

-->Mesh::loadImpl()

-->MeshSerializer::importMesh()

 

第二步为new一个Entity对象，其中包含创建SubEntity对象并加载相关的“材质”。

-->Entity::Entity()

-->Entity::buildSubEntityList()

-->SubEntity::setMaterialName()

-->Material::loadImpl()

-->Material::compile()

下面是相关的一个class的UML图：

首先一个Entity对象必须Attach到一个SceneNode。
1．  创建一个SceneNode：
SceneManager::getRootSceneNode() （在SceneManager::init时会创建一个RootNode）
-> SceneNode::createChildSceneNode()
->Node::createChild()
主要的操作在这个函数中完成，首先调用虚函数SceneNode::createChildImpl（），此函数又会调用OctreeSceneManager::createSceneNode（），此函数会new一个SceneNode的派生类对象，这里是OctreeNode，并加入到SceneNodeList mSceneNodes中；随后又进行了坐标变换；最后将此指针又加入到ChildNodeMap mChildren中，然后返回此指针；
2．  将Entity Attach到SceneNode：SceneNode:: attachObject()；
3．  渲染从Root::startRendering()函数开始，此函数启动一个循环，每次执行Root::renderOneFrame（）
->Root::_updateAllRenderTargets
->RenderSystem::_updateAllRenderTargets()
->RenderWindow::update()
->D3D9RenderWindow::update(bool swap)
->RenderTarget::update()
->Viewport::update()
->Camera::_renderScene()
->SceneManager::_renderScene(Camera* camera, Viewport* vp, bool includeOverlays)
4．  绕了好大一圈，才来到了SceneManager::_renderScene()，此函数想必是渲染的主要操作所在；
5．  SceneManager:: _updateSceneGraph()从root node开始递归的调用了所有scene node的update，主要是计算了transform；
6．  给AutoParamDataSource设置了一系列参数，这个类是用来为gpu programs提供一些参数的；
7．  SceneManager::prepareRenderQueue（）。这里有一个Ogre场景管理的概念RenderQueue。粗略的看，这个类主要是为了把Objects按照材质分组，它还将管理对象的渲染优先权；
8．  OctreeSceneManager::_findVisibleObjects（）
-> OctreeSceneManager::walkOctree
-> OctreeNode::_addToRenderQueue
如果想显示包裹盒的话，则会调用” sn->_addBoundingBoxToQueue(queue);”
可见这个操作利用SceneManager的空间管理算法来对所有的SceneNode进行了可见性判断，如果可能可见，则加入到RenderQueue中；
9．  在计算好了RenderQueue之后，开始调用RenderSystem的一系列函数，例如_setProjectionMatrix等等开始为真正的渲染操作做好准备；
10．              SceneManager::_renderVisibleObjects，渲染操作就在这里了。
->SceneManager::renderVisibleObjectsDefaultSequence
-> SceneManager::_renderQueueGroupObjects
->SceneManager::renderBasicQueueGroupObjects（此函数遍历RenderQueueGroup中的每个RenderPriorityGroup，然后先渲染solids，再渲染transparents）
-> SceneManager::SceneMgrQueuedRenderableVisitor::visit
11．              à SceneManager::renderSingleObject，此函数设置了灯光、GPU programs，然后使用一个RenderOperation对象来调用D3D9RenderSystem::_render，也就是真正的Draw call。RenderOperation对象是由SubEntity::getRenderOperationà SubMesh::_getRenderOperation来设置的，主要是IndexData和VertexData。

这里有几个细节需要注意：
1．  在SceneManager::renderObjects函数中用到了一个visitor模式来访问QueuedRenderableCollection（这个类的实例用来在RenderPriorityGroup中包括solids、transparents等等）。
2．  Entity是从MoveableObject派生的，而SubEntity才是从Renderable派生的；
3．  一个SceneNode可以Attach多个Entity；实际上SceneNode可以Attach任何的MoveableObject；
4．  前面只提到了IndexData和VertexData，而对于渲染来说Material更是关注的焦点，Mesh的材质是如何与RenderSystem交互的呢？
 
总结：SceneManager进行可见性判断之后，形成一个RenderQueue，然后对于队列中的每个Object再使用RenderOpertation与RenderSystem联系，来执行渲染操作。
总体感觉有些地方相当复杂，有些觉得比较罗索，例如通过root然后找到RenderTarget然后知道ViewPort，再找到Camear，最后才执行到SceneManager的渲染函数，为什么不把ViewPort做完SceneManaer::_renderScene的一个参数，交给上层来控制呢？毕竟多数程序要一个RenderWindow，一个ViewPort就够了。又比如RenderQueue（见下图），不知道是不是因为要处理Shadow等才搞得这么复杂。

  对于Objects按照Material分组，然后对于每个Group再先显然Solids再渲染transparents，这种透明处理方式明显是不安全的，如果两个组中都有透明物体，那画面肯定会出问题的。

参考：http://blog.csdn.net/yanonsoftware/archive/2006/08/09/1041396.aspx