08-28-2013 11:19 PM - edited 08-28-2013 11:37 PM
Has anyone had success using compressed textures in WebGL?
I know about the different GPU's, encoding schemes and container formats. But it seems as if texture compression is not exposed in WebGL.
This article claims ETC1 is supported, but I cannot find any documentation on using ETC1 on WebGL in BB10 (or in WebGL at all, for that matter). Which extension should be loaded? Which internal format should be used?
I don't want to go down the PVRTC / ATC hardware-specific route. I don't need an alpha channel. Besides, those aren't documented either.
Some experimentation shows that it does seem to support S3TC: it loads the extension (ext=gl.getExtension("WEBKIT_WEBGL_compressed_textu
Some pointers or code snippets would be very welcome!
Solved! Go to Solution.
08-29-2013 02:18 PM
Hi there, I'll admit that the full implementation is a little beyond me, but here is the feedback that our engineering teams had.
On Qualcomm we support ATC compression, on SGX we do not; it's based on the underlying GL driver.
We may support some S3TC, but it's not in getSupportedExtensions because we don't support all of it (for example, on-the-fly DXT3 and DXT5 compression is unsupported.) In general, it's best to assume DXT is not supported.
It seems that there may be some conflicting / misleading evidence being reported by the extension that's loaded. It may actually be worth logging a JIRA here (and email me once you do; firstname.lastname@example.org):
That will take it directly to our development teams who can help address the confusion at the API level. I don't expect additional support to be added in the short-term, but it never hurts to show that there is interest in these APIs.
08-29-2013 03:24 PM - edited 08-29-2013 03:28 PM
Thanks for your reply, Eric, but I'm not sure that clarifies a whole lot...
I'm trying to find a feasible way to do any texture compression. If possible a method that will work on all the current devices (and Chrome on Windows, for debugging), but if we have to go down chipset-specific routes and/or use a fallback for Chrome, then so be it.
OK, so we've established that S3TC is off limits, and that Dev Alpha C should support ATC.
So far I've only been able to get compressed textures working on Chrome with S3TC. None of the compression schemes seem to work on STL100-1 or Dev Alpha C (or we don't have enough info to implement them).
It is my understanding that one first loads the appropriate extension using gl.getExtension(), passing an extension name that determines the compression "family" (ETC1, PVRTC, ATC etc). Then one loads and parses a container file (e.g. .dds, .ktx), extracts the textures and calls gl.compressedTexImage2D() passing an appropriate internalFormat parameter depening on the fourCC found in the container file.
The specific questions I have:
I'll post a JIRA issue about the misreported S3TC support.
PS: it would be a good idea to standardize terminology. In the current info, scattered around the BB blogs and docs sites, Imagination, PowerVR, SGX, Qualcomm, Adreno, VZW, Chipset A/B, Z10, Q10 are being used interchangably, yet nowhere is it documented which device models have which chipsets. Just drop the brand names and talk about device models (STL100-1/2/3/4 etc). That's what devs and power-users use.
08-30-2013 07:30 AM - edited 08-30-2013 07:34 AM
OK, I've found out a little more info...
Diving into the Khronos WebGL spec this should work: http://jsfiddle.net/jonno/KGEEQ/. The snippet simply tries to load 3 WebGL extensions (for PVRTC, ATC and S3TC). Tested on:
Both report the same:
I also found some Khronos WebGL comformance tests:
According to this page:https://developer.blackberry.com/native/documentat
Of course the name strings are different for plain-C OpenGL and WebGL. I've tried various permutations, without success...
08-30-2013 09:37 AM - edited 08-30-2013 09:38 AM
Hi there, I've forwarded this (along with your previous questions) along to our engineering team who are compiling the information that you're after. Unfortunately I haven't gone very deep into the texture compression avenue myself. I'll do my best to get an answer for this ASAP.
(And if it's taking too long, feel free to poke me at email@example.com) :-)
08-30-2013 04:08 PM
Should have an update for you soon. Just verifying a few pieces with the gurus and will follow-up on here once confirmed.
09-03-2013 11:04 AM - edited 09-03-2013 11:05 AM
EDIT: Note that Group 1 and Group2 are not standard ways to refer to these devices, I'm just using them in this post to simplify how I refer to the specific devices.
Apologies for the novel here. Do let me know if you have any further questions.
In terms of device model values...
STL100-1 (aka Group 1) would refer to:
Texas Instruments OMAP 4470 1.5Ghz / Imagination GPU PowerVR SGX 544
The remaining models (STL100-2, STL100-3, STL100-4; aka Group 2) all refer to:
Qualcomm Snapdragon MSM8960 1.5Ghz / Qualcomm GPU Adreno 225
The SQN and SQR models are also Qualcomm based and should follow the same behaviour as Group 2.
Our development team has been doing some digging and have found the following. Group 1 (i.e. STL100-1) supports:
Whereas Group 2 (the remainder) support:
What we’ve discovered is that while the underlying implementation supports these, they haven’t actually been exposed except for one (1) within Group 2, which is:
Furthermore, this specific format is not a cross-platform format and is specific to STL100-3.
What our development team has done today is updated the implementation to exposed the following:
This does not include PVRTC2 as it is not exposed at all by WebGL in WebKit and we want to stay in sync with the upstream enumerations as much as possible.
So, to your question about which compression method can be used across all devices; the answer would be ETC1 as soon as the next update is released where these have been exposed.
As for your other questions...
which extension names should be used in gl.getExtension() for each compression "family"?
This tells you which extensions are supported and the names given are what you put into gl.getExtensions()
once the extension is loaded, what are the ID's to pass in the inernalFormat parameter of gl.compressedTexImage2D()? which texture compression is available on STL100-1?
You would do something like:
var ext = gl.getExtensions(WEBGL_compressed_texture_etc1);
Then the internalFormat would be ext.COMPRESSED_RGB_ETC1_WEBGL for gl.compressedTexImage2D(...)
We are currently in the process of adding this extension. Presently only ATC is supported on certain devices.
what about the defacto-standard ETC1? That woud suite my needs just fine. Is it supported in WebGL?
We are working on getting ETC1 support in WebGL.
how should a WebWorks app find out which chipset it is running on (i.e. which compression to use)?
Unfortunately there is no API available to do this sort of low-level query. There may be something on the native side which I will look into but I don't think there will be anything for this. Generally you can use one common compression (in this case ETC1) method and submit one BAR for all graphics chip variations. Or you can build two separate BAR files and associate them with the appropriate graphics chip variations in App World, and rely on App World to deliver the correct build to a particular device.
09-03-2013 08:18 PM - edited 09-03-2013 08:19 PM
Thanks for the follow up and your excellent explanation. I somehow had the feeling there was a difference between the native implementation and the exposure in WebGL. Too bad we can't use compression just yet (unless you have an STL100-3, which I don't). But it's comforting to know I wasn't barking up the wrong tree and have helped fix some bugs.
So the support matrix for texture compression in WebGL is:
ETC1 compression will be very useful in my current project. Though I don't need it right now, please consider exposing ATC to STL100-2, STL100-4, SQN and SQR, so there is a format with alpha support on all models.
Also, proper S3TC support would be desirable so the same code & assets can be used while developing on Chrome/Ripple and at runtime in BB10.
Good support for texture compression is not only to reduce the .bar file size, it should also allow faster loading of textures into memory, from memory into the GPU and more/larger textures in GPU simultaneously. Separate .bar files per device model aren't always a good idea. A reliable way of querying TC support or device model at runtime is needed.
I'll have another Q for you soon, as it appears textures in WebGL are limited to 2048x2048px, not 4096 as the specs state. But I'll start another thread for that.
09-05-2013 09:29 AM