Urho3D简介

 

简介

 

Urho3D是一个轻量级、跨平台的C++免费开源游戏引擎，在MIT许可协议下发布。极大地吸收了Ogre(http://www.ogre3d.org)和Horde3D(http://www.horde3d.org)的特点。虽然借鉴了Ogre，但代码远比OGRE 1.x的清新和简洁，效率也远比Ogre 1.x好。据说Ogre 2.x代码非常简洁和高效，但是正在开发中，先不做评价。先上图，有个直观的感受。

 

 

基于物理的材质

 

 

场景编辑器

 

特性

 

通用

 

• 运行时使用c++语言和面向对象编程。

• 基于任务的多线程。

• 层式性能分析工具。

• 场景和对象支持保存和读取多种格式：二进制、XML和JSON。

• 多线程工作队列等任务的剔除和动画更新。

• 支持Unicode字符串。

• 可以从Open Asset Import Library支持的格式中读取模型、场景、动画和材质；也可以从OGRE支持的mesh.xml和skeleton.xml文件里读取模型和动画数据。

• 资源后台加载。

• 支持多种IDE：Visual Studio、Xcode、Eclipse、CodeBlocks、CodeLite、QtCreator、CLion。

• 支持的编译器工具链包括：MSVC、GCC、Clang、MinGW以及它们的交叉编译派生工具。

• 支持32和64位编译。

• 可以编译成单个外部库文件（以静态或者动态的方式链接）。

• 使用SDL 2.0支持跨平台（目前可以运行在Windows、Linux、macOS、iOS、tvOSnew、Android、Raspberry Pi，还包括其他的通用ARM主板，以及使用Emscripten工具链支持Web）。

  图形和图像

• 支持所有通用的图形API：Direct3D 9、Direct3D 11、OpenGL 2.0 or 3.2、OpenGL ES 2.0和WebGL。

• 着色语言使用HLSL或者GLSL，支持HLSL字节码缓存（只在第一次用到时编译一次，将编译结果存到本地硬盘上，之后使用直接读取，从而节省加载时间）。

• 使用xml灵活定制渲染流程：向前渲染或者延迟渲染，启用哪些后期处理。默认实现了前向着色、light pre-pass（也就是延迟光照）和延迟着色。

• 支持点光源、聚光灯和方向光。

• 所有光源种类都支持阴影；方向光使用级联阴影（cascaded shadow maps）；除了深度偏移还支持法线偏移（normal offsetadjustment）。

• 在支持SM3的硬件上自动合批。

• 粒子渲染。

• 投影纹理。

• 环境&雾区。

• 高度雾。

• 地形系统支持层级细化。

• 静态和蒙皮贴花。

• 附加的视口渲染（实现反射等）。

• 几何形状、材质和动画都支持LOD。

• 后期处理。

• HDR和PBR。

• 能融合进3D场景的2D精灵和粒子。

• 使用stb_image加载图片文件；支持DDS、KTX、PVR压缩纹理。

  场景管理

• 基于组件的场景模型。

• 场景加载/保存在XML和二进制格式。

• 基于八叉树的场景管理和剔除。

• 使用软件光栅化实现了遮挡剔除。

  动画

• 硬件蒙皮的骨骼动画。

• 场景节点动画。

• 顶点变形动画。

• 对象属性的关键帧动画。

• 动画混合。

  物理

• 使用Bullet作为物理引擎。

• 2D物理使用Box2D。

  网络

• UDP客户端-服务器网络使用kNet库。

• 使用kNet支持HTTP请求。

• 场景属性支持网络复制。

  人工智能

• 使用Recast/Detour库，支持寻路和人群模拟。

  声音

• 2 D和3 D的音频回放。

• 使用stb_vorbis支持Ogg Vorbis；支持WAV。

  用户界面

• 内置的UI系统。

• 使用XML描述UI布局。

• 使用FreeType渲染TrueType字体；支持AngelCode位图字体。

• 本地化和数据子系统。

  脚本

• 支持AngelScript，这是官方推荐的。

• 除了Web平台，在所有平台上可选用使用Lua或者LuaJIT实现的脚本接口。

• 场景组件可以在脚本中定义。

  输入

• 支持键盘、鼠标、操纵杆和触摸输入。

  工具和编辑器

• 使用脚本实现的场景编辑器和UI布局编辑器，具有撤销和重做功能。

• 内容导入使用开放资产导入库。

   

 

效果

 

 

图1动画模型

 

 

图2多个点光源

 

 

图3静态场景

 

 

图4小地图（多台摄像机，还有Bloom效果）

 

 

图5物理碰撞压力测试，这么多立方体刚体，帧率没有明显下降

 

 

图6触发和布娃娃系统

 

 

图7汽车物理

 

 

图8水面渲染

 

 

图10一个忍者打雪仗游戏，这个引擎的人工智能做的不错

 

 

图11粒子系统

 

 

图12各种2D物理

 

 

图13 2D动画

 

 

图14 2D物理

 

 

图15更炫的粒子特效

 

 

图16 2D物理

 

个人评价

 

优点：

 

1、基于MIT协议的开源引擎，限制非常小。

 

2、所包含的特性非常全面。Ogre只是个渲染引擎，虽然有众多的插件，但是插件本身大都质量很低，另外要想做游戏，整合是个很大的工作量。

 

3、代码质量非常高。架构清晰容易拓展，代码简洁高效，包含PBR等诸多商业引擎最新特性。

 

4、有一个简单的场景编辑器，比起Godot的编辑器差了不少。编辑器是用Angel script写的，跟个普通游戏一样，在移动端也能运行，曾想着修改下是否以后也能在移动端上直接编辑游戏内容了，兴奋。

 

缺点：

 

1、像所有的免费开源引擎一样，大部分算法都达不到商用级别，需要魔改。

 

2、只有一个简单的编辑器，跟Unity这样工具链全面和易用性极高的商业引擎比起来差太远。

 

3、官方文档太少，社区还比较单薄，有问题可探讨的人不太多。

 

总结：

 

总的来说，在免费开源引擎里面，除了Godot，这是我目前见到的最好的引擎，各方面跟Unity的设计比较像。如果加大投入，开发出一个“开源的Unity”也不是什么问题。

 

还有个避不开的永恒的话题需要讨论，那就是使用商用引擎还是自研引擎开发游戏。没有绝对的好和坏，只有看是不是适合团队和项目。通用商用引擎的优点是实现的功能面广，工具链完整且易用，稳定性好。但是如果项目特殊需求多或者对技术水平要求苛刻，要求在某些方面深挖，就不如自研引擎灵活了。由于自研引擎有源码，且一般代码量少，所有模块都能完全掌控，只要有了方案，整合进引擎非常容易。而如果使用Unity这种没有源码的引擎，面对特殊需求只能用一些怪异的方式拼凑出来一个低效的方案，或者干脆劝说策划放弃。UE4虽然开源了，但是单单运行时就200万行，国内敢改底层的估计也就腾讯、网易这样的大厂了。概括来说就是，自研引擎是“倒吃甘蔗”，而使用商用引擎开发这个类型的项目正好相反。

 

当然，对于自研引擎来说，团队的技术实力也有一票否决权。如果引擎团队没有个有经验的负责人，或者公司舍不得投入资源，那千万不要染指自研引擎，还是乖乖地用Unity或者UE4做常规一些的项目吧。