WebGL Roadmap

@JamesArndt, being well aware of the limitations of Unity's WebGL implementation. Do you have any information regarding WebGPU's status in Unity's roadmap? Playcanvas already has confirmed their intention of implementing it ASAP, while having prototyped demos of it already and there's strong continuous movement towards the completion of the specification by major browsers.

To quote the recent Khrono's group meeting on WebGL, November 18, 2020;
https://www.khronos.org/blog/webgl-happenings

Project Tiny is great on paper, but it's still years before being usable. And it relies on having to 're-implement' a lot of Unity's features and components in DOTS. Something WebGPU is not forced into.

Thanks

 

I do not personally have information of if or where WebGPU fits into Unity's plans in regard to WebGL. I do have access to the team and folks who work on the WebGL platform. I'll poke around and ask what is able to be publicly shared on that front.

 

It is not just Unity implementing features that you have to worry about, the browser developers must play well too.
Most browsers target low-power use, they use your built-in GPU, not your dedicated graphics card by default on desktop. Mac Safari will complain about Unity's webgl (probably all webgl that works a bit) saying it is energy/power hungry!

WebGL seems destined to fail for powerful graphics unless the platform builders make power-hungry content acceptable on the web (something Apple has always been against).
Yet the web remains the ideal platform - it is shared on all devices - no more build and distribute for all the device types.

 

I've asked around with our internal WebGL platform team. There aren't any public announcements planned for WebGPU and the team may do testing or experiments with the technology throughout the course of the year. From what I'm hearing the spec is experimental and browser support is variable. For the time being it doesn't appear to be a solid foundation to build tools on top of. The good news is I've discovered that WebGL support for mobile is a priority and being worked on.

 

I looked into Tiny, it looks really incredible. After spending some time trying to reduce my build size, as most of my project is just code, and seeing how there is definitely a lot of fluff there (26mb unity dll). I would like to target across more devices, particularly in emerging markets as they are the fastest growing atm. I wonder if it's possible to use Unity as a library as well? I remember talk about this during 2018. Well my main issue is Linux support atm for Tiny is still in experimental. So I will probably wait another 6 months to touch it. But as I only really want to use DOTS and Burst at this point and enjoy making lots of systems from scratch, Tiny seems like an awesome solution.

 

One could build an entire 3D, furnished, animated, networked world using the old webplayer infrastructure in under 8 mb. Basically game ready aside from lore and trappings. If we are back to that place with the incredibly slick integration of the old system then I personally will thank the stars and rush back to developing on any platform that holds that promise. And this isn't a "Eheu Me Miserum" post for time past, hopefully more an Aide-mémoire and yardstick from a passionate fanboy who testing the pants out of stripping the old system.

 

This is exactly what i'm thinking. Looks very early to use in production, but definitely keeping and eye on it.

 

Agreed, tiny looks promising but it has a long way to go. Like many that have client projects using WebGL, I am keenly keeping an eye on project tiny and the moment it becomes advanced enough and stable enough to use in production, I will be swapping our entire project over. Problem is right now its workflow is constantly evolving, so it would not make sense right now as one would end up constantly having to rewrite. But once they have nailed all of that down, I am sold.

 

and how many folks work on the WebGL platform (if not secret)?
I have impression that WebGL is not moving forward at all.
Time by time i am reading this forum section and to tell the truth i have no idea what is going on with WebGL.

 

Did you check out the 2021.1 beta changelist? It just got a bunch of WebGL fixes. I do hope that continues in future Unity versions, as project Tiny is a dead end due to having to use DOTS.

 

It's great, but...
I would like to see some kind of summary... "where we was, where we are now and where we are moving". Maybe some charts of performance and size improvements over years and with look on future.

current state of multi-threading?
"we plan to support multi-threading for our internal engine code using Shared Array Buffers" how far you are with this? any performance improvements from this?

 

I just want to thank you for taking the time to explain all of this so that we know what's going on and what we can hope for in the future. It's much appreciated.

 

I fully acknowledge that, recently, I have become a vocal critic for the lack of C# multithreading support in Unity's WebGL player. I love Unity but I dislike how WebGL has been neglected.

Therefore, I am going to ask -- given the extended timeframe for tooling upgrades and fixes, and now a reduced roadmap priority -- where are multithreading limitations communicated in product documentation? Specifically, where is documentation which describes which .NET collections in the concurrent namespace fail or which .NET features are limited in the WebGL player (i.e. no HttpClient, no async/await). While I am appreciative of the communication the execution has room to improve!

 

Plug for UniTask, which allows a single-threaded async/await integration that works in WebGL. Obviously doesn't improve performance the way multithreading can in principle, but great for those of us who like Tasks/Await/Async better than coroutines, and great for web requests etc.

 

