prevnext   » SZS: Wiimms SZS Toolset » Guides » Mipmaps

Mipmaps

Contents

1.   Introduction

Mipmaps are smaller representations of the main image. A main image can have a series of mipmaps, each having half the height and width (rounded down) of the previous image. Any number of mipmaps are supported as long a mipmap has at least 1*1 pixels. They are always stored in the same image format as the main image and use whole blocks to store the pixels.

During rendering, mipmaps are used for textures that are distant. To render a given texture, the system generally computes how big it appears on screen, and then interpolates between the mipmap bigger and smaller than this size to produce texture information quickly. This behavior can be controlled by the materials sections within BRRES files.

If using images with different textures for mipmaps, textures can look different up close and far away. It is also possible to make objects invisible if they are close or far away.

2.   Resizing algorithms

If creating mipmaps, the source image must be resized to half width and half height (each rounded down). If both (width and height) are even, each new point is calculated by the average color of the 2x2 of the source. This can be done very fast with an easy algorithm.

If at least one size (width or height) is odd, a more complicated algorithm is needed. Wiimms SZS Tools support 2 algorithms for this case, one old and fast algorithm and one newer and smarter algorithm.

2.1   Fast algorithm

Example for fast resizing. The old and fast algorithm was default until v1.64a. Since v1.65a, it can be enabled by option --fast-mipmaps.

The fast algorithm only uses whole pixels of the source to create a new destiantion pixel.

For example, we have an image of 9x5 pixels (red and blue squares) that must be resized to 4x2 pixels (yellow frames). The number of source pixels used for a single destination pixel varies between 4 to 9. For diagonal lines or shapes, the result may look unnatural.

2.2   Smart algorithm

Example for smart resizing. The new and smart algorithm is default since v1.65a. It splits the source image into equal sized rectancles and break virtually some pixels into peaces.

The new color is calculated by the average of all source pixels with weights. Here, each destination pixel is created by 5.625 source pixels. This kind of calculation makes the smart algorithm slower (factor 2–4) compared to the fast algorithm, but the resized images (mostly mipmaps) look most likely better.

3.   Options

The following options control the scanning and creation of mipmaps.

Options
Option Param Description
--mipmaps If reading a source, scan for mipmaps and load them too. For PNG files, files named NAME.mm#.EXT with #=1.. are searched. This is the default. --mm is a short cut.
--no-mipmaps If reading a source, ignore mipmaps. This disables not the creation of mipmaps (see -n-mipmaps). --no-mm is a short cut.
--n-mipmaps num Force the number of mipmaps. Values between 0 and 20 are allowed. Value OFF (default) disables this option. If enabled, options --max-mipmaps and --mipmap-size are ignored. The creation of mipmaps stops if the width or the height of the mipmap becomes 0. --n-mm is a short cut.
--max-mipmaps num Control the automatic mipmap creation. Values between 0 and 20 are allowed and the default is 4. The mipmap creation for an image stops, if the set number is reached. This option is ignored, if --n-mipmaps is enabled. --max-mm is a short cut.
--mipmap-size num Define the minimal width and minimal height of a generated mipmap. Any value >0 is allowed. The default is 8. This option is ignored, if --n-mipmaps is enabled. --mm-size is a short cut.
--fast-mipmaps If resizing an image, use the old fast resize algorithm (default until v1.64a) instead of the new smart one. Both algorithms differ only, when creating a mipmap for images with odd width or odd height. The old algorithm is faster (factor 2-4) than the default algorithm, but the new algorithm creates better resized images. --fast-mm is a short cut.
--cmpr-default rgb1[,rgb2] Define 2 colors for the case, that all 16 pixels of a CMPR block are transparent. The default is to calculate an average color of all transparent pixels. Before v2.04 white was used.

2 RGB values (hex values with 6 digits each) are expected as parameter. If optional RGB2 is missed, a copy of RGB1 is used. As first step, both colors are converted to RGB565 colors C1 and C2 and sorted, so that C1<C2 (mandatory for CMPR). If C1 and C2 are identical, the least significant bit of green is cleared for C1 and set for C2.

Use parameter '0' to force black, '-1' to force white, or '-' to reset to auto calculation.