WebGL Roadmap

Hi there;

Our company is developing 3D Configurators, and our main project is based on Unity.

We are very happy with how things go in general, but we still struggle when it comes to WebGL load time & memory usage.

So far we use every technique available in 2018.2 that we know of :
- Code stripping
- Asset bundles
- Wasm
- Brotli
- Data caching
- Reducing the assets in the project

I'm not here to complain; I would very much appreciate to have a timeframe about the upcoming improvements, such as :
- Streaming Instantiation
- Unity Tiny 3D
- Any upcoming improvement you might be working on.

This would help us a lot prioritizing our projects.

Thanks a lot.

 

https://blogs.windows.com/windowsex...better-through-more-open-source-collaboration

And then there were 3. Not sure how I feel about this in general, but the immediate benefit will be webgl 2 + threads is definitely coming to edge!

 

I'm excited to see that the webgl2-compute context appears to be becoming available in a near future Emscripten commit, see this pull request:

https://github.com/kripken/emscripten/pull/7612

This basically brings the OpenGL ES 3.1 feature set to WebGL - such as compute shaders (and I think geometry shaders). With a bit of luck, we might see it in Unity at some stage as well - although I'm sure there'd be a bit of work involved but it's a nice intermediate solution before WebGPU which is no doubt a while away.

Since it's a context, hopefully it doesn't mean having yet another separate fallback build but rather it'd be similar to how WebGL 1.0 and 2.0 are handled in the current builds.

 

Have you tried Safari's webgl 2? I actually got around to enabling it the other day (it's been behind a flag forever) to see how far along it was. Turns out it's basically unimplemented. Worse, the last time they've worked on webgl 2 was in 2015 (https://bugs.webkit.org/show_bug.cgi?id=126404)! I don't know why they even bother putting it behind a flag.

My bet is Safari will never support webgl 2. They definitely will never support compute in webgl2.

 

Considering how Apple is and how they like to do things their own way, my guess is that they are skipping WebGL2 to concentrate on WebGPU(which they proposed and is basically Metal for web).

 

Sheise, that basically means we can't upgrade our games to make use of Linear colour space =(. What a pain in the ass. Is webGPU something that will help this?

 

Hello! Could someone please explain differences in WASM (if any exist) between unity 5.6 vs 2017 vs 2018 vs 2019?!
For example: any runtime performance improvements, build size decreasing, runtime memory consumption, crash/bugs stability ?

Also I have see some features like
* streaming initialization (cant test yet)
* multithreading only for unity-engine (cant understand profits for my game, but waiting for custom-threads-support)
* heap grow (also I have question related - is it reduces memory-fragmentation-OOM cases? and allocates without copy-to-new-grown-area ?)
* some default options changes (no profit)
.. it's all?

What is constant in those 2 years is very long build time (in asm.js and webasm too).. will be any improvements?

 

Hi guys,
Just read this article about WASM future improvements : https://hub.packtpub.com/mozilla-sh...y-and-make-deeper-inroads-for-the-future-web/
They talk about Implicit Data Caching. This would be a massive improvement in load time.
Any idea when we could see this with Unity builds ?

 

Big news: Safari on iOS 12.2 (beta) works with Unity wasm!!! The extra memory for their jit compiler did the trick! I loaded up our applications for the first time on my iPad today! I could cry I'm so happy!!!

 

Which Unity version?

 

2018.3, but I'd be surprised if it didn't work for older versions of Unity.

 

I don't think the build time is long its just the compression that is long? If im not mistaken. Which is fine broji or what ever its called is super nice compression. Its worth the wait.

 

Hi
I would love to have some update about incoming upgrades for Unity WebGL / Wasm.
Any news @Marco-Trivellato ?

 

Ya id like to know whats planned for the future as well.

 

Thanks !
Hopefully we will get a smaller engine someday. Then just the WASM roadmap looks promising.
Cheers

 

Can you do something about the memory issues its absurd, I dont see how anyone can actually use it right now in real projects.

 

what memory issues?

 

Nevermind

 

Hi and thanks for the good work on the webgl! I still have some questions though.
Is the Unity's weblgl port still limited to 32 bit typed arrays in the upcoming 2019+?
I read that the memory limitation has been removed from 2019+ player settings.
Does this mean we can have larger webgl applications and no memory crashes on large 3d models?
This would be really good news, since we could finally consider using Unity as an engine in our apps.

 

I have tested Web build with 2019.1f1 and SRP 5.10 and it seems that it works.
Did I miss something, is SRP supported in WebGL now?

 

It doesn't work on browsers that don't support WebGL2.0 like Safari

 

It wasn't the case some time ago when I tested lightweight render pipeline on WebGL builds, with proper browsers.
Now it appears that it is working, great.

 

What wasn't the case?

Last time I checked(2019.1) LWRP - runs on Chrome(WebGL2.0 support), doesn't run on Safari(Doesn't support WebGL2.0)

 

Ok, worked for me on WebGL1.0, but after I removed the post processing stack, turned off shadows, set quality level to very low, etc... not sure if removing the post processing stack was enough, but I just wanted to check if it can work.

 

Google conference about WebGPU yesterday :

Is WebGPU likely to be a build target for Unity ?

 

