Wonder与Unity3D、Threejs等同类产品的比较


#1

对比Unity3D

Wonder的优势

1.性能更高
Unity3D在Web端非常慢,因为它使用webassembly和Asm.js,中间绕了一层。

而Wonder快多了,因为:
a)因为我们直接使用webgl原生api
b)多线程
c)采用data oriented架构

2.扩展性更好
a)使用函数式编程
扩展粒度更小,我们可以支持函数级别的扩展。

b)能支持各种环境的应用
因为我们支持渲染管道定制。

虽然Unity最新版本也支持,但我们是一开始就完全支持。

c)使用微服务

3.用户体验更好
a)直接运行在web端,能利用各种web的技术来优化用户体验(如stream load, …)

4.移植性更好
a)包体更小
b)运行在浏览器中,而浏览器是跨平台的

5.开发统一
a)Wonder的所有产品都使用编译到Js语言的Reason语言

对比Threejs

Wonder的优势

1.提供完整的解决方案
a)Wonder的编辑器是核心产品,专门设计来给用户使用
b)Wonder未来会提供更多的工具,打造更好的生态

2.性能更高
由于Wonder使用多线程和data oriented,因此比Threejs快。

3.扩展性更好
Threejs是继承架构,而Wonder是函数式编程+ECS架构,更灵活。

4.代码质量更高
Threejs直接用Js语言,而Wonder的所有产品都使用编译到Js语言的Reason语言,有强类型的编译检查做保证。

5.文件更小
Wonder完全使用二进制数据来保存场景的包(.wpk)和模型(.wdb),数据更小,加载更快。

6.能支持各种应用场景
Wonder支持job管道,类似与Unity的scriptable render pipeline,能通过配置job来灵活支持各种应用场景和各种平台。

对比Playcanvas

Wonder的优势

1.性能更高
由于Wonder使用多线程和data oriented,因此更快。

Playcanvas的整体性能比Threejs慢。

2.扩展性更好
Playcanvas没有支持扩展编辑器和引擎,而Wonder在2.0版本就会重点支持这些扩展。

3.代码质量更高
Playcanvas直接用Js语言,而Wonder的所有产品都使用编译到Js语言的Reason语言,有强类型的编译检查做保证。

4.文件更小
Wonder完全使用二进制数据来保存场景的包(.wpk)和模型(.wdb),数据更小,加载更快。

5.能支持各种应用场景
Wonder支持job管道,类似与Unity的scriptable render pipeline,能通过配置job来灵活支持各种应用场景和各种平台。

6.Wonder支持同时运行/编辑场景,而Playcanvas需要开一个新的标签页来运行场景。


于置顶 #2

#3

大大好,我其实还是不太能 get 到,一点拙见,请多指教。

Unity 的 Project Tiny 就是为了解决 H5 的这些性能和包体问题而生的。同样采用了 DOD 架构。将来的性能很难说无法赶超纯 js 方案吧。

跟客户端相比 pwa 的用户体验没优势啊

开发者也必须使用 Reason 才能编写游戏吗?


#4

你好朋友,你是cocos creator的开发者吧?谢谢你非常专业的反馈~cocos creator做得很好,感谢你们的开源和贡献~


#5

Unity 的 Project Tiny 就是为了解决 H5 的这些性能和包体问题而生的。同样采用了 DOD 架构。将来的性能很难说无法赶超纯 js 方案吧。

Unity发展得很好,最新的版本也采用了DOP和多线程渲染。
不过Wonder从一开始就是为大型场景设计和考虑的,因此引擎端完全使用多线程+DOP架构。比起Unity,我们没有历史包袱,可以在巨人的肩膀上前进。

我们也非常感谢Unity的贡献,它的组件架构给了我们很大的启发。

跟客户端相比 pwa 的用户体验没优势啊

这个确实是,我们已经改了文案,谢谢你的提醒。

开发者也必须使用 Reason 才能编写游戏吗?

等下个版本加入脚本后,开发者可以使用Js或者Reason来编写游戏。


#6

是的,谢谢!1234


#7

欢迎多多交流哈~互相学习~


#8

请问这个在 web 上是如何保证的?js 不是无法自己管理内存吗?难道你们把同类型组件的所有数据都存放到一个非常大的数组中?组件其实只是一个数组的 index?


#9

是的,我们确实把同类型组件的所有数据都存放到一个Buffer中,组件其实只是一个Buffer的index。

详见Data Oriented


#10

666


#11

虽然不知道你们在讨论什么,但是感觉很刺激啊,wonder加油啦,可别经常停水


#13

恩,我们会继续加油的,谢谢支持,欢迎继续关注~


#14

看到两位大佬讨论,很刺激。。


#15

:grinning:


#16

你好,请教个问题哈。

按我的理解 wasm 和 asm.js 会导致包体积变大,但是在密集型运算上面也有优势,为啥 Unity3D 会很慢,绕一层是指得是哪些地方绕了一层?

还有,wpk 和 wdb 也许在传输上可以节约网络资源,但是相比于 GLTF 优势有多大?在 GLTF 已经成为标准的情况下再造一种格式是否合理?


#17

用wasm后包体积会变小(变小1/3左右?)。

unity3d->webgl的性能可以参考2016年playcanvas 和unity的比较: PlayCanvas versus Unity WebGL

慢了4倍。

现在unity3d->webgl的性能我不是很清楚,具体在哪绕了一层我不是很清楚。

wpk和wdb是二进制文件,相当于wonder版本的glb文件(glb是gltf规范中的二进制格式文件)。
wdb和gltf可以相互转换。
wdb是优化过的二进制文件,相对于glb文件,解析速度更快。

wpk=scene wdb+asb
(asb是资产二进制文件,scene wdb是场景的wdb)