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

[Public WebGL] On the lack of ddx/ddy.



I had an idea today for adding support for something very similar to the
ddx/ddy shader functions on systems that don't support them natively.

It's exceedingly hackish - and I hesitate to suggest it - but it will be
incredibly useful for one particular effect in my application.  So I
thought I'd share it.

If you make a 256x1 1D monochrome texture map (myMagicTexture) that has
each MIPmap level painted in a brightness that is
pow(2.0,MIPlevel)/256.0 - then you can deduce what ddx or ddy are by
judiciously looking up that texture with the parameter that you were
planning to pass to ddx or ddy.  The MIP level that the hardware
calculates is (theoretically) log-to-base-2 of the worst case
minification direction of the map...so we should be able to do something
like:

      sampler1D myMagicTexture;
      float ddxy(float thing){return
texture1D(myMagicTexture,thing).g*256.0;}

CAVEATS:

* I'm still trying to figure out a way to distinguish between ddx and
ddy (this function returns something like max(ddx(thing),ddy(thing)).
* It''ll only work over the range of values set by the number of MIP
levels in 'myMagicTexture'.
* If you wanted to pass a vec4 to it, it would have to do four texture
lookups(!)
* On systems that can't support 8 bit monochrome maps, we'd need to do
something a bit more complicated...maybe doing the pow(2,...) in the
shader instead of offline.

Now - we also don't have texture2DLod in the fragment shader - but we do
have a version of texture2D that has a LOD bias parameter...without this
trick, that doesn't help us much - but now that we can use
myMagicTexture to figure out the LOD that the texture2D function would
have used without the bias parameter - so we can calculate the amount of
bias we need to get the LOD we actually want!

That is hackish-squared...but maybe it'll work.

  -- Steve

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