WebGL Roadmap

Thank you for the link, looks like things are pretty far along! I hope that everything gets resolved soon It would be a game changer for WebGL content!

 

Seems like you guys have put Multithreaded WebGL in the 2018.3 roadmap, definitely excited for it, do you think this will increase the initial loading performance as well? Downloading the content aside.

 

I know about the Shared-Array-Buffer issues been following that for a long time hoping it would get resolved. I understand it would be experimental, hoping that the site isolation issues get resolved and that the web can get multithreading. I'm excited to see any progress on it and thank you for referencing me to the Chromium issues Marco, I greatly appreciate it. I'm excited that it would mean it would be easier to dynamically load content with threading.

 

How do you want to keep backward compatibility? With Jobs system it's easy, because you can emulate jobs on main thread, but full multi threading seems like a real challenge. 2018.3 will have only Jobs system right?

 

So in 2018.3 we will have engine running in multi-threaded mode, but does it mean only engine core or core + jobs system? AFAIK jobs are not C# threads, because they require native-like code (no reference types, no garbage collector). Full C# threads support is not that important since ECS and Jobs are getting more and more features. I think unity should focus on Burst and jobs rather than C# threads. But that's just my opinion, maybe I'm wrong

I'm fine with compiling two versions (ST and MT), but it has to be an option in player settings, just like you did with linker targets: asm.js, wasm or both (so here: single-threaded, multi-threaded, both). It is extremely useful, because you can have faster build times for test builds.

 

Question. I have been using WebAssembly on Unity 2018.2. On firefox, this drastically reduced our startup time. However, on chrome, it actually increased the startup time. Any idea as to the reason for the disparity?

Also, couldnt find anywhere in the UnityLoader.js that you guys are actually calling WebAssembly.instantiate. How are you guys actually instantiated the web assembly object? Was trying to find it to see if you guys are using instantiate vs instantiateStreaming for performance

 

good news https://v8project.blogspot.com/2018/08/liftoff.html

 

Awesome!.. this is really good news!

 

Now my game use LuaJit in webGL platform. what should i do,that i want to export my game.

 

Hi. Does anyone knows if we can expect OpenGLES 3.1 (with compute shaders) with WebAssembly in the coming months or years ?

 

You will have to wait for webgpu for compute shaders; I'd bet still years away. At this point I'll take Edge and Safari supporting WebGL 2...

 

Hey - hope its ok to post this here ...

We are building an educational application to teach kids about solar energy. We have panels on a home and are simulating movement of the sun. In the editor, shadows and the sun's reflection on the panels add great context. But when we export the project using WebGL, none of this works in the browser (neither shadows or the reflection).

I've seen similar posts about WebGL, but those are at least two years old now. Thought those issues would have been worked out by now ...? I am aware of the quality settings and think I've done things right on my end, but maybe not ...

Any advice or is it just the case that these features still don't work (well) in WebGL?

Thanks

 

Shadows and reflections work fine in WebGL. If you do in fact have the quality levels set properly, perhaps you used custom shaders that aren't compatible.

--Eric

 

Pretty sure I've applied the quality settings correctly, but am attaching current settings just in case I've missed something. Beyond this I am simply using a point light with soft shadows enabled. And, just in case there could be something with shaders, I just output a build with two simple cubes (standard/default materials and shaders) with one cube casting a shadow onto the other. Works fine in the editor - does not work in the WebGL build.

For whatever its worth, the point light is simulating the movement of the sun. So the light and all shadows should be moving continuously. I wouldn't think that would add too many complications, but ...

Lastly, in the event there was something up with my use of a point light, I added a simple directional light casting a soft shadow (no movement). Again, the soft shadows show in the editor but not in the WebGL build. Considering all these tests, it would seem that the light and objects (simple cubes) are not the problem. What else am I missing?

Anything else I can look into? Losing my mind a little ...

 

