转:Ogre源码剖析 - 场景管理之Octree

由于本人的引擎ProjectGaia服务于08年创新杯的游戏项目 – 3D太空游戏,所以理所应当加入Octree(八叉树 – 已经周宁学长发帖介绍过)场景管理器.参考了无数Octree的代码,发现还是我们可爱的Ogre写的最好,于是狂看n千行代码,把精髓提取出来给大家共享.

鉴于我们游戏版教程又n久没有更新了,今天发一篇我对Ogre场景管理器之Octree源代码分析的笔记.

所有代码采用伪代码.

首先回顾一下Ogre场景管理的架构

Ogre以插件形式提供了多种场景管理器

1. BSP管理用于支持Quake系列

2. Terrain管理,优化大型的地形场景

3. Octree管理,用处多多,很适合太空游戏

4. 等等… (我只了解这几个:P)

以上所有的管理器都继承与SceneManager类,实现其提供的接口

并把与SceneManager挂接的SceneNode根据自身的特性进行管理.

进入正题: OctreeSceneManager – 名字好长啊,打字都麻烦

对八叉树的简介在附件中,如果不了解的请先看完附件,我就不废话了.

注意: 实际代码中的成员,方法数量是我下面提供的10倍以上..我只讲关键过程用到的成员和方法.

OctreeSceneManager : SceneManager

主要的方法:

FindVisiableObjs

WalkTree

UpdateOctreeNode

FindNodeIn(BoundingXXX)

主要的成员:

Root : Octree

WorldBox : BoundingBox

Octree

主要的方法:

GetChildIndex(BoundingBox)

GetCullBox()

主要的成员:

nodeList : List<OctreeNode>

box : BoundingBox

child : Octree[2][2][2]

parent : Octree

OctreeNode : SceneNode

主要的方法:

GetOctree

AddToRenderQueue

UpdateBound

主要的成员

LocalBoundingBox

这三者之间的关系如下:

OctreeSceneMgr包含一棵Octree的root, 一个Octree对象则包含了八个方向的子树(见上面的成员介绍), 一个Octree用链表管理了n多个OctreeNode. (补充: 由于OctreeNode继承与SceneNode, 看过我前面介绍的兄弟们都知道,SceneNode也是以树状结构组成的.但是此树非我们Octree中的树,因此在接下来的讲解中无视, 但要注意一点:OctreeNode的LocalBoundingBox则是由该SceneNode下面挂接的所有SceneNode的AttachedEntity (想像为一个或者多个3D模型)的boundingBox合并而成的…有点复杂了,多看几遍)

从程序执行的步奏来讲解:

首先,场景管理器为何物?答曰:cull,即剔除不可见的东东.

场景管理器的调用步奏基本如下: --- 参考燕良大牛blog…

1. SceneManager::_renderScene()

2. SceneManager:: _updateSceneGraph从root node开始递归的调用了所有scene node的update，主要是计算了transform；

3．SceneManager::prepareRenderQueue 这里有一个Ogre场景管理的概念RenderQueue。粗略的看，这个类主要是为了把Objects按照材质分组，它还将管理对象的渲染优先权；

4．OctreeSceneManager::_findVisibleObjects
4.1 OctreeSceneManager::walkOctree
4.2 OctreeNode::_addToRenderQueue
可见这个操作利用SceneManager的空间管理算法来对所有的SceneNode进行了可见性判断，如果可能可见，则加入到RenderQueue中；

步奏也看了,那么开始分析具体的函数吧.从调用的顺序开始…

前三步是用于状态的update,和cull无关,从第4部开始才是关键…

_findVisibleObjects{

//没什么内容,初始化

//调用walkOctree

walkOctree(camera,renderQueue,root,visibilityInfo,false )

//搞定

}

walkOctree(camera,renderQueue,octree,visibilityInfo,foundVisible )

{

//顾名思义,遍历树

If(octree->NumOFNodes == 0)

Return //没有OtreeNode,也就是没有模型关节,根本谈不上可见判断

OctreeCamera::Visibility v = OctreeCamera::NONE; //不是伪代码

If(foundVisible){

//当为true的时候,说明这个节点的父节点已经判断为完全可见,所以不用费神了

v = OctreeCamera::FULL;

}

Else if(octree == root){

//根结点暴大,不可能全部visible

v = OctreeCamera::PARTIAL;

}

Else{

Box = octree->getCullBox() //Cull,剔除盒,大小比octree的boundingbox大125%

v = camera->getVisibilty() //通过摄像机的Frustum平截头体(形状和透视体一样,

//定义一个farClip面,一个nearClip,然后四点分别相连)大小判定

}

if ( v != OctreeCamera::NONE ) //如果不是完全不可见{

//处理当前Octree节点下面挂接的OctreeNodeList的可见性

//此处我会砍掉一些用于显示八叉树盒子线条的代码 – 无用

Foreach(OctreeNode n in octree){

//原文代码用的是迭代器

//对于每一个OctreeNode n,判断是否可见,AABB是轴对称包围盒的意思

Bool vis = camera -> isVisible( n -> _getWorldAABB() );

if(vis){

//Ogre很大很复杂,一下所有代码表示把该节点放到渲染队列

sn->_addToRenderQueue(camera,queue ,visibleBounds );

mVisible.push_back( sn );

if ( mDisplayNodes )

queue -> addRenderable( sn );

}

}

}

Foreach(Octree child in octree){

//对于当前octree的八个子结点

bool childfoundvisible = (v == OctreeCamera::FULL);

if(child!=null)

walkOctree … 递归调用

}

}

OctreeSceneMgr:UpdateOctreeNode ( OctreeNode * onode ) {

//由于挂接在八叉树上的OctreeNode:SceneNode的模型随时可能会移动,跑出当前的包

//围盒,所以我们需要重新计算传入的节点所在的Octree位置

If(该场景节点所挂接的Octree == null){

//没有被挂接在任何Octree上

//如果已经在root的范围以外,强行挂接的root上

if ( ! onode -> _isIn( mOctree -> mBox ) )

mOctree->_addNode( onode );

else

调用_addOctreeNode

}

If(该场景节点已经跑出所挂接的Octree){

从原来的Octree上remove掉

//没有被挂接在任何Octree上

//如果已经在root的范围以外,强行挂接的root上

if ( ! onode -> _isIn( mOctree -> mBox ) )

mOctree->_addNode( onode );

else

调用_addOctreeNode

}

}

//怎么添加一个新的场景节点 – 即挂接一个OctreeNode用于挂接模型

OctreeSceneManager::_addOctreeNode( OctreeNode * n, Octree *octant, int depth ){

首先获得要被挂接的节点n的包围盒

if ( ( 没有超过八叉树的最大深度) &&

被挂接的octree的包围盒大小是被挂接的节点包围盒的两倍 ){

Child = 根据节点n的包围盒大小计算其属于octree的哪个子结点

If(child == 0){

建立该节点

}

Else{

递归调用_addOctreeNode(n,child,++depth)

//作用在于找到改好能包围该场景节点的子树

}

}

}

好了,基本的流程就是这样,那么我要动工开始移植代码了.把Ogre的C++移植到基于XNA的C#中去…ZZZ…