Part of the Khronos Group
OpenGL.org

The Industry's Foundation for High Performance Graphics

from games to virtual reality, mobile phones to supercomputers

Results 1 to 3 of 3

Thread: Anisotropic Filtering

  1. #1
    Senior Member OpenGL Pro
    Join Date
    Jan 2007
    Posts
    1,182

    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 http://www.opengl.org/archives/about...003-06-10.html (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.

  2. #2
    Member Regular Contributor
    Join Date
    Apr 2004
    Posts
    250
    Quote Originally Posted by mhagain View Post
    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 http://www.opengl.org/archives/about...003-06-10.html (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.
    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.
    Last edited by l_belev; 05-30-2014 at 07:05 AM.

  3. #3
    Member Regular Contributor
    Join Date
    Apr 2004
    Posts
    250
    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •