Ogre的起源

免费打工仔

以下文章节译自Gregory Junker所著作的《Pro OGRE 3D Programming》
Ogre的起源

Ogre是一个开源软件项目。这意味着你“通常”可以免费的随意使用它。一些小小的限制来源于它所使用的LGPL协议；如果你有什么不明白的细节，理查德*斯托尔曼 和他创立的自由软件基金将会很高兴告诉你什么是LGPL所定义的规则。无论是哪种类型的软件产品，包括教学或者科研项目，个人学习或者开发游戏项目，全特性的社区游戏（Full-featured community），乃至具有赢利的商业游戏和其他3D应用程序，只要你遵循下面的一些限制和规则，你都可以免费的将Ogre应用到你的软件产品中。

这本书里所含所有版本的Ogre，并不象MySQL等开源软件那样具有双重开发许可，相对而言它是更严格的遵守LGPL，以下是LGPL许可的主要内容：

*你必须区分你所得到的二进制文件是否是从最初遵守LGPL的源代码版本编译而来，因为任何对源代码的改动都可能让这个项目变成“闭源”，并且确认从这个源代码所编译生成的库是可用的（对于这点你完全不用担心，这应该是Ogre开发工程所保证的）。

*当你使用这个库作为动态库被链接到你的应用程序之中的时候，并没有必要如同GPL协议一样开源你的应用程序，在LGPL协议下这种情况你的软件没有被强制要求遵守LGPL。（这就是协议中“Lesser”这个词所带来的含义。）

*但当你把遵守LGPL的项目作为一个静态库链接到你的应用程序的时候，你必须保证你所开发的程序也要遵守LGPL协议开源（换句话说，静态链接——让你把协议链接到了程序里）。

Ogre项目在2001年被建立，它的作者，Steve“Sinbad”Streeting，曾经是一个每天循规蹈矩的商业软件开发者。某天，突然冒出了一个想法：世界需要有一个不一样的3D 渲染引擎（约翰*卡马克 在多年前已经开发了一个），它的场景结构应该独立出来。随后，他利用10多年在图形领域的软件工程开发经验（也可以称为“折磨”），以及在更多“折磨”中诞生出来的软件工程（他正式的工作）经验，设计了一个体系结构——今天被我们亲切地称为Ogre。当我们问他为什么愿意去设计另外一个3D渲染引擎的时候，Steve回答说：

[B]很多的引擎，在技术上吸引人的同时，却缺乏紧凑的设计和完善的开发文档。它们虽然拥有众多的特性，但是缺乏一致和直观的技术演示。正如同其它很多软件系统一样，随着时间而逐渐变的庞大和衰落。另外还有很多引擎只是针对某一特定类型的游戏或者演示而开发（如，第一人称射击游戏，地理场景漫游）。
而OGRE是如此与众不同，在它的理念中设计总是先于功能的实现。每一个加入OGRE的特性，都经过了慎重的考虑，尽可能的完善设计并伴随完整的文档，这意味着新功能会完美的融入整个体系之中。它严格遵循着质量重于数量的原则，因为拥有良好的质量就具备了持续发展的可能，简单数量累积并不能解决这个问题。OGRE遵循面向对象的设计理念，并借鉴在商业领域广泛使用的设计模式等技术。我们的核心团队刻意的保持精简，他们所有人都是在真实世界中拥有多年软件工程经验的的工程师。同时也欢迎从社区中脱颖而出的人才加入到核心团队中来，但一定要经过严格的考核，确认他既符合“食人魔（Ogre）”的精神——强壮且团结，这样才可以被接纳。
[/B]

在Ogre核心团队中这些专业且富有激情的工程师们来至众多领域，其中有商业软件工程师，游戏开发者，学术研究人员，甚至包括大型机器模拟仿真系统的开发人员。在他们没有做本职工作的时候，就会腾出时间来完善Ogre引擎。当他们没有完善Ogre引擎的时候，就会在Ogre的社区论坛或者官方聊天室中解答大家的问题。当这些核心开发人员没有在这里回答大家的问题的时候，同样有一群热心而活跃的社区用户来代替他们给新的Ogre使用者解答问题，也或者老的使用者们会相互交流。其中那些活跃的，经常为人们及时提供正确答案和建议的人将被选为Ogre MVP

congy

