Hi Chris, < xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />
Please don’t get me wrong on the format side. As I already said as professional game developers we are very used to work with different hardware that supports different formats. We solve such problems with assets pipelines. Therefore we would not have problems to generate assets for different formats if necessary.
Based on my DXT experiences artists are in general not very happy with the results of runtime compression. They prefer to do it offline with more heavy calculations that provides better results. Beside of this online compression increases the startup time. Maybe not for the first time when we still need to fetch data from the network but if you play again from the cache. In the Webgame business this is a quite common case that people play games multiple times if the like them. We have optimized our file handling to a level that we can reach 100% local file cache hit rate for static data without a single request to the CDN. OK this is no magic but we have seen many websites that aren’t care in this area at all. This startup time problem might be occur with shaders, too. But this is another thing that might be considered when moving the standard to the next level.
So what we need is just a list of supported formats that we can use to load the correct asset from the CDN. If we don’t have something that match we can generate an alert in the system that we need to extend the asset pipeline and go with an uncompressed assets until it is done. That’s what I was thinking about when I called it generic. Maybe you can just forward what the driver reports as supported.
PS: this is just from a game developer view. I am pretty sure that people who are doing other kinds of web sites/application may have other requests.
Von: Chris Marrin [email@example.com]
Gesendet: Montag, 24. Oktober 2011 18:59
An: Kornmann, Ralf
Cc: Gregg Tavares (wrk); public webgl
Betreff: Re: [Public WebGL] Texture Compression in WebGL
On Oct 23, 2011, at 12:30 AM, Kornmann, Ralf wrote:
But ETC texture compression only gives you 6x. You can easily beat that with high quality using JPEG. Downloading of JPEG (and PNG and GIF) compressed images is supported today.
I understand that this is the biggest issue for some hardware. The problem I see is that I don't think there is any texture compression format supported universally.
Aside from the compression issue, you can download different mip levels separately today.
There's an issue we've discussed before, but I don't think we had the benefit of game developer input. Would it be reasonable to add a hint that would say "please use texture compression if available, and I understand this may result in somewhat lower quality or performance issues for the initial runtime compression"? Or is the actual compression of the texture too finely tuned for a runtime algorithm to do a reasonable job? Because if we were able to do that, we could use the texture compression capabilities of the hardware without the author needing to deal with the details.