我的结论是远处，以及草叶表现较好，不过如果有Normal的话，还是非常大的改进余地。
KlayGE中的AO是不是和DX中的HDAO差不多啊？感觉那个AO可以钩出非常细节的AO线，但是全局表现不如这个，怪不得叫HDAO，如果能配上一些低频的AO的话，应该会更好看一些。Nvidia的HBAO效果也挺好的，就是Blur老是出现点，但是可以比较好的解决低多边形镶嵌的痕迹，所以还是不错的解决方案。将来我会再尝试做个更好一些的AO，目前这个仍然没有十分让人满意的方案。
最近我分别使用了下Cryengine和Unreal的编辑器，相比之下，Unreal的编辑器要更专业一些，虽然Cryengine很强大，但是并不一定就是最为成功的商业引擎。Unreal的材质连接器使得Unreal效果的扩展性要好很多，Cryengine相比之下也只是拥有更强大的内建渲染功能，作为一款引擎，与Unreal的积累上仍然存在一些差距。当然说到效果，比起Lightmass所展现出的静态GI，Cryengine也没有办法弄出相应的动态解决方案。目前还是会有很多人觉得虚幻的室内效果更为完美，即使那要以牺牲动态光影为代价。
我继续更新，为回应[url=space.php?uid=4025]kuguoxin198[/url] 之前问的OC，我先在这里面简单说一下Cryengine中OC的理念，其实我也是这么想的，只不过GPU精粹上的说法和这个大相径庭，不过看到Cryengine的做法后，我像是有了靠山一般，很心安理得地也这么做了。当然，我说的OC是指Query的OC，其它使用CPU的OC方法不在这里面讨论。Query和回读差不多，都需要等待显卡指令执行完成，才能得到结果，如果在当帧疯狂查询，那OC会直接给予帧率毁灭性打击。GPU精粹上有一种优化OC的方案，但是这个方案只是减少了帧中查询的数目，并没有解决查询直接导致处理器空闲的问题，所以得到的性能增益非常有限，如果用这种方案来做一个游戏的话，场景规模会有相当大的限制。Cryengine的OC还是在我的意料之中，它在帧头，也就是Begin之后进行查询，这样的好处是，因为Begin已经等待显卡完成所有操作了，所以在Begin之后的查询就会相当迅速，不会因为同步白白浪费宝贵的CPU周期。得到结果后已经晚了一帧了，可以在渲染的时候直接应用，当然也可以等到下一帧场景管理器Cull的时候大幅度减轻CPU负载，不过那样的话，OC结果就需要延迟应用两帧，Cryengine可能是两种中的一种，我个人猜测应该是延两帧的，毕竟宝贵的CPU对Cryengine来说可是要计算几乎全部次世代物理的，在场景规模和视距都如此巨大的情况下，节省下这些资源是很有必要的。这时有人就会发现了，那不是会出现结果错误的情况，两帧的会比一帧的更严重。事实也确实如此，但这就是我之前提到过的瑕疵优化，有如此可观的性能提升，即使有瑕疵，仍然是合算的，因为毕竟OC的错误并不是无法接受的。原因有以下几点：
1.想要在同代硬件上加大场景规模，很多LOD的技术都会引起跳动和突变，有些远处的东西本来就会突然消失，OC导致的消失只不过是增多了会消失的机会罢了。
2.本来就要使用非常粗糙甚至刻意加大的模型代理来OC，这种粗糙会反过来减少OC错误的机会，所以OC错误可以很大程度地被减小，有特别刺眼的消失只要加大代理就行了。
3.相机的高速移动机会并不是很多。
4.事实证明了Crysis疯狂的跳动突变完全被场大规模的场景以及超高规格的细节所掩盖了。
我们对OC的需求是在最低帧率至少不降的前提下，可以较为可观地提高平均帧率，最完美是能同时解放GPU和CPU，而不是完美的无缝。下面发图来大致看下Cryengine的OC结果。
从图中可见，其实OC并不是那么精确的，太精确的OC反而对性能无益。目前好像有个OC引擎叫Umbra，可能这方面会比Crytek做得更精一些。