Re: [css-shaders] GLSL implementation defined limits

Reordering your message a little...

On 12/11/2011, at 6:11 AM, Gregg Tavares (wrk) wrote:

> I also want to add that I think CSS shaders in particular are going to end up getting extremely complicated.
> 
> As an example I certainly never would have made a folding map using a shader like the one Adobe showed. I would have (a) cut the paper into 1 plane per fold and set texcoords appropriately OR (b) used a skinned model and hierarchical animation OR (c) used morph targets across 2 meshes. It's neat that it can be done in a shader but that's just my point, given the limitations people will need to put more in shaders then they generally have in the past.

You first say that shaders are going to get extremely complicated, then propose more extremely complicated alternatives :)

I greatly prefer complexity in a shader over rewriting my document, or using WebGL (which you'd need for the skinned model and morph targets, and would require lots of JS). A shader is clearly isolated to the element it is working on. I don't think the world will explode if certain advanced shaders do not work on particular hardware. That's typically the way features appear on the Web - it's rarely an on/off switch. Over time, the switch is nearly completely on.

I also think the folding map is a pretty advanced example. I expect the majority of uses for shaders will be a lot more subtle, and be much less complex GLSL.

> Given that the author can't supply an arbitrary mesh nor can they supply arbitrary textures it seems likely they'll end up doing crazy complicated things in the shaders to work around those limitations.

Arbitrary textures can be passed in. See the texture() parameter in https://dvcs.w3.org/hg/FXTF/raw-file/tip/custom/index.html#feCustomParamsAttribute

Dean

Received on Saturday, 12 November 2011 00:29:26 UTC