So your webGL settings are on the lowest possible, which may be the source of the issue (see the green checkmark). They aren't actually using the 'Good' Values. I agree that this is a confusing thing with the UX.

Click the arrow and change them to a higher quality setting

 

Wow - that was it! On behalf of all the idiots in the world, I can't thank you enough

 

I was wondering if we can expect or not that Unity with Webgl in webassembly mode will at some point catch up with a webgl solution made through something like playcanvas (in terms of performances, but also build time and so on).
Playcanvas is really not my cup of tea, as it is lightyears away from Unity in terms of functionnalities, but build times are quasi instant and it works on mobile.
What can we expect from unity in the future when it comes to building for browsers and mobiles? Is that a door closed for a long timeframe? Will we see for example a Unity for mobile first or something ?
Sorry for the possibly very uneducated questions!

 

@yoannG There was an article here that the Unity team wrote about performance. With the upcoming improvements and the ability to have managed multithreading in about a year, maybe less, they're starting with internal threads and the Unity jobs system first, I think that Unity WebGL would be something to be on. I even wrote a post on performance and it's improvements, here. With this being said, you will have to do a lot of optimization to your game to get it running smoothly on WebGL, and loading as fast as possible but that is the case with any platform anyone publishes to.

 

@Dan_NextRevC
"With this being said, you will have to do a lot of optimization to your game to get it running smoothly on WebGL, and loading as fast as possible but that is the case with any platform anyone publishes to."

This is where i don't know what to think.
If i have an empty scene in playcanvas and an empty scene in Unity, the difference in build times and loading is tremendous... or is there a way to make Unity reach the same perf in some ways already?
That is the bottom line.. either Unity gets to be as performant as PlayCanvas, or it is forever doomed as a possible solution.

As it is now, i have no means to pitch Unity as a game changer for web to big companies..
I was in an interview at a 400+ people design company, and they were skeptical for good reasons..

Bottom line: what is the roadmap of Unity to change this ? Is it even achievable ? When ? 2 years ? 4 years ?
What is the vision of Unity on the matter ?

 

@yoannG I do have to disagree with you. As stated in my article I wrote describing how I got an empty scene loading down to under 3 seconds on all desktop browsers that I tested on, I tell you what I took out and how I reduced the build size as well as the loading times across multiple browsers, additionally in the article written in the Unity Blog describes the improvements. I recommended to my company to move over to Play Canvas, for the time being, for our initial launching of a product, due to it's speed, we are now working towards transitioning back to Unity and my tests were one of the steps taken to prove that Unity had speed. Unity is easier for artists and has a lot more plugins and is more mature as a game engine so we are eager to move back. Once there are managed native threads available which I expect 2019, and there will be internal ones available through the jobs system in 2019.1, if you look through this thread. I do expect Unity to gain even more engine initialization loading speed after managed threads area a thing. What I expect you are doing and seeing is the fact that Unity first downloads the content of the project, which can be streamlined by downloading certain things after the experience has been started, or you are using complex shaders, which would slow down any engine to compile. Additionally Firefix loads it the fastest so I recommend that any demos you do are on there. If you upload a 200mb project you are going to have to download 200mb then start the engine. I do recommend you look into what exactly is in the loading speeds and what type of projects you are going for. Build time is slow, yes I agree there, Web Assembly is something the internet is excited for and companies are banking on it.

 

That´s what I did and still do unless Unity WebGL stays incompatible to mobile.

 

@Cascho01 From my experience and the Unity Technology folk can correct me here. Unity's incompatibility to mobile is that they do not support the full feature set. As mobile browsers improve I would suspect that Unity will support them. Also, you can run WebGL on mobile, as I said, with heavy optimizations because build should be about 20mb and download the rest during runtime. The warning message is there but you can remove it with a custom loader.js.

 

Please do it, I can't wait!

 

This is great news!

Is there a current closed beta of any sort that we can apply to be a part of? Have a significant client project I'm testing for now, and I would very much like to use Unity, but the current webgl builds are too big and slow. Would love to get involved / help test the new Instant Games platform.

 

