Anti-aliasing procedural shaders

[SteveG]

Found something potentially interesting In the NV30 OpenGL extensions document at:

http://developer.nvidia.com/docs/IO/3260/ATT/OpenGLforNV30.pdf

Page 13, slide at the bottom right hand corner, is titled "Fragment Program Partial Derivatives". On that slide, under the header "Applications", is listed "Anti-aliasing procedural shaders".

Can anyone shed light on this? I recall someone posting a link a few weeks ago to an acedemic paper that described a new AA method using derivatives. Think this slide is referring to hardware implementation of that AA method? Is this something that must be explicitly coded for in the application, or can this AA method be applied to existing games on the NV30?

Very detailed document altogether, with the following conclusion on the last slide: "OpenGL exposes all NV30 features. Well beyond even what DirectX 9 exposes".

 

[Dave Baumann]

Very detailed document altogether, with the following conclusion on the last slide: "OpenGL exposes all NV30 features. Well beyond even what DirectX 9 exposes".

Thats usually the case with OpenGL - the vendor releases extensions that cover the entirity of the hardware which may not be exposed through DirectX. R300 goes beyond whats exposed in DX9 in some areas and likewise ATi extensions will support these.

 

[Humus]

The doc isn't very clear about DDX/DDY, does this return the derivate of the actual texture values sampled or the derivates of the texture coords?

I find the implementation of floats to be halfhearted in the NV30, only GL_NEAREST filtering, no mipmaps, only texture_rectangle (no 1d,2d,3d,cubemap), not supported through texenvs.

 

[KimB]

I find the implementation of floats to be halfhearted in the NV30, only GL_NEAREST filtering, no mipmaps, only texture_rectangle (no 1d,2d,3d,cubemap), not supported through texenvs.

Are you talking about when using floats as a texture source?

 

[KimB]

Page 13, slide at the bottom right hand corner, is titled "Fragment Program Partial Derivatives". On that slide, under the header "Applications", is listed "Anti-aliasing procedural shaders".

This is basically a means of applying texture filtering to procedural shaders. There's no good way to do thiw without the "Fragment Program Partial Derivatives." Right now, I think we can only hope that nVidia's implementation of DDX/DDY are good enough for filtering of procedural shaders...and not just, "Yeah, they kinda sorta work..."

 

[KimB]

I find the implementation of floats to be halfhearted in the NV30, only GL_NEAREST filtering, no mipmaps, only texture_rectangle (no 1d,2d,3d,cubemap), not supported through texenvs.

Btw, I checked the specs, and while they aren't supported through the normal extensions, you can do MIP maps and any sort of texture filtering you want through the pixel shader. Oh, and no texture filtering is supported for floating-point sources (Apparently they're mostly to be for temporary framebuffer storage, for multipass algorithms. They could also be used for other temporary data storage, as you can pack pretty much any type of data you want into the 32-bits per channel allowed).

In other words, it appears that the NV_float_buffer extension is purely for temporary storage of relatively high-precision data. If you want to use a floating-point texture, you're going to have to do all the filtering, MIP maps, etc. yourself.

 

[Humus]

... which sucks.

One of the big things I expected to be able to do with the new generation cards is to render to a high precision cubemap, seams I can't do this with the NV30.

Anyone knows if any of these restrictions apply on the R9700 too? OpenGL_guy?

 

[Basic]

DDX/DDY seem to differentiate any register. Probably by looking at the neighbours in a 2x2 pixel pipeline configuration.

R9700 does not support texture filtering with floating point formats (but do support it with 4x16bit ints), and no frame buffer blends either (with fp).

 

[DemoCoder]

Humus, neither R300 or NV30 support filtering on floating point textures. You write your own custom filtering algorithm directly into the fragment shader. As for why, well, for most of the floating point texture sources people will be using, traditional filtering would produce bad results.

I expect most floating point textures to either include the previous framebuffer (multipass), a shadow map, a normal map, or some other function lookup texture. For each texture format, you can write your own filtering algorithms specific to that format.

I do not expect floating point textures to replace regular old 32-bit textures. There will be few FP textures in any game engine, and most will be a function lookup or state recovery from multipass.

 

[duffer]

Derivatives are used in Renderman procedural shaders, too.

I think they're really helpful for anti-aliasing procedural textures. For example, you can fairly easily make a great anti-aliased procedural checkerboard texture by using the sample point and the du,dv to compute the exact correct color to return.