Anisotropic Filtering

We know that anisotropic filtering isn’t in core OpenGL for a reason: IP issues. We also know that this is slightly ridiculous as hardware support is ubiquitous. So how can we get anisotropic filtering into core? Simple.

Relax the specification so that GL_MAX_TEXTURE_MAX_ANISOTROPY is allowed to be 1.

From specification, setting GL_TEXTURE_MAX_ANISOTROPY to 1 disables anisotropic filtering; I quote:

When the texture’s value of TEXTURE_MAX_ANISOTROPY_EXT is equal to 1.0, the GL uses an isotropic texture filtering approach…

So with GL_MAX_TEXTURE_MAX_ANISOTROPY allowed to be 1, the only legal value of GL_TEXTURE_MAX_ANISOTROPY which may be set is that which disables anisotropic filtering, and IP requirements are satisfied.

It’s ugly and hacky, yes, but there is precedent: GL_ARB_occlusion_query allows GL_QUERY_COUNTER_BITS_ARB to be 0 so that implementations which don’t actually support occlusion queries can implement it; see OpenGL ARB Meeting Notes - June 10-11, 2003 (look for “ARB_occlusion_query”). This proposal is just for doing the same but with anisotropic filtering.

Is it right to be proposing something ugly and hacky? Probably not, but it seems to me that the benefit of finally getting anisotropic filtering in core would outweigh the negative.

[QUOTE=mhagain;1259715]
It’s ugly and hacky, yes, but there is precedent: GL_ARB_occlusion_query allows GL_QUERY_COUNTER_BITS_ARB to be 0 so that implementations which don’t actually support occlusion queries can implement it; see OpenGL ARB Meeting Notes - June 10-11, 2003 (look for “ARB_occlusion_query”). This proposal is just for doing the same but with anisotropic filtering.

Is it right to be proposing something ugly and hacky? Probably not, but it seems to me that the benefit of finally getting anisotropic filtering in core would outweigh the negative.[/QUOTE]

I see absolutely nothing “ugly” or “hacky” here. It would be clean and nice. Can you formulate at least one objective problem with this suggestion? Is it unintuitive or complicated to use? No. Does it twist or add bloat to opengl in any way? no. Does it do it’s intended job? fully. I can’t understand what definition of “ugly” or “hacky” are you using here?

Such kinds of workarounds are very common way to deal with patent garbage in this industry. Now that you drew attention to it, i am puzzled why they haven’t done it yet for so long.

By the way note that the s3 texture compression case was similar - they added the infrastructure in the specification (glCompressedTexImage2D) but didn’t require support for the s3 formats.
Well, the infrastructure allowed other formats besides s3, but at the time there were no other formats. (It was only recently that they added the RGTC formats.)
So without actual s3 support it was useless by itself. The same would be with the anisotropy state.