Does it have to be based on Unity ECS?

 

This thread is too long.
Is there a way to check the current state of Unity WebGL?

Browsers support, Web API support(Web assembly, Web Workers, Web Audio...), Unity features support(LRP, ECS, C# Jobs System...)

Thanks

 

Check out WebGL Browser Compatibility

 

Unity strikes again big. I can forget PlayCanvas now )))

 

Thanks.
There's no mention for Web Workers. Is there work in progress to use them for threads?

 

With the 2019.1 alpha just landed any chance to see multithreading support in this release cycle?

 

@De-Panther It would be interesting to see if you could write a js plugin that enables web workers and you can send managed code to them. It would probably involve C and JS in terms of languages for the plugins, I remember seeing a thread about something similar. It looked pretty complicated and I didn't have the time to dive deeper into it. Here is a medium article about it. If you do some searching I am certain you can find the thread I was talking about. If you manage to do anything on that end, I would love to know and hear about any progress.

Medium Article

 

@Dan_NextRevC
I prefer not to work on this on my own, unless I must use it. From past experiences(search "WebGL Streaming"), custom solutions like that tends to break after a while...

Currently I mostly interested in the current state regarding to web standards, and how well the WebGL build runs on mobile.(Your empty scene helped to test it, thanks)

 

I believe you (we) don't want web workers for threads as they are not allowed to share memory between them. This greatly limits their usefulness to Unity. Really you want "shared array buffer" support in web assembly which only exists in Firefox and Chrome. So even if 2019.1 has support for threads, you still can't reliably use threads (at least not yet).

 

@kognito1 They seem to have shipped in edge, safari, and firefox according to this, although I cannot find any resources for their bug tracking (edge and safari) regarding it being disabled and re-enabled. Also using web workers would be a nice workaround for now until we get threads and then eventually managed threads.

 

That link is technically for javascript implementations, not web assembly. At any rate it seems I was mistaken, even Firefox still has it disabled in javascript/wasm (https://caniuse.com/#feat=sharedarraybuffer). I'm not trying to be a debbie downer here, but Unity probably won't be the bottleneck on when we can use threads.

I'm not sure there's any value for Unity in web workers that can't share memory. Managing one heap seems quite the challenge already.

 

Awesome share thanks for that tracker. I would be okay with being browser delimited so long as when support rolls out we can just pull the trigger on it, or at least only be partially supported. I agree with web workers, but as I said, it's a real band-aid solution.

 

Also just a note, loving the number of conversations about WebGL mobile and WebGL with regards to the shared array buffer bug, been tracking that one for a long time.

 

It's a bit unfortunate to read on the Emscripten GitHub page that WebAssembly memory growth will be disabled when threading is used. At least it isn't permanent. See this issue for details.

 

Yeah I saw that, a deal breaker I think. Memory growth is a pretty nice way to ensure (or limit on 32-bit browsers) no memory crashes. I'd rather have that than more performance, but I can see not everyone arriving to the same conclusion depending on their use case. Unity should make this clear to end users though that opt into threading.

 

The latest Unity 2019.1 alpha lists "WebGL: Add WebAssembly streaming instantiation support". What is this?

 

A great thing if it's what I'm thinking it is! I suspect this will allow the browser to start compiling the wasm binary while it's being downloaded instead of having to first download the whole file. Probably won't DRASTICALLY reduce load times, but hopefully it will be a non-trivial benefit.

 

The only non-trivial gotcha with the streaming instantiation is that you need to make sure you serve the generated 'wasm' file with the correct MIME type or it'll error out during loading. Unfortunately this is causing some issues for me when serving the content via Amazon S3 (it seems to not play nicely when I explicitly set the Content-Type HTTP header) but that's not really a Unity issue. It'd definitely benefit end users with slower download speeds and/or any larger WebGL builds.