Re: [Algorithms] mip mapping is evil!
Brought to you by:
vexxed72
From: Stephen J B. <sj...@li...> - 2005-01-07 21:26:40
|
Rowan Wyborn wrote: > hullo, > > I just had a thought this morning... mip mapping is evil! It addresses aliasing in high frequency > detail by just well, throwing away the high frequency detail. Well, you can't draw high frequency detail that's smaller than a pixel - so some way of 'summarising' all of those higher frequency things into a single RGB that you can write to the pixel is needed. Filtering. So instead of thinking of the MIPmap as simply throwing away those high frequency components, think of it as 'precomputed filtering'. For every part of the map, you pre-compute the results of whatever filter kernel you favor at a variety of scales and put those results into the MIPmap. A large part of the problem is that MANY developers do their filtering using a simple box filter (add up four texels and divide by four). This sucks from a theoretical perspective. Other filters can (and are) used to great effect. You can use bi-cubic filters - or you could take the Fourier transform of the image, cut off the high frequencies and then do the inverse Fourier...there are LOTS of possibilities. However, there are still problems. If you imagine a four texel 1D texture. What you'd like to have for the realtime display of that texture would be one MIPmapped texel that summarises the results of filtering a region that's two texels across centered between texels 0 and 1 and another centered between 1 and 2, another between 2 and 3 and so on. However, you don't have that. You only have a single filtered RGB for the region between 0 and 1 and another between 2 and 3. So if the screen pixel covers two texels and is centered between texels 1 and 2, the hardware is forced to do a linear interpolation between the 0/1 texel and the 2/3 texel. This does indeed throw away some information that could have been preserved. That would give you a system where a 256x256 texture would need FOUR 128x128 MIPmaps - each offset by one top-level texel in either S or T or both. Then you'd need sixteen 64x64 maps, sixtyfour 32x32's and so on. For a 256x256 map, you'd need eight times the amount of storage compared to the base map instead of just a third extra in the case of regular MIPmapping. It doesn't stop there - you'd also like a map that's 128x256, another that's 256x128, a 64x256 and a 64x128...that increases the storage requirement by another factor of 4. There are techniques out there for improving on MIPmapping - but they all either eat lots of texture memory (eg RIPmapping) or lots of RAM bandwidth (eg Anisotropic filtering) - which tend to make them unpopular with people who are trying to make a profit selling a board for under $100. ----------------------------------------------------------------------- The second law of Frisbee throwing states: "Never precede any maneuver by a comment more predictive than "Watch this!"...it turns out that this also applies to writing Fragment Shaders. ----------------------------------------------------------------------- Steve Baker (817)619-2657 (Vox/Vox-Mail) L3Com/Link Simulation & Training (817)619-2466 (Fax) Work: sj...@li... http://www.link.com Home: sjb...@ai... http://www.sjbaker.org |