Official Changes in WebGL1's NPOT texture handling

Hi, we're looking into doing some major internal code cleanup, of which only the OpenGLES 2.0-based WebGL1 may notice some changing behavior. With the limited scope of these changes, we believe that this cleanup should be fine. Still, we wanted to hear with you guys before following through on this.

We have a lot of complexity for handling NPOT (non-power-of-two size) Textures, rescaling or padding them (after potentially having to decompress them) if the graphics device does not actually support NPOT Textures. As this nowadays only applies to WebGL1, we decided to try and remove this code complexity such that we no longer let all devices pay the price for WebGL1 missing this capability. This means no more upscaling your Textures behind your back before uploading. This means no more surprises due to your width and height on GPU not matching your actual Texture's width and height. And this means no more uploading two Textures (a variant that's scaled to a POT and a variant that's padded to a POT) for a single asset, even though it's extremely rare to need both of them simultaneously.

If you currently compare WebGL1 with WebGL2, you already see some arbitrary behavior: NPOT Textures without mips suddenly don't do texture mirroring or repeating, NPOT Textures with mipmap generation do have mirroring and repeating enabled but have been rescaled, while NPOT Sprites still remain (by design) pixel-perfect. We would keep it simple by just applying this one rule: "if a NPOT Texture is used on a device that does not support this, then mipmapping will be disabled (and consequently texture wrapping is limited to 'clamp')". Will you see changes? If you kept the default import settings, probably not: Textures are, by default, scaled to the nearest power of two upon import, and Sprites are, by default, imported with mip generation disabled. If you explicitly disabled texture rescaling on import, well it didn't even make a difference as we rescaled it anyway on WebGL1 (except for Sprite-related code), so just rescale on import again (no added cost, now you're just setting it to rescale explicitly). Have a look here (link) for an overview of how behavior changes. In short: Textures behave more consistently and predictably, with no more surprises such as "Textures no longer wrapping around when disabling mipmapping". The main drawback is that imported Sprites can no longer have mipmaps on WebGL1 if they are NPOT; workarounds in case of changed behavior will be described (workarounds that may also depend on what functionality could still be exposed or added before we release these changes).

We feel that the many benefits for all other devices that do support NPOT Textures (including WebGL2), as well as the benefits for WebGL1 itself (regarding consistency and avoiding unanticipated internal uploading behavior) largely outweigh the niche cases in which you'll have to do some workarounds specifically for WebGL1. Still, we want to make sure we're not underestimating the need for particular use-cases. Are NPOT Textures more common than we anticipated? Are there many cases where you really need a properly mipmapped (NPOT) Sprite? Does it often occur that you want a NPOT Texture without having it rescaled? Or are we rather overestimating all of this? Are NPOT Textures already something rare in WebGL1 projects due to the graphics devices not supporting them, and do devs already pay attention to have properly dimensioned Textures in their projects? Or is it generally acceptable to potentially have texture aliasing/resampling artifacts on these platforms? ... Let us know if you think there are concerns with this cleanup we're considering! Any concerns or worries? Reliefs? ...

 

Hopefully Safari adds support for WebGL 2 soon so that we can get a better visibility for what dropping WebGL 1 would be like.

Regarding the conversation about WebGL 2 not being supported on non-Safari devices (mobile and desktop): this is something that we have discussed in the past with Google. Both Unity and Google naturally have their own web analytics dashboards, and curiously we see two different demographics with two different % capability numbers for WebGL 2 support. In the end it has been a bit vague which one to trust more. Chrome is known to be weak with WebGL 2 on mobile Adreno 300 level of devices, but apart from that, WebGL 2 is expected to have good support.

It would be great if you have Unity based WebGL sites that you host with active users, to track what the actual WebGL 2 support % rates are on your sites, cross-referenced by user agent. In the non-Safari crowd with modern PCs and mobiles, we expect that should be well above 90%, with the occassional known insecure GL drivers in the mix dropping the % by a few points.