成也萧何败也萧何，高内聚低耦合的 OO 设计思路决定了 OGRE 拥有了良好的内部结构却丧失了高效的渲染性能，对于游戏来讲，最终用户的体验的重要性远远大于优秀的内部结构，更何况这种设计结构的本身也值得考虑。

免费打工仔

congy: Re:Ogre的起源

成也萧何败也萧何，高内聚低耦合的 OO 设计思路决定了 OGRE 拥有了良好的内部结构却丧失了高效的渲染性能，...

Ogre老大看得稍微远一点，不过不代表卡马克就看不到。
最近一次卡马克在Id的会议上讲，就目前而言每秒120frame和每秒60frame已经没有什么太大的差别，性能对于游戏引擎来讲已经不如内容重要。（OK,这个是世界上游戏引擎性能最牛X的人，应该没人反对吧）。

另外一点很重要的是，显示特效已经从图形引擎慢慢朝向图形硬件编程过渡，比如GC或者其他什么顶点着色语言。逐渐的，任何引擎的渲染效果也趋于相同。（不知道以后会不会有着色引擎出现）

第三一点是，计算机硬件业朝向一个奇怪的方向发展，结构越来越复杂，比如双核或者四核，乃至XBox360上面的6核，Ps3上面cell都不知道几核。离散化的硬件更适合离散化的程序，如果一个程序结构好应该很容易步入多核的时代（虽然Ogre本身并不是线程安全，但在这个论坛中你就能看到一篇对Ogre多线程的处理），另外Ogre本身的漂亮结构会如病毒感染到使用Ogre的应用程序上，这样对于那些结构不好的快速的引擎来说，搞不好Ogre能更快速。

所以，Ogre是面向未来的图形引擎，至少在开发的时候是这个样子，现在已经是那个时候的“未来”了，Ogre的强大正慢慢显露出来！

congy

在我看来，OGRE 是个学习引擎开发的优良范例，至少我自己对 3D 引擎的理解和深入是通过研究 OGRE 近两年、看了 OGRE 80% 的引擎源代码开始的。不过理论上和实际还是有很大差别，你所引述 carmack 的话我想他是有一定前提的，我不相信在一个万人级以及复杂全局光照特效计算的场景中祯数是不重要的。从人眼的生理反应速度来讲 60 祯足以，不过请别忘记游戏中不仅包含 3D 的渲染，当引擎本身绘制一祯图像占去了大部分系统资源的时候，我相信你会对你的游戏中的逻辑、物理、AI、网络、IO 这些争抢着要资源的系统而头痛的。

免费打工仔

congy: Re:Ogre的起源

在我看来，OGRE 是个学习引擎开发的优良范例，至少我自己对 3D 引擎的理解和深入是通过研究 OGRE 近两年、看...

不是说效率不重要，只是说不如当年那么重要。当然现在应该没有能采用实时全局光照算法的例子吧，而且，真正的瓶颈在于显示硬件而不是图形引擎，图形渲染是管线的，引擎再节约效率，阴影阿，着色阿又都是硬件的工作。

我不是说效率不重要，但要看看效率丧失在什么地方，C++有一句名言，不要为没有做的事情浪费效率（类似的话）。Ogre用效率是有尝的换取了一些东西，比如灵活性和可扩展性。回想一下当年Q3引擎和虚幻2引擎的事情，如果说效率技巧来讲Q3一定大胜，但在商业来讲虚幻才是赢家，只是因为了那个开发工具而已，虚幻更容易开发。

当然效率很重要，但随着计算机硬件技术的发展，另外比如说软件工程，设计模式，扩展性等等也并不是不重要了，Ogre只不过是做了一个买卖，可能一些时候看起来不赚钱，但是谁也不能保证这些以后会不会升值（至少现在看起来应该能升值）。如果一个人写游戏，那么胜的一定是卡马克，如果一个公司写游戏，那么虚幻不一定输，如果整个开源届写游戏（或者其他什么3D的东西），至少不会完全忘掉Ogre这个兽。

回头看看最近的3款游戏机 按照性能和图像显示来说
PS3>XBox360>WII
按照销量来说
WII>XBox360&gtS3
（XBox360早卖了一年，我们就算首发销量把。）

当年是MD发色数胜了FC
SFC旋转所放胜了MD
PS的3D性能胜了SS

