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后还会有个飞跃~
方法一：
CEGUI的字符串类设计的初衷是以32个字符为分界点, 低于32个字符使用固定buffer, 高于才使用栈分配内存存储字符串. 不过因为CEGUI使用utf32,兼容性虽然很好,但是在VC调试器里无法显示是个很大的问题.
这里参考了mybios博客中的文章,给CEGUI字符串做一个patch
然后需要找到vs2008的autoexp.dat文件
XP下位于:C:\Program Files\Microsoft Visual Studio 9.0\Common7\Packages\Debugger\autoexp.dat
用记事本等工具打开, 在AutoExpand段中像这样添加:
[AutoExpand]
; CEGUI String
CEGUI::String = str =<d_quickbuff,su> length =<d_cplength>
即可在VC调试器中看到CEGUI字符串内容, 不过中文还是暂时无法支持
方法二：
CEGUI的String不是std::string或std::wstring，而是自己实现的一个字符串类，他的功能跟std的string很接近。
但是，他支持unicode，内部存储是使用utf32编码规范来存储unicode字符，也就是说 typedef uint32 utf32; utf32* d_buffer;用这个32位无符号整型的数组来保存unicode字符串。优点是显而易见的，就是世界上所有字符都可以包囊进去，毕竟是32位啊！但是，缺点也出来了，有两点：
第一、内存占用过多，一个字符就要占4个字节，也太浪费了点；
第二、调试不方便，由于VS2005的调试窗口只支持ansi和utf16的格式，所以，CEGUI的String在调试器中只能看到一堆数字数组，而看不到字符，这是很郁闷的，每次要查看都要翻到内存那里看，而且还一堆乱码，超级麻烦。
解决办法：修改String类，使用utf16来代替CEGUI的utf32。
优点：
解决了内存占用过多的问题，一个字符只要2个字节就可以了；
解决了调试问题，VS2005直接支持utf16的显示。
缺点：
可能不支持全世界的字符，因为utf16不能表示超过16位的字符，但是，对于大多数国家的字符来说，已经足够了，毕竟windows2000/xp也是基于utf16编码的。
然后，下面是修改后的字符串类：
CEGUIString