I posted another thread about this too. Curious to hear if there are any plans for this within Unity.

 

Good news about loading time : Chrome will introduce implicit caching (what I understand as caching compiled WebAssembly)
source : https://hub.packtpub.com/v8-7-5-bet...icit-caching-bulk-memory-operations-and-more/

Edit :

more details here :
https://v8.dev/blog/v8-release-75

I just tried on 75, we get the same behavior as previously : loads from IndexedDB correctly, but nothing more.
"not stored in the indexedDB cache due to the error: DataCloneError: Failed to execute 'put' on 'IDBObjectStore': A WebAssembly.Module can not be serialized for storage."

 

Can we get a followup from Unity concerning the above error? With the new Chrome implicit caching feature, finally we could see Chrome loadingtimes of WebGL improve.

Or are the memory operations be supported by compiler? So in that case we need a new Unity version?

 

No answer since may.

 

I wish they had a paid-only forum where discussions like this were guaranteed to have Dev responses ...

 

So in laymen terms does this mean subsequent reloads of webGL content would load much faster?

 

From my understanding, you would store in the cache a compiled wasm, hence you would save the compiling time when loading, which is quite long with Unity engine.

 

Sounds like this would really help with the long, long loading times on mobile. I figure I might be able to overlay some kind of animation overlayed with CSS and HTML on the first load (too keep the player occupied) and then on later, shorter loads they can start playing much sooner.

 

About implicit caching :
I just saw this post saying that Chrome 75 should have implict caching, in fact a bug prevented it to work.
Chrome canary 77 SHOULD make it work.
I will try ASAP, if someone have positive results, it would be an awesome news.

 

We tried Canary 77 few days ago and it works

 

Hi there !
Apple release few days ago a new Safari version with WebGPU.
It looks very promising.
Any plans for Unity to consider this technology ?

 

WebGPU. Interesting, but much of the issues with WebGL & Unity are around memory limits, CPU hit and mobile compatibility (dead on iOS last time I looked), also over-sized footprint of a simple Unity webgl app.
Any news on when webgl is in a good state on all mobile devices?

 

Project Tiny will probably overtake WebGL, it's only 2D at the moment but if it moves to 3D it would be ideal as a lighter replacement for the current bulkier WebGL stack.

 

Any info on that, in terms of timeline? Because the webGL implementation is kind of crap.

 

Well the streaming project seems like a better solution if it didnt require a windows pc to operate
https://forum.unity.com/threads/uni...6.1579290256.1569111626-1286865226.1563222499

 

Bad news: It's already broken in iOS 13.x

 

Yeah but I got them to fix it already: https://bugs.webkit.org/show_bug.cgi?id=200807

So 13.2 I guess it'll be fixed again.

 

Deploying for WebGL and then it doenst work on Mobile Devices is really dumb... then i dont need to Deploy it for WebGL because the majority of People already Surfing through the Internet and Playing on their Mobile Devices.

That Problem seems to Exist now since the Beginning and there is no Movement at all to increase the Unity Web Player performance, thats really sad. Maybe Concentrate on Existing Features rather then implementing new ones.

 

I'd love to see WebGPU development by all major browsers Edge, Safari, Chrome and Firefox. About a year ago or even longer by now our second development team went over to ThreeJS because it was a lot faster to start up and a lot faster to build than Unity WebGL. It also has support for Mobile. The downside about ThreeJS though is is that you miss all the engine features that Unity provides.

Our current use case is a heavy scene in WebGL with a lot of objects (such as MegaCity for instance, lots of objects lots of different materials). Being able to swap in and out pieces on demand. Assets that are loaded in dynamically (native GLTF support? or runtime fbx or ifc?) and updateable without rebuilding. For instance updateable all the way from Revit to the web app. But because of content being dynamically loaded with from the outside and swapping in and out parts, we cannot bake lighting. Things are dynamic and not static. Everything is realtime lighting, which is expensive to do on WebGL especially together with the huge amount of draw calls because of all the different objects and materials.
For a native app this would be doable but for a web application it is currently way too heavy.

I'd love to see a solution for web applications to use the device's utmost potential within a browser close to that of a native app. Metal / Vulkan like performance. It sounds like WebGPU does that. But I also would like to see multithreading, fast loading, easily updated content from any 3D solution (revit, Blender, 3DS Max, Maya). Be able to throw anything at it and still run 30 ~ 60 fps. Platform compatibility for all browsers. Quick building and not waiting 5 ~ 10 minutes for every new build but rather in a matter of seconds.

So many things I'd love to see happening with web applications.

If all that happens I want to make an example project and make them reconsider to use Unity again (even though a lot of development has gone into ThreeJS already). But progress is so slow for web apps and I don't see progress happening anytime soon...

 

WebGPU is a mess (they still haven't settled on a shader language...Apple is moving forward with their own creation WSL, Google/Mozilla is moving forward with SPIR-V); it's still far away I'd guess.

 

And it fixed again in iOS 13.2

 

Might be of interest to some - looks like people are actively working on bringing WebGPU support to Emscripten (the toolchain Unity uses to output WebGL builds) which is exciting. WebGPU itself is probably a ways off yet (not really any support outside of OSX) but I'll be looking forward to the day it's available, or at least when more than a few dozen developers running nightly browser builds can run it .