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

RE: [Public WebGL] Shader validator issue.



Great news! Thanks for the info! Now I can continue scheming on some interesting demos that use it :)

--
Ben Vanik
Live Labs / Seadragon
________________________________________
From: Kenneth Russell [kbr@google.com]
Sent: Monday, August 23, 2010 1:41 PM
To: Ben Vanik
Cc: steve@sjbaker.org; Gregg Tavares (wrk); Vladimir Vukicevic; public webgl
Subject: Re: [Public WebGL] Shader validator issue.

Support for OES_standard_derivatives is in the process of being added
to the ANGLE shader validator. See
http://code.google.com/p/angleproject/issues/detail?id=25 . Once this
is in place, it will be possible to enable OES_standard_derivatives in
a WebGL app. (We need to start a WebGL extension registry...part of
this is still on my plate.)

-Ken

On Fri, Aug 20, 2010 at 2:23 PM, Ben Vanik <Ben.Vanik@microsoft.com> wrote:
> yeah I really wish that OES_standard_derivatives (http://www.khronos.org/registry/gles/extensions/OES/OES_standard_derivatives.txt) was part of the WebGL base spec.
>
> iPhone has it and I haven't seen a desktop GPU that doesn't. *very* handy for virtual texturing/other advanced tricks.
>
> --
> Ben Vanik
> Live Labs / Seadragon
> ________________________________________
> From: owner-public_webgl@khronos.org [owner-public_webgl@khronos.org] on behalf of steve@sjbaker.org [steve@sjbaker.org]
> Sent: Friday, August 20, 2010 2:15 PM
> To: Gregg Tavares (wrk)
> Cc: steve@sjbaker.org; Vladimir Vukicevic; public webgl
> Subject: Re: [Public WebGL] Shader validator issue.
>
>> On Fri, Aug 20, 2010 at 11:44 AM, <steve@sjbaker.org> wrote:
>>
>>> Oooohhhh...ikky!
>>>
>>> So I can't control the LOD of a texture lookup in the frag
>>> shader?...Urgh!
>>>  That's a pain in the butt!  There is a significant class of shader
>>> algorithms related to image atlassing that kinda rely on that function.
>>
>> texture2D takes an optional bias parameter which you might be able to use
>> depending on what you are trying to do.
>
> Maybe.  This is one of those situations where I'm packing a bunch of
> little textures into an atlas - but those sub-textures need to wrap so
> they can repeat across a polygon.  So I take the texture coordinates
> modulo some number so they repeat over (say) 0 to 0.25 instead of 0 to 1.
> The problem with doing that is that when the texture coordinate jumps from
> 0.249 to 0.001, the texture hardware assumes that the texture has been
> massively minified and drops you down to virtually the lowest LOD of the
> map.  That causes bits of the other sub-maps to be blended into the one
> you're rendering and you get a horrible flickery seam around the edges of
> your sub-maps.
>
> However, if you have texture2DLod, you can figure out how fast you would
> have been stepping across the map had you not done the modulo thing - and
> force the system to pick the MIPmap LOD you actually wanted...and the
> flickery seam magically 'goes away' (well, assuming you are careful to
> generate your MIPmaps with a box filter and keep the sub-maps to
> power-of-two boundaries, etc).
>
> It's a bit of a hack - but for most things, it works beautifully....except
> when it's not supported.
>
> Of course, now that I actually RTFM instead of stupidly assuming that
> GLSL/ES==GLSL I realize that the all-important ddx() and ddy() functions
> have also gone AWOL...so the other way to do this (which is to filter the
> texture yourself) won't work either.  Argh!
>
>  :-(
>
> Still - we have to make do with what we've got...so I'll have to figure
> out something else to do.  I don't immediately see how the bias thing is
> going to help...but at least it has possibilities.
>
> Anyway - this is straying off-topic.
>
>
> -----------------------------------------------------------
> 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:
>
>
>
> -----------------------------------------------------------
> 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:
>
>


-----------------------------------------------------------
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: