Ogre1.7 更新

Ogre新的版本在年后首次发布了。1.7较之以往的版本有了长足的进步。
由于跟SOC的互动，Ogre 1.7开始慢慢渗透了更多只有商业引擎才有的功能。这得益于最初优良的框架。

下面一个一个道来。

1.改了个名字，似乎是另外一个怪兽。：） 协议改变，现在是MIT了，总之就是更自由了。
2.Sample Browser的引入，社区里有篇写的很详细的文章。很多商业引擎都有，个人觉得实行用其实一般，属于引擎的噱头。以后只需要进行一次资源重建就可以切换包括渲染系统等等东西，不用重新运行可执行文件。
3.使用CMake来构建，好处就不说了，社区里也有帖子很详细。
重点来了啊~~
一.地形系统重大改进。
1. 地形管理从场景管理中独立出来，成为一个可选组建
2. 内置了可编辑功能 (不过功能还不强大哈)
3. 使用了批量渲染。当顶点数量随着LOD递减时，渲染的批次也会递减。最低的Lod渲染批次的数量为1
4. Lod可以实时的与Camera设置进行适配。因此可以方便在不同的视角中使用同样的地形
5. Skirts技术替代了早期的缝合技术来出来地形的裂缝。

这里解释下。Skirts不知道国内通用的翻译是什么。直接翻译成“裙子”也行。大片地形渲染中，不同的Lod层次的地块由于有不共用的顶点所以一定会造成裂缝（Cracks）。老的解决办法就是缝合，通过削减高级别Lod地块的边缘顶点数或者增加低级别地块的边缘顶点数来做过渡。这样的缺点是，无论哪种方法都要重新遍历整块地形然后重新进行三角形剖分。对地形的分页和缓存带来很大的麻烦。
Skirts的做法，则是对每个分块的四条边，在现有的顶点的基础上再延伸出一圈，并且与单个分块的边界共享顶点，而高度值不同，这种延伸出来的一圈叫做“裙子”（Skirts）。蛮形象的把，呵呵。只要保证顶点的高度值足够大，两个分块的裙子可以把裂缝遮挡住。
这种消除裂缝的方式唯一缺点是会增加绘制的三角形数量，但是对于现在的图形处理器来讲，这种三角形数量的额外增加不会带来性能上的下降。

6. 内建了地形的保存和加载，并且是在后台线程里完成的
7. 支持多层材质融合，可配置的采样输入，以及可插件化的材质。
8. 支持生成全局Normal maps和light maps.同样也是在后台线程完成的。

二.Compositor的重大改进
这也是去年实际做项目中遇到的最麻烦的问题。由于不能共享，导致过渡的耗费，让我们不得不放弃了某些后期的效果。现在终于解决了。就是通过了一个叫‘pooled’的东西。

1. 当不同的合成器实例使用一个相同大小和格式的表面时可以被共享,这样可以节省内存。
就是说rendertarget如果设的一样的话，就可以被用来用去了。

2. 系统会帮你侦测这个合成器实例链以避免相互依赖。

3. "pooled"需要在定义纹理时显式被激活。注意下，这个激活不是默认的。因为一旦它被激活，你就没法完全看到那些作为中间过程的纹理了。（因为他们可以通过共享的方式互相传递（ping-ponging），或者叫反射吧）；但是如果用户又恰好需要，所以就设置了默认不激活。

其实很好理解，就是说如果"pooled"被激活，那么那些被用来ping-ponging的纹理就得不到了，因为不作为最终结果的图不会被保存，那个被共享的rendertarget会被反复擦写。所以说，你如果到最后又想用那些图，就不能激活"pooled"也就是说，使用默认了就可以了。

4. 另外一个就是可以在运行时，交换两个Compositor。Technique现在都有一个自己的名字"scheme"。交换的时候只要通过名字来所以就可以了。不用麻烦的再去用大量的宏定义去判断什么的，以前做法是判断硬件是否支持啊，或者自定义几种表现方式啊。现在都不用了。因为那样看起来会很乱。

5. 现在也可以保存和共享一个用过的纹理，保证向前向后交换都变得更快。
另外还有一些细节修改：
a.不想继承FSAA的，需要设置下'no_fsaa'。
b.支持逐纹理sRGB gamma校正。
c.跨Compositor的通信。
i.使用chain_scope 或 global_scope 直接可以定义纹理来自于其他的地方。
ii.使用texture_ref，可以直接从其他Compositor或公共部分引用一个纹理。
d.Compositor代码之间连接被改进了
i.可以自定义一个合成器pass。不仅仅是quad/scene/clear啦。要用render_custom来激活这个自定义的类型。
ii.可以自动使用CompositorLogics，来使compositor和相关的代码连接（例如使用一个compositor监听者）

PS:compositor这种东西在其他引擎中还很少见到，原因是涉及的东西太复杂，不好抽象，如果限制太多，后期做起来就很困难。Ogre算是一个尝试把，不是实际用起来还是有不少地方不太方便使用。等大牛们慢慢重构把，希望以后对后期制作方面的设计是个帮助。

 

