WebGL Roadmap

Or pretty much 'at all' for the last 3 or 4 years..

 

@Marco-Trivellato or anyone else from Unity, could you share some information about if and when Unity WebGL will be supporting OpenGL ES 3.1? Specifically we're hoping for support for SRP batching, which I guess isn't available in WebGL right now (since it's OpenGL ES 3.0). Or if you could share some info about the possibilities and timeframe for SRP batching in WebGL that would be very appreciated. Thanks!

 

What about Tiny it's early days but it looks like it could be the ideal light weigh replacement for the old and clunky WebGL?

 

Has there been any real movement on WebGPU in the last while? I see it every now and then as a small segment at conferences (most recently at Unite 2019), but any time I try to do any research on it, the information trail tends to run cold in around 2017/2018. The only real tidbits I'm seeing right now are some scattered statements claiming it'll be available in Chrome/Chromium towards the end of 2020, but with no official source on it.

It's a shame browser gaming has taken such a step backwards since the removal of NPAPI. A huge variety of high-quality tools were lost, but not many have been gained in the years since. Unity have been amazing in supporting WebGL as best as possible, but it just seems to be a constant uphill battle against Browser Vendors.

 

It looks like it is still in the development phase https://bugzilla.mozilla.org/buglist.cgi?product=Core&component=Graphics: WebGPU

 

I occasionally check up on this handy little Github page for a reasonably good overview of WebGPU implementation progress accross various browsers. It gets updated every few weeks or so, sometimes a bit more often.

http://webgpu.io/

 

Hi jukka_j, I was wondering how can PlayCanvas performs so much better than unity? I mean, I know about the webGL overhead but still I think there is so much room left to improve the performance building a experience with Unity, this such a slow performance does Unity not usable for the most of my clients since expect the experiences to be as performant as they could be, but unity takes ages to load, builds are so heavy and sometimes it even crashes the browser.

 

I think a lot of it has to do with what goes into the build. If you make sure the physics and other modules are stripped, make your textures small, make your models low poly, and just keep your game small- it's not that bad. I have even got it to work on low-spec Chromebooks. It is true that it will be slower, but the big advantage Unity has over native solutions like PlayCanvas is that you get to use a proper programming language.

 

In my opinion web gl is getting ignored. Filed a bug report 2 and half months ago and still isnt fixed in 2018 LTS.
Included a test project that shows just the issue too.

 

Well, WebGL has slowly been getting some new features. Auto-expanding memory is a big one, and I think 2020.1 has a new template system. Multithreading has/will be added when browsers support it again. It does seem like the big focus on the web has been Project Tiny, but I do wish that more effort would be spent on improving the efficiency of core WebGL systems instead of making a completely new system.

 

Q: Does WebGL still remove assets as well as it used to?

It looks like my WebGL builds are including way too much stuff especially packaged code e.g. I may only use a few elements of mathematics in my code but the build includes every single code file.

Could WebGL, Tiny and Unity benefit from removal of unused code?

 

Correct me here if I'm wrong, but I don't think Unity has ever stripped user code. It has only removed managed engine modules such as physics, animation, ect.

 

Aren't packaged code modules like mathematics 'Unity Engine' code?

 

I don't think so. Mathematics is a C# library, not engine-side managed C++.

 

Do any of the C# > C++ > WASM compiler steps strip unused code, as this would be ideal for web based applications?

 

Yes. But make sure to set the level you want.
https://docs.unity3d.com/Manual/ManagedCodeStripping.html
Also it might remove wanted code, so make sure that all the code you need is marked as such

 

I appreciate that the Unity team started a road map thread. Let me add my feedback here that 'stability' needs to be a high priority. I have seen a regression in quality between 2018.x and 2019.3 player builds. The WebGL player went from great to 'unusable' in one or two point releases.

 

Can you expand a little on what you know about the multithreading situation? I've seen a couple places mention that Unity is waiting on browser support for multithreading, and that browsers introduced it but had to drop it because of security reasons. However, I can't find any info from e.g. Chrome other than V8 introduced support for threads, and Chrome implemented wasm threads in version 74/75. I can't find anything about a rollback or lack of support - everything seems to say it's been supported since late 2018.

I also can't find anything from Unity on timelines for threading support in WebGL - there's another thread about it (https://forum.unity.com/threads/2019-1.597238/), but the last post from a Unity dev was mid-2019.

Since you seem to be in the know, can you share any info / articles you may have? Thanks!

 

Stop using Emscripten and hire some developers with real Web coding experience and just get WebGPU build done, your own proprietary tiny whatever Canvas 2D doesn't cut it, stop moaning and parading around as though you know anything.

 

You do know that webGPU is still in early development right? It’ll take quite some time before the implementation is solid. And when that time comes, Unity will probably be on it to implement it as graphics target.

But a little bit of respect could be shown.
I agree that the current webGL implementation is slow to build and it is far from optimal. But I think tiny is already an improvement though Dots is still far away from production quality. At least you can build for webGL. If it ain’t fast enough well none is telling you to use Unity. You’re free to go for an other implementation then.

 

There is helpful detail here in this thread (https://forum.unity.com/threads/async-await-and-webgl-builds.472994/#post-6157595). Specific to user threads, there was a forthcoming fix and that fix is not being released due to outstanding reliability concerns.

 

Unity...please. There are some bugs that could be quickly fixed but I get the impression that you don't care:
Please take a look at this bug, and this one.

The webcam on safari issue has been reported multiple times...here, and here...

I know mobile WebGL is not officially supported. But come on. Make an effort, please!

 

@jukka_j : I've posted elsewhere about this, but your team should look into officially supporting KTX2/Basis supercompressed textures as an import/export from Unity. Right now you only support DXT1/5 compressed textures on PC, which become uncompressed RGBA 32-bit textures on mobile.

With .basis textures, you only need to support one format and then let the importer at runtime interpret the proper GPU format to convert into in VRAM. It's a very efficient solution for this issue for Unity.

@atteneder on Github has already made a plugin for this (KtxUnity), and it works really well. Our team is using this along with GLTF models loaded at runtime (soon with Draco compression) to achieve impressive results with Unity WebGL on mobile.

Combine this with your efforts with Project Tiny, and Unity would be able to compete with PlayCanvas, ThreeJS, Babalon, etc on transmission speed, import times, and RAM/VRAM usage.

After that the main issue remaining for WebGL would be multithreading, which would be amazing but that's quite a nightmare to get right (never mind our C# compiled code, just getting the Unity engine multithreaded in WebGL has got to be super difficult).

 

@jukka_j That's great to hear! Is this something that's on the roadmap for an upcoming release or is it further out? (would help my own implementation planning)

 

@jukka_j, if some of us want to put some traction on it, is there a roadmap item we can vote on?

 

@jukka_j Great news reading this! Hope you guys could share with us your plans or thoughts on tackling WebGL Mobile builds in the near future. I know WebGL is kind of a dead end since WebGPU is the next step, but I think is going to be a while until it's production ready. So, for the mean time, is there any hope for us who want to persist on using Unity for web builds?

 

@jukka_j : On another related topic, has Unity considered adoption of GLTF/GLB? Our team is using GLB's with Draco and KTX2/Basis textures for runtime importing of optimized models, and the Unity community has put together some nice importers (Piglet, GLTFUtility, glTFast, among others).

I see that there's a preview package for USD, is there something on the roadmap in 2021 for official support for GLTF/GLB?

As an FYI to other devs, you can combine these GLTF importers with the KtxUnity plugin for KTX2/Basis texture loading. Most of these GLTF loaders don't support KtxUnity out of the box, but it's possible to do it yourself and most of the devs and communities around these plugins are looking into adding official support.

On a side note, I completely agree that Project Tiny and WebGPU are awesome, but if you optimize your codebase and textures/audio files, you can achieve some pretty impressive results. Not as good as straight javascript, but totally within the realm of usable to make it worthwhile to use Unity instead of PlayCanvas, Babylon, ThreeJS, etc. Unless you absolutely need to be under 2mb for your codebase, you can probably get there with Unity.

Our team shaved our latest WebGL project down to 6mb with Brotli export. And if I really wanted to be optimized I could remove all the textures from my project and shave off another 0.5-1mb of transmission size and around 20mb of VRAM (load them dynamically as .basis files using KtxUnity to save on VRAM on mobile devices).

You should always use high code stripping, and be very careful what packages you bring into Unity via the package manager. I'm betting our team will probably be able to shave off another 0.5-2mb by writing an editor script that removes unnecessary packages from the package manager when you switch to WebGL.

But even 3-5mb for an ultra optimized export is still much bigger than the competitor's engines, and to get lower than that we will need Project Tiny to save the day. Here's hoping that team gets there in 2021!

 

@jukka_j So the best thing about having KTX2/Basis support officially is that we would be able to use the Unity editor to place our images and then rely on those textures getting baked into the build as .ktx2/basis. That would avoid having to write custom scripts per project that remove all textures pre-build, load the .ktx2/basis textures from the server, and on post-build re-link everything.

GLTF/GLB support is fragmented but usable depending on the scenario. I would recommend your team reach out and offer support until they've reached parity with your competitor's official offerings if Unity doesn't plan on working on it in-house.

- @atteneder's GLTFast is the fastest, and supports Draco and KTX2/Basis via KtxUnity but doesn't support animation yet.

- @Siccity 's GLTFUtility supports Draco and animation, and I'm working on trying to add KTX2/Basis support to it via @atteneder's KtxUnity plugin. (it's not under current development by @Siccity)

- @awesomesaucelabs Piglet is the newest and well documented but is also going to be missing features for a while (animation is coming soon, and KTX2/Basis should be an easy drop-in via @atteneder's KtxUnity plugin, and I haven't personally seen how hard it is to add Draco support, but @atteneder and @Siccity got it working so it's got to be doable).

If you haven't reached out already, they're all super nice devs.

 

@DerrickBarra: I'm curious about how you remove all textures prebuild. Loading from server and applying textures in runtime is easy, but I don't get that first part. Can you write down a simple example, please?

 

@jocyf I haven't actually written out that feature yet, and a quick glance at the editor API's shows a lot of confused developers on how editing prefabs via editor scripting works.

Another way of tackling this would be to have duplicate UI prefabs for WebGL with KTX/Basis sprite loading logic added to them. That's obviously not a great solution either (duplicate prefabs for a specific platform).

But until I've actually confirmed that the Editor API's support the modifications of prefabs in the Assets folder or within scenes, I would take that solution with a grain of salt. It's not currently a high priority for our team (we don't have a ton of UI for our current project), only around 20mb VRAM savings on mobile by switching our UI to KTX/Basis.

If I do end up tackling that problem, I'll post a thread about it to show it can be done.

 

@DerrickBarra : I've been reading a little bit about it here: https://stewmcc.com/post/unity-ipreprocessbuild/

This method is a pain in the ass (even if it works) but as far as Unity doesn't provide in-editor support importing KTX it's the only solution as fas as I can see.

If Unity can provide this kind of support via PackageManager, for example, it could be a great entry door for an external developer to provide that functionality (I suppose Unity will never open that kind of in-depth importing features).

 

@DerrickBarra: When using KTX textures in WebGL, loading them at runtime (from url or SteamingAssets) the resulting Texture2D will be a regular Texture2D depending on the texture size. ¿Am I wrong?

GPU can be feeded with some compressed formats depending on the platform (ETC2, DXT, etc...). Is that the case in WebGL when using KTX/Basis format? Could the GPU be feeded directly with that compresssed format?

 

@jocyf

I think you can do this by loading the compressed texture format data with Texture2D.LoadRawTextureData()
https://docs.unity3d.com/ja/current/ScriptReference/Texture2D.LoadRawTextureData.html

 

@gtk2k : Yeah, Thanks. Unity doesn't have included the KTX format in Texture 2D ( https://docs.unity3d.com/es/2018.4/ScriptReference/TextureFormat.html ) so, it won't work.
But that's the idea, to be able to do that so you can benefit of this super compressed format when the texture lives in memory (the same that happens when using ETC or PRVC formats in mobile)

 

@jocyf I haven't tested trying to load a .ktx2 or .basis texture via the LoadRawTextureData. Our team is most likely going to end up removing all textures from our Editor and storing the .basis versions on our Amazon S3 bucket, and then just loading them at runtime. Editing the prefabs directly on Pre-Build probably won't work, but I'd love to be proven wrong.

The thing that will suck is not being able to see our UI in the editor for modifying our UI prefabs, but maybe we'll find a way around this?

 

@DerrickBarra : I'm doing the same thing. I move all important/big textures to a remote site and download & assign them in runtime. In our case, we are doing photogrametry stuff and textures are quite big, so reduce download size is a must.
The downside is maintaning those textures in memory. Is a pitty not be able to load those textures using a strong compressed format (like in mobile platforms).

I suppose that trying LoadRawTextureData() in this case with ktx / basis format will not work because Unity will not recognize that format. Maybe Unity guys could clarify that point. The other posibility we are looking for is start using tree.js or PlayCanvas for example; it's not the same as Unity (I've spent years now developing with Unity), but in our case memory issues are killing us badly using those cutting edge phogrametry graphics.

 

Hi, i've been reading throughout the forums again looking to see if there has been any progress on WebGL. My project uses dots, and therefor uses multithreading. It is still bricked? Did anyone get it working? I can't update to 2020.2 yet due to camera bugs, so im still on 2020.1.17f1. Just wondering if anyone has tested there project on it yet.

 

> Just wondering if anyone has tested there project on it yet.

We are using Unity 2020.2.1f1 for our current game, you can check out the WebGL exported version here...
https://out-of-tune-games.itch.io/crooks-like-us

 

Hi, but does it use ScheduleParallel? Since my project relies on this, and although I could switch it to single thread withoutburst.run, it would slow it down on all other versions of the game (on other platforms). So I am particularly asking about Multi Threading, and wondering if 2020.2 has made that work with WebGL builds. (That's a nice game though, I like the style and the tutorial, the way you did it is awesome)

Also regarding project Tiny, it doesn't seem like a good solution? I'm not sure, maybe I misunderstood. It doesn't seem like you can easily convert a regular ECS project to project Tiny, and keep the same functionality. I thought it was advertised towards projects of a smaller size. It would be great for mini-game/mobile games! But it doesn't seem like it would scale to both PC and mobile markets. I always thought ECS was perfect for this kind of project scaling.

 

I have been following your discussion on WebGL since before you worked for unity, and wanted to follow up and see whether you ended up moving to Project Tiny or not? We are in the same boat as it sounds like you were at NASA and really looking for a way we can keep using unity but get better performance (in particular lower RAM/VRAM usage)

 

Whaaaa... James has been captured?! x). I still remember his fair comments on Project Tiny from half a year ago, and i must say that from my own experience, it is a very much 'work in progress' still (spent my last 2 days tinkering with it again), but who cares what i think, i didn't work for NASA! Daamn James, i see you are now suggesting people give it a try, what made you change your mind (i wonder )? JK i also hope Project Tiny gets ready for production soon, it's a gem, just still quite a bit rough around the edges, with many core features missing (don't tell anyone i said so))