Hi I need to compile the downsides of Unity WebGL (the upsides are build once, use anywhere, but only when it becomes lightweight and performant on all platforms - not sure we there yet! “Unity WebGL doesn’t support mobile devices”)
Unity WebGL vs Unity Desktop/native - e.g. lower CPU performance, less memory on web? What are the memory limits? How does the performance suffer and why and to to what degree on CPU (WebAssembly vs il2cpp)?
Considerations for using Unity webgl vs say PlayCanvas (straight .js) - which I assume comes down to better performance from Unity at cost of higher memory, poor mobile support, less easy to fully integrate with web-page around it?
Far too broad. You cannot compare WebGL with any other platform, it is severely restricted all around.
The #1 feature for using Unity is tooling, with the tradeoff of generally more resource usage (specifically initial load time). JS engine tools are pretty much crap, although to be honest I haven’t followed them in the past 3 years.
It really depends on what you intend to do. If all you need is an orbit camera around a product mesh and some text, you will be doing well with any JS engine due to superior loading time and be able to hack everything together in code. But as soon as you need more complex GUI, more scenes, more assets, more animations, more scripting, more effects, more postprocessing, or more whatever then you are pretty much only trading a few seconds of startup time and a little more memory for far superior tooling and workflow.
WebGL on mobile, and in particular iOS, is pretty much crapware and bad UX and long loading times and frequent crashes and so on. If you have the above single product orbit camera, great, you can do that.
But if you intend to build something closer to an action game, WebGL just sucks on mobile. You are FAR better off making a native app, even if you already have a WebGL version of your game on desktop. Of course it won’t hurt to see how far you can take your project on mobile (specifically iOS) in WebGL you should be prepared for ditching that in favor of native apps.
Keep in mind that WebGL is NOT a single platform! Your WebGL app runs on Chrome, Firefox, Edge, Safari, multiplied by the number of operating systems (Windows, Mac, Linux, iOS, Android, etc) all of which may exhibit varying degrees of feature support and issues, and each requires at least basic compatibility testing for EVERY release! Expect to go bughunting the odd issue that only occurs on one OS and one browser and possibly only on a range of devices.
I meant to say Unity WebGL vs Unity native (corrected) - I tried it in the past and memory was too limited and no mobile and sometimes the lesser GPU was selected on a dual GPU system (!!) - but things have probably changed since… or not.
I totally agree with tooling and the fact you have C#, but truth is I want to persuade other people who are not Unity devs
I am looking at heavy apps/games not simple scenes, even heavy UI.
The web is great for UI, it is great for lightweight graphics, I don’t think it is good for complex and powerful apps and yet engines like PlayCanvas (which is rather too close to Unity in design) and CAD apps like Sketchup running in a web page suggest quite a lot can be done (though I am not blown away by any graphics there).
WebGL’s biggest limitation in my opinion is that it’s not just one platform but rather many platforms: one for each of the major browser manufacturers (two if you count the mobile versions).
I checked out PlayCanvas real quick, at least what I see on the website it seems to have come a long way in terms of tooling. But first sights are often misleading.
Question is, which you have not indulged in: why do you need to persuade other people? Who are they? (devs vs biz?) What is the project? What is the actual decision to be made? (Unity vs PlayCanvas? WebGL vs Native App?)
A couple years ago the business case for using Unity to make a complex configurator was a rather straightforward decision. These days I‘d surely have to take a close look again, and it really depends on the project and people involved.
I would say it’s not fair for Unity, as Unity is a modern engine that has implemented lots of optimization based on Multi-Threading and SIMD while WebGL doesn’t support them. If people want to make games for WebGL only and the game itself is performance-sensitive, they probably should switch to another engine instead. But if WebGL is just one of the platforms, then Unity might be the best choice.
Last, believe it or not, Unity and Unreal are still the best engines the public can get, way better than other competitors.
@zhuchun The article you linked is almost 10 years old!
WebGL was a completely different tech stack back then. Unity has since switched to WebAssembly, Browsers have evolved their WebGL implementations and WebGL v2 has now largely deprecated v1.
Unity WebGL remains fairly crippled because the browser is still crippled. You’re not going to be able to load something modern like 6Gb of assets on Unity WebGL, but you won’t be able to on any other browser-based engine because the browser itself is limited to 4Gb (side note, I can’t wait for Unity to be 4Gb rather than 2Gb.)
Some other browser based engines will let you achieve results that were visually impressive on standalone 10 years ago with less hassle and faster iteration than Unity because they aren’t built on a massive C#/C++ → EmScriptem → Wasm stack.
There isn’t a platform that supports modern game development in a browser, because browsers are still single threaded 32 bit non-simd processes with rudimentary GPU support. If that’s good enough to do what you need, great.
Browsers are not crippled, they are just far more concerned about security, compatibility and stability over game performance or rendering features.
WebGPU may eventually provide us with faster, more vibrant rendering but realtime 3D on the Web will always lag behind every other platform, including low-end mobile devices specifically because WebGL content needs to be able to run on said low-end mobile devices too.
We will probably not ever see cases where a WebGL game would be device-specific, such as “You are running this on an iPhone XXXVIII but the minimum requirement is an iPhone XLIV”.
They are 64-bit processes and with WebAssembly you can definitely write your own multithreaded SIMD code, so you can assume that’s also being utilized internally.
This is not quite accurate. WebGL2 based on OpenGL ES 3.0 GPU support means you can get very good GPU support. The main issues are on cpu (js single threaded) and memory side afaik.
Wasm seems initially a heavyweight hack and mainly used for complex pre-coded systems like Unity and for example Sketchup (free version), but you can mix js and wasm - some minor parts of PlayCanvas are actually wasm (physics I think).
That’s true, however, my first-person experience is somewhat different.
I’m developing a WebGL game on WeChat, they call it a “mini program”. Tencent has a project (https://github.com/wechat-miniprogram/minigame-unity-webgl-transform) that help Unity devs to port their WebGL builds into the format WeChat needs. That repo has been well documented(not sure if the English doc is also available).
Unity WebGL is based on WASM + WebGL…
…Unity WebGL doesn’t support multi-threading so related optimization for AI/Animation/Rendering is not available…
…In general, a native app is about 3 times faster than a Unity WebGL build, thus devs should take care of the CPU end bottleneck…
…GPU Instancing and SRP batcher require WebGL2…
…WASM is about 1.5 times faster than JS in theory, However, Unity is not well optimized for browsers, so JS is somehow lighter than Unity in many cases…
(https://github.com/wechat-miniprogram/minigame-unity-webgl-transform/blob/main/Design/OptimizationPerformence.md)
I would consider Unity WebGL as a thing that’s for everyone, including people using pretty low-end devices. Neither Unity nor WebGL are good choices for performance-sensitive games unless WebGL2 and WebGPU are well-accepted by most devices, I mean, maybe more than 95%. I know that may sound like a big number, but it also means that we still need to give up 5% of players, that’s a lot. Real-life story, in a past game of mine, the whole company made a huge determination before giving up ~2% of players in one of its major updates.
