Hacker News Reader

Comment by palish | Hacker News Reader

Hardware compatibility is the least of WebGL's problems. Right now there's essentially zero chance of WebGL powering any modern graphics engine. It unfortunately seems doomed to a life of "hey-look-at-my-cool-effect". (Which is neat, don't get me wrong. But it will never reach Doom 3 quality, and that's a tragedy IMO.)

Example: WebGL doesn't even support compressed textures. The spec actually mandates "We will not support compressed textures, and this is by design". Facepalm...

View on HN

Well my stuff isn't Doom3 level so I guess it's useless but I'm building visualization tools for the brain imaging community with WebGL and for that it works great. I have no fear that WebGL will do fine, it's an evolution of the Web the same as was seen on the phones. Looks at 2006, did anyone seriously think phones would be able to do much? Then a few years later Carmack shows some cool demo engine for iOS Rage which looks about as good as the PS3.

As for compressed textures. It hasn't been ruled out for ever. This is stil version 1.0 of the spec.

I was of course talking specifically about WebGL for games...

But it seems like you'd run into many of the same hindrances. For example, how will you get around the 5MB local storage limit? It would be unwieldly to re-download the whole visualization dataset each time, no?

P.S. I have nothing but respect for the medical visualization community. A lot of game graphics techniques were derived directly from work done in medical research (for example, BSP rendering and voxel rendering).

I offer multiple options, 1. they can open local files, option two is obviously to get them from the server every time. For most things they don't usually look at the same stuff multiple times. An average MRI is pretty low resolution and can fit in under 50mb (average 10mb, 50-60 for fMRI scans) of storage thus it's not to expensive to redownload it. For surface data it's even less, my average brain surface is also under 10mb. Most of my users are on University networks which helps a lot.

Also applications in the chrome web store can get around the local storage limitation. I'd browsers to offer a quota system where the user can assign a max amount to their applications. That would solve those issues.

Compressed textures are an intellectual property minefield. Blame the patent system, again...

However, the lack of compressed textures, or any other specific feature isn't WebGL's biggest problem. It really is hardware compatibility. WebGL is the first web technology to expose significant hardware variations (with bonus buggy drivers!) directly to web content, and web developers aren't equipped to handle that. Deploying a WebGL app with any hope of wide compatibility will require testing on at least 3 and more likely 10+ different hardware/driver/os configurations, and the fact that a GPU is required makes automated testing difficult (VMs don't work, remote desktop solutions often don't work, driver crashes hang machines).

The least of WebGL's problems? Failing to run at all with no fallback isn't a big problem? :P

Why is texture compression so badly necessary? Aren't downloaded PNG or JPEG files that you upload to the GPU uncompressed "good enough"? I don't think anyone's asking for COD5 to be in WebGL.

Texture compression isn't just for smaller downloads. In fact JPEG is fine for reducing download sizes. However, when the JPEG is converted to a texture it is completely decompressed. Texture compression formats aren't as good at compression as JPEG, but they are specially designed so that they never need to be decompressed; they remain compressed in graphics memory and the GPU decodes them on the fly as they are sampled. Not only does this save graphics memory, it also saves memory bandwidth, which actually makes rendering faster.

Given this, it makes sense to store your textures as JPEG and convert them to compressed textures at load time. That way you get the excellent compression ratio of JPEG for the download and the speed boost of compressed textures for rendering. For example, id Tech 5 (RAGE) does this for their megatextures (except they use JPEG XR instead of JPEG).

S3TC(DTX) and PVRTC have patent problems. The Khronos group is working on designing and popularizing new formats that aren't patent encumbered. So, far they best we've got is ETC -which doesn't support alpha channels and is not yet supported by PC hardware...

Reply on news.ycombinator.com