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

Re: [Public WebGL] Volume Textures




On Mar 24, 2011, at 8:24 PM, John Davis wrote:

> Universally implementable?  This sounds like any shader I write should run on any implementation.  We all know this is not the case.  It is up to the developer to detect the limitations of the shader model on the device.  Which means writing a shader that runs on ps 3.0 and a lighter one that runs on ps 2.0, telling the user it won't run, etc., when we're talking about desktops.  With mobile devices the same applies, instruction count limitations vary.

It's true that you can write a shader of sufficient complexity that it will fail to run on some hardware. But one of the goals of WebGL was to try to minimize these incompatibilities. Read on...

> 
> How is this any different from detecting an extension at runtime, and using it if available?

There is no concept of "extension detection" in WebGL like there is in OpenGL. Before you can use an extension you have to enable it. It it doesn't exist enabling it will fail. Trying to use an extension that does exist without first enabling it will fail.

> 
> I don't believe the "Universally implementable" argument is valid.  Otherwise, WebGL would only accept the most minimal vertex/fragment shaders.which would run on everything.

That's exactly how WebGL is defined. Try using "while", or using a standard derivative function without turning on OES_standard_derivatives. If you're on a compliant WebGL implementation it will fail.

> 
> If we add the extension now, and later it gets added to the OES2.0 spec, we simply have "Webgl2" for instantiating the context which has volume textures added to the API and the extension removed.
> 
> WebGL is amazing, and I truly believe it is going to change the shape of everything internet.  We just need one last tweak for a very simple/clear/elegant well understood concept which has been around for quite a while.

That was tongue in cheek, right? You think volume textures is "the" one-last-thing that is needed to push WebGL over the edge? I can point you to the list of OpenGL ES extensions that we don't yet support, and I think I could argue that any of around half of them would be as good or better a candidate, depending on your application.

-----
~Chris
cmarrin@apple.com




-----------------------------------------------------------
You are currently subscribed to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email:
unsubscribe public_webgl
-----------------------------------------------------------