三：增加了几个很牛X的组件
1.RTSS组件。

这个太强了，以前材质脚本都需要一个懂美术&懂技术的人员来搞定。现在不用了，在画面上点点UI，保存下，就完成了一个Shader文件。并且里面支持per-pixel lighting, normal mapping and shadows等更多内容。
已经有点gamebryo的意思了。GB里做的只是把这个生成Shader的方式跟Max结合到了一起。而作为Ogre我也觉得应该有自己的一套pipeline，并且集成好用的工具提供给游戏开发人员。现在看到个雏形，挺高兴。
实现过程其实还是蛮复杂的，特别是构建一个ShaderTree系统，具体的关于Gamebryo的实现，做个广告，http://www.guibian.com。可以去我Blog看罗。
另外，我觉得这还不够帅，按照这样发展下去，SOC2010应该能作出类似UE3的东西，就是拖拖拉拉出Shader。至少我觉得在Ogre现有框架下实现并不复杂。

2.分页组建。
新的分页组件从场景管理器中独立开，分拆成为几个不同的可选组件。
插件化的策略组件来控制场景中的分页。插件化的内容组件来控制分页的内容。
插件化的集合组件用来组合不同的分页(比如 在一个页中分出多个LOD级别)

四：支持Iphone
估计地球人都知道了，自己去看代码把。很多Objective C的东西，看起来很亲切把。：） 我的Ip已经能跑起来了。就是速度还有待提升。另外别忘了先预解析一下材质脚本，不然解析Shader很费电。 - -||

五：几个不加解释的翻译
1. 场景管理器的修改，可以中途暂停一帧的渲染（比如通过在一个过程中使用回调函数），暂停后可以触发另一个渲染，最后在恢复。这是之前在商业引擎中看到的。而且是个很有用的功能。
2.添加了一个选项可以手动触发阴影图的更新，比方在有特殊光照的时候。
两个方法结合起来很有用。当有多重shadowmap的时候，纹理就可以被重用了。
其实还是Compositor里的东西，另外跟DS有关。

抗锯齿的改变
1.支持CSAA，dx9和10中可以使用。
2.简化了并标准化了AA的设置。
在Root的config选项里。所有情况下都加FSAA，组合上一个采用方式和一个提示字符串。通过空格分隔。
在createRenderWindow的miscParams参数上你可以提供 "FSAA" 和 "FSAAHint"参数,前面是这个采样的倍数，后面是一些提示(例如质量)
PS：怎么跟gamebryo越来越像，怀疑google code这些家伙是GB的倒戈。

光照的改变
1.阴影摄像机的远近裁减面设置支持每盏灯光。
2.可以通过调用MovableObject::setLightMask来设置渲染物体mask光照,一个可渲染物体的掩码与灯光掩码按位求与，如果是0，灯光就被排除。

LOD的改变
LOD不再使用距离作为度量来区分了。
LOD策略现在在材质和网格上都能被设置，或者按照距离，或者按照像素数。当然也可以很方便的添加新的策略。
STL容器
所有的STL 容器现在使用自定义的内存分派。

优化
固定管线的光照状态更加智能化，为了处理物体数量巨大的时能发挥更好的性能。
着色器参数更新现在更加有选择性了，减少不必要的更新。

GpuProgramParameters改变
多个cg程序或者材质基本中需要共享的参数可以在一个地方定义和更新。代码看这里：GpuProgramManager::createSharedParamerers
当Gpu程序的基类被改变或者重加载以后，参数会自动被移植。改变后任然可以使用的参数将合并到新的参数中去。

文件系统的改变
支持创建和移除文件（仅在FileSystem中有效）

DataStream的改变
可写数据流也支持了（同样仅在FileSystem中有效）

加了一个新的类StreamSerialiser，是读写二进制数据格式的新方法。

PS：看到Ogre开始也要用流格式来管理数据了

RenderWindow的改变
可以自定义v-sync的刷新频率。并且硬件也要支持。

视口的改变
增加了一个clear方法来手动清除任何 颜色/深度/模板的组合，这个指定值不执行更新操作。

图片的改变
增加了 loadTwoImagesAsRGBA 和 combineTwoImagesAsRGBA 这两个方法，使用它可以更容易的构造 法线/高度图 和 漫反射/高光图等组合

线程也做了修改，大家自己去看把。

总结下，这次新版本作出的改变。感谢SOC的那帮牛人，Ogre越来越向着一个易用的引擎靠拢。开始借鉴很多商业引擎不错的地方。开始慢慢解决在实际项目中遇到的问题。而他优良的扩展性被体现的很明显。最初项目开发的时候，我们发现Ogre其实有很多"bug"，之所以有个引号，是因为那不叫真正的Bug，由于Ogre在游戏项目中不太经常的出场率，造成很多引擎设计上没有考虑到的问题，不过我发现这个版本很多的新功能都弥补了那些缺陷。这些可喜的结果我相信在SOC2010后还会有个飞跃~