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

RE: [Public WebGL] Shader validator issue.



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: