Ogre 1.7版本重大改进（转）

CrazyDev — Tue, 18 May 2010 09:43:00 GMT

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后还会有个飞跃~

CrazyDev 2010-05-18 17:43 发表评论

关于CEGUI的String的调试问题

CrazyDev — Tue, 18 May 2010 08:36:00 GMT

方法一：
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 = length =

即可在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

CrazyDev 2010-05-18 16:36 发表评论

static使用时应注意的问题

CrazyDev — Mon, 19 Apr 2010 14:15:00 GMT

今天在公司修改项目BUG，有个同事在一个函数里使用static来声明了一个静态指针数组，来保存一个结构体里的一些成员数据。因为函数里的static只会初始化一次，同事以为保存对象成员地址，当对象内容在其他地方更新时这个静态指针数组指向对象内容也得到更新，其实不然。这是我头次遇到的这样的问题，记在这里时刻提醒自己。

1void Function()
2{
3static int* pPlayerInfo[] =
4{
5 &m_struPlayer.nHatID,
6 &m_struPlayer.nClothID,
7 ……
8};
9}

CrazyDev 2010-04-19 22:15 发表评论

开博了！！！

CrazyDev — Sun, 18 Apr 2010 14:27:00 GMT

摘要: 俺的博客开张喽!希望以后像大家多多指教。阅读全文

CrazyDev 2010-04-18 22:27 发表评论

C++博客-芳草春晖

Ogre 1.7版本重大改进 （转）

关于CEGUI的String的调试问题

static使用时应注意的问题

开博了！！！

Ogre 1.7版本重大改进（转）