但到了PS后期则不是单纯拼图形了
PS光盘>N64卡带
PS2游戏数量>NGC第三方
NDS触摸屏>PSP的UMD
这里为了客观我们只考虑销量，而论图形性能来说，都是后面的优胜。
但是 现在早已不是图形的时代了，
好的，跑题严重了。

Ogre付出了效率的代价，但绝不是无偿的。

seer

免费打工仔: Re: Re:Ogre的起源
Ogre用效率是有尝的换取了一些东西，比如灵活性和可扩展性。

这个和iostream与stdio很相似，
ios比stdio慢很多，但是它有stdio没有的类型安全和可扩展性

seer

免费打工仔: Re: Re:Ogre的起源
PS3>XBox360>WII

事实上个人认为PS3≈XB360，因为本来应该和XB360同时发售的PS3因为蓝光的问题拖了一年~~~

PS：发现最阴险的还是IBM：你们三个慢慢打，反正最后赢的肯定是我

congy

免费打工仔: Re: Re:Ogre的起源


不是说效率不重要，只是说不如当年那么重要。当然现在应该没有能采用实时全局光照算法的例子吧，而且，真...

没人说 OGRE 的付出是毫无回报的，只是这种回报不重要，或者不值得，说得更明白点就是付出的大于回报的。
说到灵活性和扩展性，我决不认同，OGRE 1.2 为了加入 Post Process 组合，重写了渲染的大部分流程，你能说这是有灵活性和扩展性？我更不相信世界上会出现一种设计方法能把 3D 引擎的所有可扩展的功能都能预测到，并能保证将来还能做到无缝的、高效的扩展，这是因为 3D 技术本身就属于前沿科学，并不像 ERP\MIS 财务软件系统那样，规则早已定好，事实证明，5年前的 3D 引擎的实现方式拿到现在已经不适合，5 年后会又怎能担保现在的框架代码在面对新技术时还能够具有 “灵活的、可扩展的” 特性？对于一门处于不断发展和还不完善的系统而言，最好的实践方式就是按需变化，而不是为了那些毫无把握的未来而去做无谓的工作。 OGRE 在过去 4 年的发展过程中一直没有成功的商业游戏应用经验足以证明了这一点，开源 3D 引擎还有很多，OGRE 在这里面的表现不算出色。

congy

关于效率，请记住：技术永远跟不上需求增长，需求驱动着技术的发展。

免费打工仔

congy: Re: Re: Re:Ogre的起源


没人说 OGRE 的付出是毫无回报的，只是这种回报不重要，或者不值得，说得更明白点就是付出的大于回报的。...

后处理是现在比较流行的功能，Ogre加入无可厚非。但"辛巴德“老大承诺，所有加入的功能都是经历过认真的设计，遵守质量大于数量的原则，姑且就相信他。在完美的软件也会有漏洞，但能在1.2版本完全改变整个渲染流程，至少说明Ogre核心是比较活跃和负责的。

我想说的是软件工程不是预测未来，而是坚固现在。那么多专家那么多天才研究的领域总会有些许价值，对于3D引擎开发也不会完全无用。

关于性能，和稳定，让我忽然想起来这样一个话题：
对于汽车来说，稳定莫过于劳斯莱斯，而性能莫过于法拉利或者宝时捷，如果两种车的车迷到一起一定都各持一词，但并不代表哪种车不好，只是对于不同需求的人提供了不同的选择，另外还有中庸的奥迪或者奔驰，便宜的日产车型。有钱你全都买了也可以，没钱骑自行车也没错。

性能在左结构在右，Doom3左倾，Ogre右倾，虚幻3中庸。但这不是政治，对于不同的需求有不同的选择难道不好么？

项目应该选择最适合的，而不是所谓“最好的”。Ogre没必要一定用，也没必要一定不用。

PS.

1. 说到灵活性和扩展性，我决不认同，
   
2. OGRE 1.2 为了加入 Post Process 组合，重写了渲染的大部分流程

复制代码

所谓灵活性和扩展性，是提供给用户的方便，改了里面的渲染流程而不影响用户接口，这正是软件工程所带来的好处。插件体系也趋于完善，对于脚本配置，别忘了后处理加入框架之后，和材质脚本基本采用相同的格式，这正是标准化带来的好处。
灵活和扩展，对我来说，不意味着里面的渲染流程永远不变，而是变化之后对外界影响尽量小，我觉得Post Process 做到了。