trying to understand result of dFdx(), dFdy()

[skytomorrownow]

NOTE: originally, what is labeled as “dFdy(t)” above, was mislabeled as “dFdx(t)”. Also, what is labeled as fragment sample point was previously labeled “f( s, t )”. I suppose that isn’t wrong per se, but I thought it wasn’t very clear, so I fixed it. You may have to refresh or clear cache to see the revision.

I am working on antialiasing a procedural texture. In order to do so, I am trying to understand how dFdx() and the y version work. I looked through the orange book, and the GLSL spec. Based on how I understand it currently, I have drawn in the image above. Can you let me know if I am understanding this correctly?

It is my understanding that dFdx() is not giving you a derivative ( which makes sense to me – how could the GL possibly derive that without knowing the texture function? ), but rather the distance in s ( for dFdx() ), or t ( for dFdy() ) to the next position there would be a sample in that direction, if offset by one pixel in the x, and y direction in the frame buffer.

How can you find out which direction these virtual samples are from the current fragment? Is that universal, or manufacturer dependent? Again, I may be mistaken in my understanding, but if it does work the way I am seeing it now, what happens when dFdx( t ) + t is no longer inside the primitive ( e.g. dFdx(t) + t < 0.0, or dFdx(t) + t > 1.0 )?

I may be misunderstanding how this function works. If so, I’d love to understand this, and will correct my drawing for the record.

Thanks!

[Spasi]

This should be helpful: Advanced RenderMan: Beyond the Companion, page 62 (Basic Antialiasing in Shading Language). It’s for RenderMan’s SL, but it applies equally well to GLSL.

I think GLSL’s [b]dFdx/b corresponds to the [b]Du/b*du from that paper. That is, it returns the amount that p changes between adjacent fragments (in the x/u direction).

GLSL’s [b]fwidth/b corresponds to [b]abs/b + [b]abs/b.

So, you’re correct that dFdx does not give you a derivative of your function, but you can use it to reform your function in a way that applies antialiasing.

[quote=“skytomorrownow,post:1,topic:34122”]
That depends on what you pass to the p parameter. I guess that passing the fragment location to dFdx/y would return what you describe.

[quote=“skytomorrownow,post:1,topic:34122”]
It shouldn’t matter. A positive result from one manufacturer would be a negative from another (if they do it the “other way”). You’re mostly interested in the rate of change, rather than the direction (hence the abs in fwidth)

@skytomorrownow

Again, this shouldn’t be a problem, but here’s what the GLSL spec states:

[quote]Other properties that are desirable, but not required, are:
4. Functions should be evaluated within the interior of a primitive (interpolated, not extrapolated).

I hope this helps. Ah btw, the only time I’ve used GLSL derivatives was 3 years ago in zShapes, for antialiasing the font curves. I don’t remember the details, but from a quick glance at the code it looks like I did what is described in the RenderMan paper for antialiasing a step function.

[skytomorrownow]

Spasi thank you for your responses. It’s so funny that it’s you who replied, as I am working through the Loop Blinn paper right now – which is why I am concerned with antialiasing! LOL. Small world.

Almost all of your responses cleared up my questions. I will do a bit more research and prime this thread if I have any more questions. But, I think you’ve given me the clues I need.

I have read the Advanced Renderman section you mention, but will reread again.