1. Field of the Invention
Embodiments of the present invention generally relate to computer programming using graphics hardware. More specifically, embodiments of the invention relate to defining, loading, and manipulating texture arrays using a graphics library.
2. Description of the Related Art
Graphics processing units (GPUs) are configured to execute instructions that generate images displayed on a display device. Some graphics APIs expose an interface to graphics application developers that consists of a set of calls written in a high-level programming language. To access specific capabilities of a target GPU, developers typically write shader programs for the target GPU in a high-level programming language, such as the OpenGL Shading Language (GLSL). The shader programs are conveyed through the API to driver software that is configured to compile and assemble the shader programs into machine code programs. The machine code programs are then executed on the appropriate GPU processing units, as specified in the original shader program text.
One well-known technique used by graphics hardware is texture mapping, where data stored in graphics memory is mapped to various pixels on vertices being processed in a graphics rendering pipeline. To take advantage of hardware based texture mapping, a developer may specify both the texture to use and how the texture should be applied to each pixel or vertex, enable texture mapping, and then render a scene, supplying both the texture and geometric coordinates of the pixels or vertices. Each of these actions may be invoked using calls provided by the graphics API. Conventional texture mapping has been extremely successful, and nearly every 3D computer game today uses some form of texture mapping. In addition to two-dimensional (2D) texture maps, graphics hardware may also support the use of one-dimensional (1D) texture maps, three-dimensional (3D) texture maps and texture cube maps. Among other things, 3D texture maps have applications in medical imaging and geological analysis, and texture cube maps are useful for rendering an object with reflective surfaces.
While texture mapping has been very successful, and a broad span of graphics hardware provides support for texture maps, some problems have been identified. One issue is that, in some cases, using multiple texture maps to render similar objects is inefficient with conventional processes. Consider, for example, a video game that uses texture mapping to render military uniforms worn by a group of military soldiers. If the uniform for each figure is different, a separate texture is used. Rendering these uniforms requires a developer to load a texture map using an API call, render the geometry of a figure using that texture map, and then repeat this process to render the next figure. This process of separately loading each texture map is quite inefficient and reduces the speed at which the graphics hardware can render the full group of military soldiers. This shortcoming is exacerbated when mipmapping is used, as each mipmap image has to be loaded individually using an API call. Additionally, the use of separate textures requires that application developers incur the overhead of an API call to activate a new texture each time a different type of soldier (or other graphics image) is drawn. Some applications may deal with this problem by accepting the API call overhead. Others may perform the possibly cumbersome step of sorting their scenes by textures used to minimize the number of calls. Still others may merge individual texture images into a single larger texture image and accept the filtering artifacts that result from this approach as neighboring textures bleed together.
As the foregoing illustrates, what is needed in the art is way to load, access, and manipulate texture maps in a graphics library that library avoids one or more of the problems set forth above.