@travlake I thought the same and converted code over to it. Unfortunately, I found it to be unstable in certain scenarios that started and ended on the Unity main thread w/ async/await. For a while, the library used ConcurrentDictionary which will randomly error in WebGL -- and that has been fixed. It may work for you but might not hurt to test thoroughly and proceed with caution.

 

Look forward to seeing smooth running on mobile devices. Our main target platform is WeChat minigame which is for iOS/Android. Our casual games have many users now. To us, compressed texture(for iOS memory), lighter engine size and faster boot time(close to other H5) are most critical.

 

Hello,
I have a question, why builds from Unity 2017 works perfectly on old devices from 2013, but from 2018+ doesn't?

More detailed analysis shows the difference in how Unity compiles shaders. Here is a link on both files from 2017 and 2019
https://gist.github.com/Adeptus-Astartes/4e02d3e8db1a88cb03d65f89d475a9e7

Getting logs from old mobile phones shows this error.


So look like unity by default using high precision, but I want use medium. How I can control this?


We want to cover as many devices as possible on a newer version of unity rather than using 2017

Thanks for any support!

 

I think projects are more and more "online". So I think that WebGL development has to be quicker ( my simple opinion).
For me is frustrating to create a nice unity win app....and cannot put it ( with changes of course) online for my client.
If I use webgl1...well it can work but I don't have the visual feedback of webgl2 with urp. Webgl2 works on win but not in mobile....so no compatibility. I don't want to use other tools like babylon, threejs, verge, ec... but they are now the only way

 

Hi,
Just digging into compatibility with old mobile devices (but still powerful enough) to run our experience on WebGL and found an interesting thing. Unity2018.2.21 works perfectly on all devices, but the next release Unity 2018.3.0 contains some breaking changes.
The app is running, the audio is playing, but the whole camera view is black. So using chrome://inspect/#devices I'm collected logs from device and there is "highp precision is not supported" error for all shaders.

Note: Creation of internal variant of shader 'Sprites/Default' failed.
UnityLoader.js:4 ERROR: 0:8: 'highp' : precision is not supported in fragment shader

And after spamming error:
GL.End requires material.SetPass before!

Attached full logs, can be imported in Chrome

From Release Notes I saw "Shaders: Generated GLSL shaders for GLSL 3.00 and higher now use medium precision instead of low precision." And for some reason, it builds shader with higher precision instead of medium, (that my test device supports)

So how I can force it to use medium or low precision for all shaders in the project, since it affects also on built-in shaders?

 

Hello, can you please take a brief look on my issue, it is really important for my company

 

Submit a bug report and feel free to open a new forum thread noting the bug report / case number. There's no need to derail this topic / thread with support requests.
https://unity3d.com/unity/qa/bug-reporting
https://support.unity.com/hc/en-us/articles/206336985-How-do-I-submit-a-bug-report-

And see here for the most up to date Unity LTS releases. especially when dealing with Editor builds from previous years, these are the versions with the latest bug fixes you'll want to test with : https://unity3d.com/unity/qa/lts-releases

 

I was wondering when we could see an update to the bundled emscripten version.
Afaik the version included with Unity is 1.38.11 from 2018.
The newer emscripten versions have the new upstream backend instead of fastcomp, which creates smaller and faster .wasm files.

 

Is there any way to get JS stacktrace from exception? Currently, we have only two options. No stacktrace or very expensive il2cpp generated stacktraces - these are basically useless in production. We constantly get exception reports from our users (via cloud diagnostics). Unfortunately, it's very hard to track a source of common exceptions (like nullrefs or index out of range exceptions) without stack trace.

We tried to workaround this issue, by implementing our own log handler. We catch all LogException calls, and inject native stacktrace by calling js stackTrace() function through jslib:

Code (JavaScript):

1. var JSStackTraceModule = {
2.     jsGetStackTrace: function (buffer, size) {
3.         var st = stackTrace();
4.         stringToUTF8(st, buffer, size);
5.     }
6. };

With this hack, we can at least track where exception was caught. We call Debug.LogException every time we catch any, so we can tell which module requires further investigation, but still it's not the exact throwing function.
This could be easily fixed if js stackTrace was called from Exception class constructor. We cannot implement this solution on our own (ILPostProcessor could help, but it's only for script assemblies, and it's not executed for system dlls). I even tried to decompile .wasm file and inject code there, but this solution is waaaaay too "hacky" to work in production code (but it was fun to try it anyway ).

Is there anything we can do, to get js stacktrace in cloud reports?

 

We are now using the LTS releases of Unity, but we are not sure how fast these kinds of WebGL updates and other fixes find their way to the LTS versions of Unity.
Looking at the best speed/performance for our WebGL builds, would you recommend using the latest Unity version, maybe even the 2021.2 alpha? (There are a lot of WebGL fixes in those release notes)

 

