OGRE Wiki
Support and community documentation for Ogre3D
Ogre Forums
ogre3d.org
Log in
Username:
Password:
CapsLock is on.
Remember me (for 1 year)
Log in
Home
Tutorials
Tutorials Home
Basic Tutorials
Intermediate Tutorials
Mad Marx Tutorials
In Depth Tutorials
Older Tutorials
External Tutorials
Cookbook
Cookbook Home
CodeBank
Snippets
Experiences
Ogre Articles
Libraries
Libraries Home
Alternative Languages
Assembling A Toolset
Development Tools
OGRE Libraries
List of Libraries
Tools
Tools Home
DCC Tools
DCC Tutorials
DCC Articles
DCC Resources
Assembling a production pipeline
Development
Development Home
Roadmap
Building Ogre
Installing the Ogre SDK
Setting Up An Application
Ogre Wiki Tutorial Framework
Frequently Asked Questions
Google Summer Of Code
Help Requested
Ogre Core Articles
Community
Community Home
Projects Using Ogre
Recommended Reading
Contractors
Wiki
Immediate Wiki Tasklist
Wiki Ideas
Wiki Guidelines
Article Writing Guidelines
Wiki Styles
Wiki Page Tracker
Ogre Wiki Help
Ogre Wiki Help Overview
Help - Basic Syntax
Help - Images
Help - Pages and Structures
Help - Wiki Plugins
Toolbox
Freetags
Categories
List Pages
Structures
Trackers
Statistics
Rankings
List Galleries
Ogre Lexicon
Comments
History: Mipmapping
View page
Source of version: 3
(current)
{maketoc} !!How it works {img src="img/wiki_up/MipMap_Example_STS101.jpg" alt="frame|An example of mipmapping: the principal image on the left is accompanied by copies at reduced sizes."} Each bitmap image of the mipmap set is a version of the main texture, but at a certain reduced ((-LOD|level of detail)). Although the main texture would still be used when the view is sufficient to render it in full detail, the renderer will switch to a suitable mipmap image (or in fact, interpolate between the two nearest) when the texture is viewed from a distance, or at a small size. Rendering speed increases, since the number of texture pixels (((texel))) being processed can be much lower than with simple textures. Artifacts are reduced, since the mipmap images are effectively already ((Anti-aliasing|anti-aliased)), taking some of the burden off the real-time renderer. If the texture has a basic size of 256 by 256 ((pixel))s (textures are typically squared and must have side lengths equal to a power of 2), then the associated mipmap may contain a series of 8 images, each half the size of the previous one: 128×128 pixels, 64×64, 32×32, 16×16, 8×8, 4×4, 2×2, 1×1 (a single pixel). The easiest way to make these textures is using the so called [http://www.ogre3d.org/wiki/index.php/All_about_textures#The_.DDS|The .DDS]tools. !!For Programmers If, for example, a scene is rendering this texture in a size of 40×40 pixels, then an interpolation of the 64×64 and the 32×32 mipmaps would be used. The simplest way to generate these textures is by successive averaging, however more sophisticated algorithms (perhaps based on signal processing and Fourier transforms) can also be used. The increase in storage space required to store all of theses mipmaps for a texture is a third, because the sum of the areas 1/4 + 1/16 + 1/256 + ... converges to 1/3. (This assumes ((image compression)) is not being used.) This is a major advantage of this selection of resolutions. However, in many cases, the filtering should not be uniform in each direction (it should be anisotropic, as opposed to isotropic) and a compromise resolution is used. If a higher resolution is used, the cache coherence goes down and the aliasing is increased in one direction, but the image tends to be clearer. If a lower resolution is used, the cache coherence is improved, but the image is overly blurry, to the point where it becomes difficult to identify. To help with this problem, nonuniform mipmaps (also known as rip-maps) are sometimes used. With a 16×16 base texture map, the rip-map resolutions would be 16×8, 16×4, 16×2, 16×1, 8×16, 8×8, 8×4, 8×2, 8×1, 4×16, 4×8, 4×4, 4×2, 4×1, 2×16, 2×8, 2×4, 2×2, 2×1, 1×16, 1×8, 1×4, 1×2 and 1×1. The unfortunate problem with this approach is that rip-maps require four times as much memory as the base texture map and so rip-maps are very unpopular. To reduce the memory requirement and simultaneously give more resolutions to work with, summed-area tables were conceived. Given a texture <math>(t_{jk})</math>, we can build a summed area table <math>(s_{jk})</math> as follows. The summed area table has the same number of entries as there are texels in the texture map. Then, define: {EQUATION()}s_{mn}:=\sum _{1 \leq j \leq m,\ 1 \leq k \leq n} t_{jk}{EQUATION} The average of the texels in the rectangle (a{SUB()}1{SUB},b{SUB()}1{SUB}~np~]~/np~ × (a{SUB()}2{SUB},b{SUB()}2{SUB}~np~]~/np~ is given by: {EQUATION()}s_{a_2b_2}-s_{a_1b_2}-s_{a_2b_1}+s_{a_1b_1} \over {(a_2-a_1)(b_2-b_1)}{EQUATION} However, this approach tends to exhibit poor ((cache)) behavior. Also, a summed area table needs to have wider types to store the partial sums {EQUATION()}s_{jk}{EQUATION} than the word size used to store {EQUATION()}t_{jk}{EQUATION}. For these reasons, there isn't any hardware that implements summed-area tables today. A compromise has been reached today, called anisotropic mip-mapping. In the case where an anisotropic filter is needed, a higher resolution mipmap is used and several texels are averaged in one direction to get more filtering in that direction. This has a somewhat detrimental effect on the cache, but greatly improves image quality.
Search by Tags
Search Wiki by Freetags
Latest Changes
IDE Eclipse
FMOD SoundManager
HDRlib
Building Ogre V2 with CMake
Ogre 2.1 FAQ
Minimal Ogre Collision
Artifex Terra
OpenMB
Advanced Mogre Framework
MogreSocks
...more
Search
Find
Advanced
Search Help
Online Users
195 online users