opengl superbible 5 edition chapter 5——Basic Texturing

up until now, u have been rendering with points, lines, and triangles, and u have seen how u can shade their surfaces by calcualting color values and interpolating between them to simulate lighting effects. this is all well an dgood, and there are a substantial 大量的 number of 3D application market segments where this is all that is required. A tremendous shortcut to greater realism, however, is texture mapping. A texture is simply image data that can be applied to a triangle in your scene, filling in the solid areas with filtered texels (the texture-based equivalent of pixels). Figure 5.1 shows the dramatic effect a few texture files can add to your 3D renderings.

FIGURE 5.1 The stark contrast between textured and untextured geometry.

As you will come to see, however, in Chapter 7, “More Advanced Texture Topics,” textures have come to mean a great deal more than just image data and are a key ingredient to most modern 3D rendering algorithms.

As you will come to see, however, in Chapter 7, “More Advanced Texture Topics,” textures have come to mean a great deal more than just image data and are a key ingredient to most modern 3D rendering algorithms.

Raw Image Data
In the beginning, there were bitmaps. And they were…good enough. The original electronic computer displays were monochrome (one color), typically green or amber, and every pixel on the screen had one of two states: on or off. Computer graphics were simple in the early days, and image data was represented by bitmaps—a series of ones and zeros representing on and off pixel values. In a bitmap, each bit in a block of memory corresponds to exactly one pixel’s state on the screen. Figure 5.2 shows an image of a horse represented as a bitmap. Even though only two colors are used (black and white dots), the representation of a horse is still apparent 显而易见的. Compare this image with the one in Figure 5.3, which shows a grayscale image of the same horse. 灰度图 In this pixel rectangle (sometimes still
called pixmaps by the old timers), each pixel has one of 256 different intensities of gray. The term bitmap is often applied to images that contain grayscale or full-color data. This description is especially common on the Windows platform in relation to the poorly named .BMP (bitmap) file extension. Many would argue that, strictly speaking, this is a gross misapplication of the term. In this book, we never refer to pixel data as bitmaps. Color Plate 2 shows these two images again, but along side a full color RGB version.

pixel packing
Image data is rarely packed tightly into memory. On many hardware platforms, each row of an image should begin on some particular byte-aligned address for performance reasons. Most compilers automatically put variables and buffers at an address alignment optimal for that architecture. OpenGL, by default, assumes a 4-byte alignment, which is appropriate for many systems in use today. Many programmers misjudge the amount of memory required to store an image if they simply multiply the width by the height by the number of bytes per pixel.
For example, if you have an RGB image with three components (a red, a green, and a blue), each of which is stored in one byte (8 bits per color channel, this is actually quite typical), how much memory would you need for each row of the image if the image was say 199 pixels wide? You might think, well, simply 199 x 3 (one for each of the three color channels), which would be 597 bytes per row of image data. You might be right.
If you’re a good programmer, though, you really, really hate that word might! If your hardware’s native architecture is for 4-byte alignment (which most are), then the image will have an extra three bytes added to the end of each row of empty padding (making each row 600 bytes), just to make the memory address of each row start on an address that is evenly divisible by 4.

这也就是为啥图片的在unity里面是2的幂次方的原因，为了效率。

Many times, however, this works out by itself, especially if you stick to power of two textures (more on this later), but you should keep an eye on it because missing little things like this has a tendency to catch you with a strange hard-to-find memory-related bug somewhere down the road. Although this may seem like a waste of memory, this arrangement allows most CPUs to more efficiently grab blocks of data.

many uncompressed image file formats also follow this convention. the previously mentioned windows .bmp file format uses 4-bytes alignment for its pixel data; however, the targa (TGA) file format is 1-byte aligned… no wasted space. why other than for memory allocation purposes is this important to opengl? Because when you hand image data to OpenGL or ask OpenGL for image data, it needs to know how you want your data packed or unpacked in memory.

You can change how pixel data is stored and retrieved by using the following functions:

void glPixelStorei(GLenum pname, GLint param);
void glPixelStoref(GLenum pname, GLfloat param);

If you want to change to tightly packed pixel data, for example, you make the following function call:

glPixelStorei(GL_UNPACK_ALIGNMENT, 1);

GL_UNPACK_ALIGNMENT specifies how OpenGL unpacks image data from data buffers. Likewise, you can use GL_PACK_ALIGNMENT to tell OpenGL how to pack data being read from pixel buffers and placed in a user-specified memory buffer. The complete list of pixel
storage modes available through this function is given in Table 5.1 and explained in more detail in Appendix C, “OpenGL Man Pages for (Core) OpenGL 3.3.”

pixmaps

of more interest and somewhat greater utility on today’s full-color computer systems are pixmaps. a pixmap is similar in memory layout to a bitmap; however, each pixel may be represented by more than one bit of storage. extra bits of storage for each pixel allow either intensity (sometimes referred to as luminance values) or color component values to be stored. u can not draw a pixmap directly into the color buffer with the opengl core profile, but u can read the contents of the color buffer directly as a pixmap using this function:

void glReadPixels(GLint x, GLint y, GLSizei width, GLSizei height, GLenum format, GLenum type, const void *pixels);

u specify the x and y in window coordinates of the lower-left corner of the rectangle to read followed by width and height of the rectangle in pixels. if the color buffer stores data differently than what u have requested, opengl takes care of the necessary conversions. this capability can be very useful. the pointer to the image data, *pixels, must be valid and must contain enough storage to contain the image data after conversion, or u will likely get a nasty memory exception at runtime. also be aware that if u specify window coordinates that are out of bounds, u will get data only for the pixels within the actual opengl frame buffer.

mipmapping
mipmapping is a powerful texturing technique that can improve both the rendering performance and the visual quality of a scene. it does this by addressing two common problems with standard texture mapping. the first is an effect called scintillation闪烁 (aliasing artifacts) that appears on the surface of objects rendered very small on-screen compared to the relative size of the texture applied. scintillation can be seen as a sort of sparking that occurs as the sampling area on a texture map moves disproportionately to its size on the screen. 就是当贴图很大，但是在屏幕上显示的很小的时候，就会出现闪烁。the negative effects of scintillation are most noticeable when the camera or the objects are in motion. 特别是当运动的时候，画面闪烁的更厉害。

the second issue is more peformance-related but is due to the same scenario that leads to scintillation. that is, a large amount of texture memory must be loaded and processed through filtering to display a small number of fragments on-screen. this causes texturing performance to suffer greatly as the size of the texture increases.

the solution to both of these problems is to simply use a smaller texture map. however, this solution then creates a new problem: when near the same object, it must be rendered larger, and a small texture map will then be stretched to the point of creating a hopelessly blurry or blocky textured object.

the solution to both of these issues is mipmapping. mipmapping gets its name from the latin phrase multum in parvo, which means “many things in a small place”. in essence, u load not a single image into the texture state, but a whole series of images from largest to smallest into a single “mipmapped” texture state. opengl then uses a new set of filter modes to choose the best-fitting texture or textures for the given geometry. at the cost of some extra memory (and possibly considerably more processing work), u can eliminate scintillation and the texture memory processing overhead for distant objects simultaneously, while maintaining higher resolution versions of the texture available when needed.

a mipmapped texture consists of a series of texture images, each one half the size on each axis or one-fourth the total number of pixel of the previous image. this scenerio is shown in figure 5.11.

mipmap levels do not have to be square, but the halving of the dimensions continues until the last image is 1x1 texel. when one of the diemensions reaches 1, further divisions occur on the other dimension only. using a square set of mipmaps requires about one-third more memory than not using mipmaps.