Unity webgl in mobile browser is now possible!!!
https://forma.dl.it.unity3d.com/

What unity version is needed to build a webgl project that can works on mobile browsers?

 

Always was, it's just not officially supported. And won't 'easily' work for all devices.

 

Yes but this is an official Unity3D demo... and it works fine on many mobile device!
I need to know more...

 

Just tried a WebGL build in 2020.3, 2021.1 and 2021.2 and I noticed that 2021.2 built to about a 2.4 Mb vs 9 Mb in the others amazing work!

 

@Arowx That's amazing! I'm going to have to spend some time trying out 2021.2 to see what our results are (our WebGL app is at 7.24mb in 2021.1.1f1)

 

WHOAH!!! Did you guys see that?

2021.2.0a19: Changelog

WebGL: Enabled ETC/ETC2/ASTC/BC4/BC5/BC6/BC7 compressed texture formats for WebGL in editor, build and runtime.

ASTC!!! Now you're talking about!!!

 

But the loading time is still long. Modularity / engine cutting is needed.

 

The same compress format(gzip, brotli, raw) ?

 

I couldn't get any difference on the non compressed versions but I got a significant decrease in size with compression in 2021.2. Could you check if the build are any different without compression?

 

2021.1.1f1 - Code Optimisation - Speed
None - 27.7 Mb
Gzip - 9.05 Mb
Brotli - 7.04 Mb

- Code Optimisation - Size​

None - 24.2 Mb
Gzip - 8.09 Mb
Brotli - 6.43 Mb

2021.2.0a20 - Compression - Compiler Size - Speed
None - Speed - Fast - 26.5 Mb
Gzip - Speed - Fast - 7.8 Mb
Brotli - Speed - Fast - 5.87 Mb

None - Size - Small - 20.6 Mb
Gzip - Size - Small - 6.4 Mb
Brotli - Size - Small - 4.99 Mb

Between about 1 and 4 Mb smaller.

 

Would be great if we can speed up load times. This is the number 1 reason stopping us currently from jumping all over this

 

I think you can with async loading of scenes, so if you have an intro or menu/options scene load in fast and first then load in the main game scene in the background.

 

Super, thanks for taking the time to share the data

 

Same here, often having to fight to justify using Unity for webgl over other solutions

 

Already under works 4 years ago Still got slow loading times...

 

Whilst I haven't "Given up" on this ever being anywhere decent, after 4 or 5 years ones confidence does get a little jaded. The total lack of noise about the entire project area just screams "shelved"

 

Kronos group got time^^
Time to dev and time to run code....
THose ones are dumb lamers and did nothing correct since they're born !

Now that proper things are said, i have to be pityfull for U3D devs working on this sh*t and ( i guess ) having to do something right and usable with it :-(
I'm really sad for you guyz !

When i used the U3D webplayer more than 10 years ago i guess it's now impossible to be satisfied with web things.
All was so simple ! and efficient....
I'm still surprised no browser is able to run some code ( except intrusive ones like amazon or other viruses ) and run U3D application at the CPU speed !
Even with time loss for building a target texture used for a graphics.quad on webgl^^

I have to thank a lot @jukka_j for explaining us all the team life this is nice and kind !

The webgpu is at least as promising as was webgl 10-15 years ago. I guess i'll be dead when it is integrated in browsers.... :-(

I however come with a question:
There was once a wonderfull thing called webplayer, showing a browser can really run 3D. Then there was a useless pile of sh*t that replaced it, called webgl.
Isn't there something that replaced webgl ? Even if not as perfect a webplayer but at least something that allows to make 3D in browsers ? :'(

Thanks ans GL for your devs

Happy unitying !

 

in short. no. unless you are saying is there anywhere in the gamut of programming, well then yes.
However the applications vary and the platforms and languages. However solutions have been posited https://www.babylonjs.com/ is one that a google search would reveal. Among a wealth of other contenders.

It would be nice to squeeze some extra performance out of webgl please.
I recognise this is a highly technical task with insurmountable upstream roadblocks and fundamental architectural shifts are often required that can take years to bloom.

However just some updates please about the current roadblocks would be great. A friendly blog post maybe. Thanks people.

 

What you are looking for is WebGPU.

WebGPU is the blood ancestor of WebGL but redesigned for modern processors and graphics-card capabilities. Issue is, WebGPU is just too cutting edge right now and not all browsers support it the same way (creating a maintenance nightmare for Unity, which is why we don't have WebGPU yet).

Once things become more stable, Unity plans to drop WebGL in favor of WebGPU — but it could be a while.