Not looking great. Seems like still no WebGL 2 support at all in the next version of Edge (Fall Creators Update). In addition while the next version of Safari (11/Technical Preview) supports it behind a flag, will continue to have it disabled by default. This is rather unfortunate because now we have to wait until ~mid 2018 at the earliest for all the (desktop) browsers to support WebGL 2 in practice/in the wild. I’m clearly just venting here but can Unity do some poking for information? WebGL 1 (ogl es 2.0) can be quite restrictive and it’s a little annoying there’s no technical reason (on desktop) that we have to be held hostage by it.
We have no more information to share compared to what you already listed.
We do share our insights and wishes in meetings with them but can’t magically make things get developed faster. Sad but true 
And WebGL 2.0 game developers are but one target audience for browser makers to consider in their roadmap.
However Chrome and FF do support it rather well and while they have quite the market share haveing a common set of features available in all browsers is clearly the more desired option.
At the moment it can be enabled via the experimental features in Safari, anyone have an idea of when it will go into a release version?
Also can the browser be made to fallback to webGL 1.0 when your settings are like this?
I’d like linear/ webGL2.0 to be the default in Chrome and Firefox, but to fallback to webGL1.0 if a user is loading in in Edge/ Safari
That wouldn’t quite work and more importantly you’d have to author all you content twice, once in linear color space and once in gamma color space for WebGL 1.0 which is probably more effort than it is worth.
1 Like
If you want to fallback to WebGL1.0, you must use Gamma. WebGL2 is a requirement for Linear color space.
1 Like
So you can’t use linear and 2.0 in supported browsers and have the content automatically fall back to 1.0 in safari or edge, shame 
We currently fallback to 1.0 on browsers that don’t support 2.0, but we did have to switch back to gamma to do that.
Oddly enough, except for some blurry textures due to no NPOT texture support on edge/safari, it works relatively well, even with some of our more complex streaming clips. However, very much looking forward to switching off 1.0 support permanently so we can move future content to linear color space.
‘‘We currently fallback to 1.0 on browsers that don’t support 2.0, but we did have to switch back to gamma to do that’’
Do you do that dynamically ‘in-game’ somehow?
Is Linear/Gamma the only limitation of using 1.0?
What other pitfalls should we be looking for?
No deferred rendering path, terrible shadows, no instancing support.
1 Like
Somewhat related, WebGL 2 now reports as shader level 35, not 40 FYI.
I would be very curious to know, how do you detect at run-time that it’s using WebGL 1.0 and not 2.0?
The information is lackluster on that front. Some people say “use user-agent” javascript api or similar. I think this is incredibly cumbersome for something that should be simple.
So that’s the way to go? if shader level is below 35 on WebGL player then it means it is WebGL 1.0?
Thanks!
1 Like
Hard to remember exactly but these are the comments I left on our FXAA script for Safari and pre-WebGL 2.0 Chrome/Firefox (no MSAA on WebGL 1.0 under masOS, thus we fallback to FXAA):
if (SystemInfo.graphicsShaderLevel <= 30) //webgl 1 = 30, webgl 2 = 35
Still, I don’t think it would be terribly difficult to check through javascript (might be a more robust solution since Unity has changed this once already…).
1 Like
If you have “Auto Graphics API” checked on won’t it build both versions and auto load them at runtime?
That’s not my experience.
There are 3 possible end results:
- WebGL will fail with an alert error.
- You will get the alert error but WebGL will load anyway
- WebGL will fail without an alert error
It will be consistent with your build, but no doubt each is a result of the project failing to workout the incompatibilities (this is on top of WebGL just failing because… it ran out of memory or whatever).
The only way to force Safari to drop to WebGL 1.0 seems to be to build a 1.0 version and divert it with the browser.
1 Like
Yes, but note various graphical features only work on WebGL 2 (so obviously be careful what you use if you plan to support Safari). When you enable “Auto Graphics API”, Unity will print a harmless error when it falls back to WebGL 1 but it will still function normally. You don’t need to generate a separate build.
2 Likes
Excellent. Good to know. Nothing I’d be doing would be using anything beyond very basic.
I did discover that Babylon.js has a Unity exporter. I’m going to start experimenting with it as it appears to be quite a bit faster than the current WebGL exports. However I’m unsure if this supports exporting Unity UI elements…but I do believe that could be handled natively.
1 Like
Interesting. We used Babylonjs till we tried Unity with wasm. Same assets was unbelievable faster using Unity engine.
2 Likes