just noticed in my code that ive used both, dont ask me why cause its stopid of me but anyways.
now im guessing GL_NEAREST_MIPMAP_LINEAR is better
ive had a search on the internet for bilinear filtering and basically
some ppl say its GL_NEAREST_MIPMAP_LINEAR + others say GL_LINEAR_MIPMAP_NEAREST, so whos right?
which one should i use?
cheers zed
I might have it backwards, but I believe GL_LINEAR_MIPMAP_NEAREST means linear filtering on the selected mip level but only the nearest mip level is selected, and GL_NEAREST_MIPMAP_LINEAR means no filtering on the texture image but linear filtering between the two nearest mip levels. GL_LINEAR_MIPMAP_LINEAR gives you linear filtering on the two nearest mipmaps, and then does a linear blend between those two mipmaps (avoids popping or lines between mipmap levels, this is trilinear filtering).
GL_LINEAR_MIPMAP_NEAREST = Bilinear.
thanks guys, so i was wrong
GL_NEAREST_MIPMAP_LINEAR should give the better quality right, time for find_and_replace in multiple files
quick update incase someone follows my footsteps
GL_NEAREST_MIPMAP_LINEAR
looks a lot better than
GL_LINEAR_MIPMAP_NEAREST
they work as alexN described
i assume GL_LINEAR_MIPMAP_NEAREST is cheapest to do
performance wise ild expect GL_NEAREST_MIPMAP_LINEAR + GL_LINEAR_MIPMAP_LINEAR to be roughly equal (linear_linear slightly slower perhaps)
also so i can stick this in my ingame menu
GL_LINEAR_MIPMAP_NEAREST = billinear
GL_NEAREST_MIPMAP_LINEAR = ?
GL_LINEAR_MIPMAP_LINEAR = trilinear
perhaps ill just do bad,…,good (medium/moderate/ok/average/reasonable none of these terms really decribe halfway between bad + good, english has more words than any other language yet it has no term for this, a failing of the english language, ill have to invent a term )
… ok not so quick update
GL_NEAREST - no filtering, no mipmaps
GL_LINEAR - filtering, no mipmaps
GL_NEAREST_MIPMAP_NEAREST - no filtering, sharp switching between mipmaps
GL_NEAREST_MIPMAP_LINEAR - no filtering, smooth transition between mipmaps
GL_LINEAR_MIPMAP_NEAREST - filtering, sharp switching between mipmaps
GL_LINEAR_MIPMAP_LINEAR - filtering, smooth transition between mipmaps
So:
GL_LINEAR is bilinear
GL_LINEAR_MIPMAP_NEAREST is bilinear with mipmaps
GL_LINEAR_MIPMAP_LINEAR is trilinear
As for speed it depends on texture LOD bias. Typically GL_LINEAR_MIPMAP_NEAREST would be fastest and GL_LINEAR would be slowest. Surprising? Not really - when using GL_NEAREST or GL_LINEAR there is only full-quality texture and with mipmaps, when scaled down, lower quality mipmap is selected therefore reducing memory bandtwidth requirements.
I actually like the D3D nomenclature better on this one.
They have MinFilter, MagFilter, and MipFilter
states. And the value for MipFilter describes how the results from neighboring miplevels are combined (in the minification case).
yes just quickly looked up and having a seperate mipfilter state is much cleaner
note, theres disagreement even here what bilinear is
ive noticed in the nvidia driver states u can force mipmaps ( i assume for greater performance with rendering 3d scenes ), i dont know if this is a good idea or not, esp 2d stuff where the user will only need the largest texture level (like my HUD stuff or a 2d game) now with the extra memory required, i could see this slowing performance.
the other overrides i do sorta agree with eg conformant texture clamp, antialiasing settings/ aniostropic settings
actually ive just thought of something much worse.
now in game each frame im updating lots of cubemaps per frame eg envmap, shadows + i have mipmaps turned off specifically for them, due to the fact they do occur a cost penelty also since the shadowmap cubemap size is generated based on its onscreen size, i dont want smaller mipmaps.
will the driver override my choice? thus something there for better performance/IQ will actually cost performance
As for forcing mipmaps - performance drop wouldn’t be that big - only few textures you render to would have to be upated, most likely once per frame, and since it’s done in HW cost would be comparable to clearing such texture by glClear. The problem is image quality. Imagine you have a chessboard - you could use 8x8 texture with GL_NEAREST, but if driver will enforce mipmaps your chessboard will look grey when viewed from low angles.
I remember NVIDIA had a setting in their driver that allowed user to manipulate texel offset in DX - this could really kill 2D rendering (imagine you’re using textures to display fonts) and such operations as tone mapping (instead of computing average brightness of the scene you could get brightness of the pixel in the corner).
Another thing would be antialiasing, especially in GPGPU applications. Right now AA is not supported when rendring to texture, but when it’s supported some apps can stop working properly on machines with AA enforced.
Note that such driver options are not quite compilant with OpenGL specs - if I use GL_LINEAR in my application and I will get GL_LINEAR_MIPMAP_NEAREST instead then something stinks here… Or do specs allow that?
>> thus something there for better performance/IQ will actually cost performance
I see your point here, but it is not on the performance/IQ quick settings (at least on NVIDIA), it is on a general list of tweaks, there is no assumption of enabling this would always be better.
If this worries you, add a section about it in your readme.txt 
Originally posted by k_szczech:
[QB] As for forcing mipmaps - performance drop wouldn’t be that big - only few textures you render to would have to be upated, most likely once per frame, and since it’s done in HW cost would be comparable to clearing such texture by glClear. The problem is image quality. Imagine you have a chessboard - you could use 8x8 texture with GL_NEAREST, but if driver will enforce mipmaps your chessboard will look grey when viewed from low angles.
well im updating quite a few cubemaps (shadows)
eg say i have 10 i wanna update a frame, thats 10x6(though i only update the sides where something changes, thats another question if i update 1 side of a cubemap do all sides mipmaps get regenerated? i assume not)
anyways ~60 unnecssary mipmap generations is not nice
Note that such driver options are not quite compilant with OpenGL specs - if I use GL_LINEAR in my application and I will get GL_LINEAR_MIPMAP_NEAREST instead then something stinks here… Or do specs allow that?
yeah it is strange, i assume if u ask for GL_LINEAR + GL_LINEAR with this override u will get GL_LINEAR_MIPMAP_NEAREST + GL_LINEAR
true the driver usually knows best (but not always)
btw im not trying to hassle the driver writers, im just worried about some driver optimization that will make my app slower
If this worries you, add a section about it in your readme.txt
ppl read those?, i assume from the number of emails ive had recently that they dont :eek: