芳草春晖

偶尔记录自己思绪的地方...

 

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

posted on 2010-05-18 17:43 CrazyDev 阅读(967) 评论(0)  编辑 收藏 引用


只有注册用户登录后才能发表评论。
网站导航: 博客园   IT新闻   BlogJava   知识库   博问   管理


导航

统计

常用链接

留言簿(1)

随笔档案

文章分类

文章档案

C/C++

CEGUI

Friend Bog

Game Industry

Lua

OGRE

Other

搜索

最新评论

阅读排行榜

评论排行榜