你所不知道得Ogre

免费打工仔

首先说明，这个标题只是炒作，可能下面所有的观点看官们早已了然于胸。

Ogre研究的人太多了，在中国更是这样，但很多人都仍然认为Ogre只不过是一个普通的图形引擎而已，并且主要研究的也是Ogre作为普通引擎的部分。

但Ogre有自己的特点，不知道大家都注意了没有，反正我是没有注意到，最近看到了一本国外的著作才侥幸的到这些知识。

Ogre老大是做软件工程出身，似乎他很讨厌这个工作，但是确实带来了Ogre设计上的特点。

首先是场景图的管理，一般而言，游戏都是固化一个场景图管理器到里面的，比如Q3的BSP或者其他什么图形引擎（至少再Ogre诞生的时候是这样的情况），这是Ogre老大最看不惯的地方，他说，我应该能选择我喜欢的场景图组织方法，而不是你们给我规定，所以他就把场景管理器抽象成插件，然后就可以动态的选择。

似乎并没有人注意到这样做带来的好处，但到了1.0版本之后，Ogre可以支持多个场景管理器，哦，明确以下，在同一个场景中使用多个场景管理器。不是很cool么。当一个室内室外交界的画面，你可以从室内场景管理其自然的过渡到室外中。在一个管卡里面，只要场景管理器的开发者做好出入口的处理就可以完美的实现上面所提到的功能，当然现在很多商业的非商业的半商业的Ogre图形管理器都势能完美处理这些问题的。

另外一个Ogre重要的特性并不那么容易被人发现，回想一下你所学过的面向对象教材（比如Thinking in Java或者 C++ Coding Standards），都提到过在可以用组合的时候尽量不要使用继承。但是似乎大部分图形引擎（或者游戏引擎）开发者都没有看到过这句话，他们的场景图和场景内容是继承关系的，这样做带来的“好处”是，在你企图要修改场景图的部分，所有场景内容都要跟着一起改变接口。或者当增加新的场景内容的时候，所有场景管理器都要增加适配代码。不要用继承，他是除了友元之外C++中最紧密的关系。Ogre听到了这句话，在这里采用了组合的方式，场景图和场景内容分离。这样做在图形届算是创举，所以当然Ogre在实现的过程中也遇到过多多少少的问题，不过还好，到了今天Ogre已经能胜任这种工作了。

这是Ogre引以为傲的特性，可能您现在还不以为然，但当您的项目中需要增加新的场景内容，比如音源的话，你可以不用考虑具体的场景图结构，而轻易的增加新的内容，你才能了解这样做的伟大。

回过头来说，Ogre的特点不是技术（当然技术也不弱），而是设计，这与Ogre老大的出身十分不开的。

还是那句话：好的设计可以带来更多的特性，但反过来则不可以。

FantasyDR

另外一个Ogre重要的特性并不那么容易被人发现，回想一下你所学过的面向对象教材（比如Thinking in Java或者 C++ Coding Standards），都提到过在可以用组合的时候尽量不要使用继承。但是似乎大部分图形引擎（或者游戏引擎）开发者都没有看到过这句话，他们的场景图和场景内容是继承关系的，这样做带来的“好处”是，在你企图要修改场景图的部分，所有场景内容都要跟着一起改变接口。或者当增加新的场景内容的时候，所有场景管理器都要增加适配代码。不要用继承，他是除了友元之外C++中最紧密的关系。Ogre听到了这句话，在这里采用了组合的方式，场景图和场景内容分离。这样做在图形届算是创举，所以当然Ogre在实现的过程中也遇到过多多少少的问题，不过还好，到了今天Ogre已经能胜任这种工作了。

说起来组合和继承的关系确实很搞……c++多继承带来的诱惑实在不小啊。

月下临风

夜深了,特地登陆,就是为了这贴--顶了,值!

whb9633

OGRE的场景管理方式应该不能叫场景图吧…
而且OGRE大部分都是实体类而非抽象类的层次结构，耦合性很高

免费打工仔

whb9633: Re: 你所不知道得Ogre

OGRE的场景管理方式应该不能叫场景图吧…
而且OGRE大部分都是实体类而非抽象类的层次结构，耦合性很高

应该明确，继承使C++中第二名耦合的功能，
实体采用的是组合，耦合性比较低（相对于抽象类的层次结构）。
你可以参看一下用户自定义（user-defined）节点的使用方法，可能就会理解我说的意思了，我还是不要辩解了，把译文直接贴出来好了：
以下文章节译自Gregory Junker所著作的《Pro OGRE 3D Programming》

首先，Ogre对场景图形的操作维持在接口级别；它并不关心去操作图形的具体算法实现。换言之，Ogre只是通过信号（它们的方法）来操作场景图形，进而忽略了具体的算法实现。其次，Ogre的场景图形接口支维护场景结构。节点中没有包含任何固有的内容和管理方法。具体的内容被放置到一种可渲染（Renderable）对象之中，它提供了场景中全部几何图形（包括活动的的或者其它所有的）。它们的渲染的属性（也可以说是材质）被包含在实体（Entity）对象中，在实体对象里面同样包含着一个或多个子实体（SubEntity）对象，这些子实体才是是真正可以被渲染对象。图3-1 展示了场景图形结构和场景内容之间的关系。注意：尽管场景节点挂接到场景图形上面；但场景图形仍然没有任何节点状态的直接操作。

其中活动对象MobeableObject可以直接操作所有几何体和渲染属性。它并不是场景节点的子类，而是挂接到场景节点中（可以理解为通过组合代替继承）。这意味着如果你需要，程序中的场景节点可以不用了解与之相关的可渲染对象的任何细节。也意味着你可以扩展，改变，重写，或者其他改变场景图形的实现，而不会影响场景内容接口的设计和实现；他们彻底独立于场景图。场景图甚至可以完全修改而不会影响任何内容类。

反过来说也同样适用：场景图同样不需要对所挂接的场景内容节点有任何了解，只要通过所用的接口来通知就可以完成所需要的功能。因为这些出色的设计，Ogre甚至可以完成对“用户自定义（user-defined）”内容节点的挂接。如果你决定构造一个拥有环绕立体声的场景，你可以把各种音效实现自定义节点，然后无缝的挂接到场景中。自定义的场景节点只需要实现一个简单的接口，就可以把定制数据挂接到场景中任意的节点上。

就像我在前面说的，这是一个漂亮的设计。虽然在Ogre的开发历史中也经历过一些问题，不过到了现在的版本，这种设计已经得到了绝对的完善，请放心的使用。

zotin

好的设计的确很重要，大家都知道。
但好像很多人对好的设计的理解的重要性就不知道了。

ricohcanon

顶啦

smile636

     继承也有继承的作用，赞成楼主所说的OGRE很多地方用继承是对的，但是大家不要就以为处处都用聚合替代继承。

ricohcanon

顶咯