TEXTURE MIN FILTER default as NEAREST MIPMAP LINEAR - why? - Graphics and GPU Programming

130

Author

April 24, 2008 09:12 AM

I was debugging my app and was surprised to find all the textures I created had GL_TEXTURE MIN FILTER defaulting to GL_NEAREST MIPMAP LINEAR rather than GL_NEAREST or GL_LINEAR as I had expected. I checked the spec and this is the defined behaviour..... but why? I was having problems with textures not appearing and, as I found out, this was due to me not having specified all the mip levels as changing GL_TEXTURE MIN FILTER to GL_LINEAR fixed things. Has anyone any insight into why the spec decided to be how it is when it forces mipmapping to be used as default which involves extra complexity? Not a problem as such but it has me wondering.....

ndhb

247

April 24, 2008 10:36 AM

You're not the only one and will probably not be the last one :)

It is one of those common OpenGL texture pitfalls that many beginners wastes time on. I've never seen an explanation why the default filtering is not the one least likely to cause problems (i.e. GL_NEAREST). Although mipmapping is a good thing for both performance and image quality I don't think it should be default - especially not when automatic mipmap generation from the base level defaults to false.

V-man

813

April 24, 2008 11:28 AM

Because then people would complain why mipmapping is not working and we'd have to explain to them that the default is GL_NEAREST or GL_LINEAR.

Newcomers need to just read the documentation.

Also, why rely on default state when you don't have to.

Sig: http://glhlib.sourceforge.net
an open source GLU replacement library. Much more modern than GLU.
float matrix[16], inverse_matrix[16];
glhLoadIdentityf2(matrix);
glhTranslatef2(matrix, 0.0, 0.0, 5.0);
glhRotateAboutXf2(matrix, angleInRadians);
glhScalef2(matrix, 1.0, 1.0, -1.0);
glhQuickInvertMatrixf2(matrix, inverse_matrix);
glUniformMatrix4fv(uniformLocation1, 1, FALSE, matrix);
glUniformMatrix4fv(uniformLocation2, 1, FALSE, inverse_matrix);

coordz

130

Author

April 25, 2008 11:19 AM

Quote:Original post by V-manAlso, why rely on default state when you don't have to.

Because initializing *everything* is tedious. I wouldn't want to set all the hundreds of OGL state variables... would you? ;)

V-man

813

April 25, 2008 12:23 PM

Well, the numbers of states is much less than 100. I don't know the exact number but it is around 30.
I can understand if you are new and don't know which state would be causing problems. It even happens to experienced people, that's why we develop wrapper classes.

Sig: http://glhlib.sourceforge.net
an open source GLU replacement library. Much more modern than GLU.
float matrix[16], inverse_matrix[16];
glhLoadIdentityf2(matrix);
glhTranslatef2(matrix, 0.0, 0.0, 5.0);
glhRotateAboutXf2(matrix, angleInRadians);
glhScalef2(matrix, 1.0, 1.0, -1.0);
glhQuickInvertMatrixf2(matrix, inverse_matrix);
glUniformMatrix4fv(uniformLocation1, 1, FALSE, matrix);
glUniformMatrix4fv(uniformLocation2, 1, FALSE, inverse_matrix);

Brother Bob

10,350

April 25, 2008 01:45 PM

Quote:Original post by V-man
Well, the numbers of states is much less than 100. I don't know the exact number but it is around 30.
I can understand if you are new and don't know which state would be causing problems. It even happens to experienced people, that's why we develop wrapper classes.

If you believe the number of states are around 30, then I strongly suggest you download the latest API specification and check out the state table at the end. Starting at page 269 (in the 2.1 specification), you have 35 pages of tables with states, their initial values and how to query them, and which it sounds like you suggest we set manually. And those pages lists only what's in the core. There are more states in extensions that are not listed in those tables.

edit: That list contains implementation limits also. They aren't states, but excluding them you are still left with a lot.

Yann L

1,806

April 25, 2008 02:49 PM

Quote:Original post by V-man
Also, why rely on default state when you don't have to.

Why not ? Default state is well documented in the official specs, and there's no reason to not rely on it.

Now, the defaults for texture filtering are somewhat weird, but this is not a reason to manually duplicate initialization for everything.

V-man

813

April 25, 2008 05:05 PM

Quote:Original post by Yann L
Now, the defaults for texture filtering are somewhat weird, but this is not a reason to manually duplicate initialization for everything.

Why not? It is better to have a wrapper class that deal with texture and it can setup explicitly all the texture states.

wrap, min filtre, mag filter, mipmap generation, anisotropy, base level, border color

Anything else?

Sig: http://glhlib.sourceforge.net
an open source GLU replacement library. Much more modern than GLU.
float matrix[16], inverse_matrix[16];
glhLoadIdentityf2(matrix);
glhTranslatef2(matrix, 0.0, 0.0, 5.0);
glhRotateAboutXf2(matrix, angleInRadians);
glhScalef2(matrix, 1.0, 1.0, -1.0);
glhQuickInvertMatrixf2(matrix, inverse_matrix);
glUniformMatrix4fv(uniformLocation1, 1, FALSE, matrix);
glUniformMatrix4fv(uniformLocation2, 1, FALSE, inverse_matrix);

coordz

130

Author

April 29, 2008 08:01 AM

I quite like it that wrapper classes have come up because that is what I'm currently implementing :) Now I can have GL_NEAREST as default all the time :-D

TEXTURE MIN FILTER default as NEAREST MIPMAP LINEAR - why?

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

TEXTURE MIN FILTER default as NEAREST MIPMAP LINEAR - why?

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Reticulating splines