Explain mipmapping to me again...

[TheGecko]

OK I though I had a grasp about what exactly mip mapping is but after I saw a demo of mipmapping in action,I'm now totally confused.

Correct me if I'm worong,but mipmapping is a method of displaying textures at a lower resolution the farther away you are from the camera and the res of the texture increases the closer the camera gets,right?

Well....say I'm using a 256x256 texture on a polygon,now wheather I'm up close to the polygon or farther away,I still don't see the point of mipmapping.I mean,I already created the texture and mapped it onto a polygon,why should I now care about lowering the res from farther away? Is there a drawback to using my high res texture throughout my entire game? And what do you guys mean when you say "hi res" or "low res" ? do you mean the dimensions of my texture map or do you mean less colors?

Thanx for the replies!

[AndersO]

One point with mipmapping is to get rid of the weird patterns that occur when your textured polygons are far away.

Do a comparision between a polygon with and without mipmapping that moves away from the camera and you'll see the point with mipmapping.

Why those patterns occur and why mipmmaping makes them go away pherhaps someone brighter than me can explain.

Cheers

[john]

Hello,

Mip-maps have two purposes:

1) you can pre-filter the image when it's smaller to make it look better than a large image filtered by the graphics h/w at run-time, and
2) to improve performance when texture memory is limited

A given texture is a point sample of some image. The graphcis hardware needs to *resample* the texture if the projected polygon is smaller than the texture. There are a number of ways of doing this. One way is a very poxy "discard data that we can't fit", like so:

[1][2][3][4][5] (textels)

[1][3][5] (poly)

ie. throw out textels 2 and 4 so our 5 textel image can map to the three pixel poly. But... what if our texture is of a chequer pattern... so that odd pixels are white and even pixels are black. This resampling method will throw aweay all the black pixels and we'll end up with a sold white polygon. This looks decidedely dodgey... especially when the polygon gets bigger and suddenly we change mimaps and use the texture with black in it.

What is more desireable when resampling images is to reasmple the function the image represents. Now, i'm not going to get into the lengthy "a pixel isn't a square" debate, because no one would believe me and everyone would think I'm just f?@#ked in the head. For the record: a pixel is NOT A LITTLE SQUARE> it's a point sample of an analogue intensity function. Graphics programs with a tad more intelligence than the simple discard reconstruction filter mentioned above fit curves through the pixels and resample the function to map to fewer points. Or, a simple way of saying this is to use a bilinear texture filter and muneg the black and white together to make a grey polygon. OKay, the grey isn't a chequer pattern, either, but it's a better representation than just a white poly.

Yes, some graphics h/w can do bi-linear filtering on chip, but the didn't all use to do that. But, that leads onto the second point:

large textures are not always used. It's a waste of bandwidth to transfer a 1024x1024 texture to a group of polygons which only take up 8x8 pixels on screen. It is much better, in this case, to use a smaller mipmap which takes less time to transfer from host to video memory.

anyway, enough of my meandering mumble.

cheers
John

[Tom Nuydens]

Originally posted by john:
large textures are not always used. It's a waste of bandwidth to transfer a 1024x1024 texture to a group of polygons which only take up 8x8 pixels on screen. It is much better, in this case, to use a smaller mipmap which takes less time to transfer from host to video memory.

It sounds good in theory, but if I understand correctly, it doesn't work out that way in practice. Even if you only need the 8x8 pixel mipmap, your drivers are still going to transfer the whole mipmap pyramid to the 3D card. I recall a .plan update by John Carmack that mentioned this problem, and his proposed solution was to virtualize the video memory, so data could be transfered in pages of, say, 4 KB. 3Dlabs is doing this already: http://www.3dlabs.com/products/vtpaper.pdf

[fresh]

Traversing a 1024x1024 map when texturing a 8x8 pixel (in screen) poly is going to trash your cache! That's the major reason for the speedup when using mipmaps.

mipmaps are almost always a win. That's why some older drivers *cough*NVidia*cough* auto-generated them even if the app didnt request them.