在过去三个月中，OpenMW团队一直在努力将代码库从Ogre3D引擎移植到OpenSceneGraph渲染工具包。在以前的文章对我们的动机会谈。
我们很高兴地宣布移植工作终于取得成果 - 因为所有游戏玩法必不可少的功能已被移植，因此用户可以在OpenMW-osg开发分支中享受Morrowind的合法游戏。
一些高级功能 - 着色器，远距离地形，阴影和水反射 - 尚未移植。然而，即使是这么早，可以肯定地说，转型取得了巨大成功，其方式比我们最初设想的要多。玩家会发现新的OpenMW加载更快，帧率更高，看起来更像原始游戏，并修复了一系列长期存在的错误，这些错误在我们的旧框架中难以解决。
坚持...... 提高帧率？让我们来测试......
第一个基准
我们的测试环境应为：
GeForce GTX 560 Ti / PCIe / SSE2，AMD Phenom（tm）II X4 955处理器×4，Linux 3.13.0-24-通用x86_64
1680×1050，全屏，无AA，16x AF，无水反射，无阴影，无着色器
根据游戏内滑块的最大视距
测试场景：好老（滞后）Balmora
| OpenMW | OpenMW，OSG | |
| 帧率平均 | 49 | 75 |
| 加载时间平均值 | 7S | 3.4s |
| 系统内存平均 | 344.6mb | 277.1mb |
不出所料，OSG端口在所有三个方面都获胜。帧率提高是不错的，但仍然远远低于我们在单个模型的早期测试中看到的3-4倍的改进。然而，没有理由担心 - 你应该把这些数字当作一粒盐：
- 比较是不公平的。OSG分支中包含新的渲染功能，这使我们更接近vanilla Morrowind兼容性，但也会影响性能。例如，我们现在基于运行的动画动态扩展边界框，这修复了悬崖竞赛者在某些角度下消失的臭名昭着的bug（错误455），但也对帧速率产生了负担。同样地，我们抛弃了静态几何体批处理，这是一种性能优化，导致了许多问题，主要是不正确的光照和无法工作的对象的脚本移动。即使在所有这些新工作负载下，OSG端口仍然更快！
- 预计高级图形功能将获得更高的性能提升。使用最小图形设置进行比较，原因很简单，OSG分支中不存在高级设置（阴影，反射等）。我们预计，一旦移植了这些高级功能，它们对帧速率的影响将比以前低得多，这仅仅是因为新的渲染器在GPU工作负载方面的扩展性要好得多。Draw提交现在被卸载到工作线程，因此场景的图形复杂性不会阻止主线程在此期间执行工作，例如剔除，物理，脚本和动画。
- 在真正的优化阶段甚至还没开始。现在的主要焦点是让游戏恢复到可玩状态，而这只发生在几天前。现在，有很多优化机会即将到来。我们的新渲染框架使我们能够更好地控制场景图的结构，以及如何调度更新，这是我们刚刚开始利用的。不久的将来计划优化包括：
- 将皮肤更新移动到工作线程。
- 将粒子更新移动到工作线程。
- 跨不同的NIF文件共享状态。
- 启用粒子发射器/程序的剔除。
- 集成模型优化器。不幸的是，Morrowind的模型包含大量冗余节点，冗余变换和冗余状态，这会影响渲染性能。原始引擎在将模型加载到引擎中时会在模型上运行“优化器”。我们应该实现类似的优化器传递。OpenSceneGraph提供了osgUtil :: Optimizer，它可能对此非常有用。
- 创建更平衡的场景图，例如四叉树，以减少剔除和场景查询对性能的影响。
- 渲染不是唯一的瓶颈。假设渲染器速度提高N倍会导致OpenMW速度提高N倍。我们有其他系统争夺帧时间，现在我们的渲染器更快，这些其他瓶颈变得越来越明显。特别是，物理和动画系统目前是最糟糕的两个罪犯。对这些系统的一些初步优化使其成为OSG端口，但我们毫不怀疑还有更多的改进空间。
话虽如此，更好的性能肯定不是用户期待的唯一变化：
初步更改日志
渲染改进
- 非均匀NPC缩放（错误814）：
某些NPC现在沿着它们的X和Y轴缩放，使它们看起来更笨重，就像在香草Morrowind中一样。由于Ogre3D的限制，早期版本的OpenMW无法支持这种扩展。 - 提高渲染精度：解决了当玩家距离世界原点太远时闪烁/抖动所表现出的大坐标精度问题。视频比较
- 删除静态几何体批处理：修复不正确的光照（错误385），修复对象的脚本移动（错误602），并改善单元格加载时间。
- 香草精确的透明度设置：OpenMW的早期版本使用透明度设置对vanilla Morrowind不太准确，以促进静态几何体批处理。这已经修复 - 用户会注意到树叶和其他透明物体现在有更柔和的边缘。
- 添加了小特征剔除选项：除了剔除屏幕外对象之外，我们现在还可以剔除渲染时小于单个像素的对象。视觉上的变化几乎无法察觉，因此我们默认启用了该选项。
 |  |
