[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] Texture Compression in WebGL


On Oct 23, 2011, at 12:30 AM, Kornmann, Ralf wrote:

Hi Gregg,

Thank you for this opportunity. During evaluating of different techniques to bring 3D games to the browser the missing texture compression support was one of the cons for WebGL. There are three primary reasons why we would like to see compression support:

1.       Reducing the download time for the players. We still have many customers with slower (~1 MBIt/s) connections.
2.       Reducing the bandwidth cost. This may not a problem for many sites today but if we deliver game content to Millions of people this would require quite an amount of bandwidth that is not for free.

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.

3.       Improving performances for people with lower class GFX hardware. To be honest I am not sure if we will run in memory limitations before we hit the limit of the script engine. But as the script engines improve faster than the hardware it is likely.

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.

Therefore I would like to see two features for the compressed texture support:

1.       Allow downloading data for different compression methods separately. We already can (and need) handle this well for different sound formats so there is no magic behind this. A combined storage for all formats could be fine for people who don’t care that much about bandwidth but as said we prefer to only transfer data to the client that could be used there.
2.       Allow separated transfer of the different mip levels. This way we could stream the lower resolutions first.

Aside from the compression issue, you can download different mip levels separately today.

3.       Make it somewhat generic. I think the standards don’t need to list the supported formats itself. Just a way to tell the application what is supported would be enough. This way there would no need to update the standard if a new format shows up.

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.

-----
~Chris