| NPC缩放比较 | 透明度比较 |
重新设计的NIF装载机
- 支持NIF文件中的非均匀缩放（错误2052）
- 修复了NIF文件中节点数量的限制（错误2187）
- 修复了对象被剔除时动画“冻结”的问题（错误2151）
- 重新设计的蒙皮算法，以实现更高效的场景图
- 基于骨架动画动态扩展边界框; 修复某些生物在某些视角下消失的问题（错误455）
- NIF场景图现在是共享资源; 大大缩短了装载时间。
- 动画文本键现在是共享资源
物理重写
- 使用Bullet 2.83或更高版本编译时，利用btScaledBvhTriangleMeshShape进行有效的形状实例化
- 删除“详细”子弹光线投射形状，替换为场景图上的直接光线投射（请参阅“新光线投射”部分），大大减少了内存使用量
- 使用btCollisionWorld代替btDynamicsWorld，以避免对我们未使用的功能进行不必要的更新
- 通过指针而不是按名称映射碰撞对象
新的光线投射
- 使用osgUtil :: IntersectionVisitor在场景图上进行直接光线投射
- 支持对动画网格进行光线投射，修复演员不准确的光标选择（错误827）
- 重新编写库存预览玩偶的项目选择逻辑，以使用光线投射而不是选择缓冲区，从而缩短响应时间
改进了加载屏幕
- 加载屏幕现在在绘制线程中呈现，因此不再阻止加载过程
- 加载屏幕FPS增加，因此加载杆移动更平稳
- 使用osgUtil :: IncrementalCompileOperation在区域加载时在后台线程中上载OpenGL对象
改进了SDL2支持
SDL2是我们用于跨平台输入和窗口创建的库，它与渲染系统更紧密地集成在一起。为用户带来的实际好处包括：
- 抗锯齿选项最终适用于Linux系统（错误2014）
- SDL2现在负责创建图形上下文，这意味着自动支持新的显示API，例如Linux上的Wayland和Mir，而OpenMW团队无需额外的维护开销。
8倍抗锯齿作用
分析叠加
使用OpenSceneGraph的一个很好的副作用是访问他们的顶级分析工具。使用“F3”键，屏幕上会出现一个按键，每次按键都会显示更多信息。
剖析覆盖 - 彩色条表示OpenSceneGraph的内部线程，白色条表示OpenMW逻辑
被动修复
新的OpenMW在我们所有平台上运行统一的OpenGL渲染器。不再支持通过Direct3D进行渲染，从而简化了OpenMW团队的维护和支持开销。
实际上，我们已经“修复”了Bug 2186（Windows上的小地图上的垃圾像素）和Bug 1647（在Windows上切换到窗口模式时崩溃）。
其他变化
最后，我们确实有一些与OpenSceneGraph转换并不严格相关的奖励更改，但是为了减少合并冲突，我们还是致力于OSG分支：
- 调整灯的激活范围（错误1813）
- 固定NiGravity强度（错误2147）
- 实施控制器外推模式（错误1871）
- 实施了NiPlanarCollider粒子处理器（Bug 2149）
- 添加了UI缩放选项：
 |  |
| 普通的UI规模 | 2倍UI比例，相同分辨率 |
代码维护/重组/清理
代码库已经大大减轻了重量，这对开发人员来说可能很有意思，尽管对最终用户来说并不那么有趣。
- 物理代码转移到一个新的“mwphysics”子系统
- 删除了场景节点名称，即RefData :: getHandle标识符
- 删除了OpenEngine
- 删除了平台包装器
- 去掉了光泽
总共删除了〜23.000行代码：git diff upstream/master --shortstat
689 files changed, 24051 insertions(+), 47695 deletions(-)
下一步是什么？
Phew，这是很多东西 - 即使在这个阶段，改进列表也是巨大的，所以我们的首要任务应该是将端口合并到主分支，让我们的各种夜间构建再次运行，然后获得新发布。
从长远来看，我们甚至没有释放出我们新渲染引擎的全部潜力。接下来的步骤是进一步提高性能，然后恢复着色器，远距离地形，水反射和阴影。我们的新NIF加载器有助于实现后台单元加载，最初计划是1.0后改进 - 现在，这样做很简单，所以我们可能会看到1.0之前的这个功能。
与此同时，在图形方面，现在没有什么可以阻止我们发布期待已久的OpenMW 1.0，所以也许应该转移到首先修复剩余的OpenMW 1.0拦截器，将1.0版本推出门外，然后移植高级版本版本1.1的图形功能。我们可能会根据具体情况做出决定。特别是，水反射应该比阴影更容易移植，阴影无论如何在Ogre分支中都不是特别好。
如果您对此事有意见，请随时发表评论。虽然不管我们决定的优先事项如何，但这些肯定是激动人心的时刻！
437
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
