Texture tiling with adjacency information

[0002] This application claims the benefit of U.S. Provisional Application No. 60/238,128, filed Oct. 6, 2000, the full text of which is incorporated herein by reference as if reproduced in full below.

[0003] 1. Field of the Invention

[0004] The present invention relates generally to computer graphics.

[0005] 2. Related Art

[0006] Computer graphics systems render all kinds of objects for screen display and animation. An object is modeled in object space by a set of primitives (also called graphics primitives). Examples of primitives include, but are not limited to, triangles, polygons, lines, tetrahedra, curved surface, and bit-map images. Each primitive includes one or more vertices that define the primitive in terms of position, color, depth, texture, and/or other information helpful for rendering. Each primitive can be further broken up into fragments. Each fragment when projected for rendering on a screen, corresponds to all or part of an area of one pixel. For example, a polygon or curved surface can be broken up through scan conversion into fragments. Fragments can also include vertices or per-vertex information.

[0007] Textures are used to add further visual information. By utilizing texture mapping techniques, color and other details can be applied to areas and surfaces of objects. In texture mapping, a pattern image (also referred to as a “texture” or texture map”) is combined with an area or surface of an object to produce a modified object with the added texture detail. For example, given the outline of a featureless cube and a texture map defining a wood grain pattern, texture mapping techniques can be used to “map” the wood grain pattern onto the cube. The resulting display is that of a cube that appears to be made of wood. In another example, terrain (e.g., images of a town, river, vegetation and trees) can be added by texture mapping to an otherwise barren terrain model.

[0008] The demand for large textures is increasing. Many graphics applications increasingly demand a large contiguous texture. The cost of increasing texture memory and/or hardware to accommodate a large contiguous texture can be prohibitive.

[0009] Due to the importance of large contiguously textured databases to many graphics applications, schemes have been implemented which allow an application to apply massive textures over databases such as terrain, while operating within the limited constraints of hardware resources. These have ranged from software-only schemes which slice the underlying geometry into tiles corresponding to texture files, to hardware implementations which treat the image as a homogeneous entity.

[0010] Consider two examples of such schemes, clip-mapping and texture tiling. Clip-mapping is a relatively specialized and sophisticated scheme that uses a clip-map. See, U.S. Pat. No. 5,780,783 issued to Migdal et al. and incorporated in its entirety herein by reference. For example, a clip-map can be a multiresolutional texture map pyramid (such as, a MIP map) clipped to a “clip size” that covers a single view being rendered. See, the example clip-map MW pyramid 100 in FIG. 1A. The image space is treated as a homogeneous entity for texturing purposes. Paging supplies a region 102 of high resolution in the area of most immediate interest with decreasing resolution as one moves away from the region of interest. Naturally the region of interest may be moved with the viewer in order to sustain high resolution in an animated scene. Torroidally wrapped texture addressing can be used to accommodate texture updates in clip-mapping. See, e.g., Tanner et al., “The Clipmap: A Virtual Mipmap,” Computer Graphics Proceedings, Annual Conf. Series, 1998 (SIGGRAPH '98), pp. 151158. As depicted in FIG. 1B, such torrodial wrapped texture addressing allows new data 102B to be added to a clip-map tile as old data 102A is removed. This is a relatively complex scheme which can be difficult to adopt in many applications which drive consumer-level products.

[0011] Texture tiling creates a series of tiles. The tiles represent portions of a contiguous image space. These tiles are applied as unique textures with associated unique texture identifiers (referred to herein as “texture IDs” or “texture handles”) to a series of tiled geometry segments. This requires that the application or database creator chop the geometric database into tiles to match the texture representation. A database is triangulated when it is chopped up to meet image paging requirements. FIG. 1C shows how an example triangle primitive 110 might have to be divided into four parts when it overlays four texture image tiles (Tile 1, Tile 2, Tile 3, and Tile 4).

[0012] Furthermore, as the database is viewed from a distance, ideally one would like fewer tiles to be applied to the database requiring that a quad tree or similar tiling structure be implemented to manage geometric complexity; this in turn requires a quad tree texture representation. While not entirely forced by the geometric issues, a software implementation quickly becomes a rather unwieldy proposition and suffers from some flaws. If implemented without consideration of filtering at the borders of the texture boundaries, there will be apparent texture filtering discontinuities across tile boundaries. The magnitude of these boundaries varies with the level of MIP map being applied to the respective tiles.

[0013] Graphics hardware has been built which avoids the need to subdivide the geometry using fragment selection within the range of the texture and multipass rendering on the underlying geometry. With this approach, any fragment outside the immediate texture image is not rasterized. This test is performed repeatedly with different images in different locations in a sequence of rendering passes. The issue of filtering then remains.

[0014] One or more extensions have been implemented to cope with filtering while subdividing the geometry in the application. For instance, texture border image support has been designed into graphics hardware implementations to allow filtering under these circumstances to be handled smoothly. Using such a scheme as described in U.S. Pat. No. 5,230,039, which is incorporated herein by reference in its entirety, a portion of the adjacent tile is specified by the application for filtering purposes. This scheme still requires the subdivision of the database based on texture border tiles, but it avoids the filtering artifacts at the tile edges. FIG. 1D shows an example that illustrates the specification of borders to avoid filtering issues. As illustrated, a triangle 120 is divided into fragments 120A and 120B. Fragment 120A will be textured with tile 1 while fragment 120B will be textured with tile 2. Note border portion 122 of fragment 120A and border portion 124 of fragment 120B. These border portions 122,124 will be textured with border portions 126,128 of texture tiles 1 and 2. This scheme provides filtering for a smooth transition between the texture tiles. However, the drawback of having to break the geometry into tiles remains.

[0015] A modified scheme described in U.S. Pat. No. 5,815,157, which is incorporated herein by reference in its entirety, uses an adjacent portion of texture memory to store borders of the image tile under consideration to the side of a tile in an oversized region of texture memory. A variation on the scheme is to use a larger portion of texture memory and a texture matrix to manipulate the application of texture coordinates such that the tile of texture under consideration and its borders become part of a contiguous texture memory space. FIG. 1E illustrates an example of an adjusted layout in memory for contiguous mapping. Note texture tile 130 and borders 132 which are stored in a larger portion 134 of texture memory.

[0016] To eliminate the strict requirement for geometry subdivision along tile boundaries, a scheme can be implemented where overlapping textures are applied to the image in texture memory. Instead of clamping to the original image boundary, the adjacent images may be addressed for triangles which extend a short way beyond the conventional image border. If one rearranges the in memory representation described in U.S. Pat. No. 5,815,157, it can be seen that conventional hardware may be used and the subdivision of database triangles is avoided. By placing the original texture tile in the center of an oversized texture, it is easy to see that the border images are simply extensions of the original tile in a conventional texture memory addressing scheme.

[0017] Another way of visualizing this type of scheme is to see that the texture tiles in memory are actually overlapping with each other. The reason this is done is to avoid geometry which must be textured with two or more separate textures. A remaining constraint on the geometry is that primitives near the edge of a tile may not exceed the size of the region of overlap. FIG. 1F illustrates an example of overlapping texture borders which can be used to supply a single texture to graphics primitives without subdivision. For example, FIG. 1F illustrates texture tiles 1 and 2 which share a common overlap region 140. As a result of overlap region 140, triangle T1 can be textured using only texture tile 1. Similarly, triangle T3 can be textured using only texture tile 2. Triangle T2 can be textured using either of texture tiles 1 or 2 since it lies entirely in overlap region 140. The price of this scheme is increased texture memory usage and redundant texture paging to supply the data for the region of overlap. It also requires non-trivial management of texture memory, since the data on disk is likely to be in a tiled format without the overlap, subloading of texture. Images with memory strides is required, which further reduces paging performance.

[0018] What is desired is the ability to decouple geometry from texture tiling and to avoid the need to implement difficult or complex torroidal mapping schemes or tricky underused border schemes. It is also desirable to avoid the redundancy of overlapping texture schemes while increasing the ease of implementation and performance of a paging approach. A system and method is needed which can apply unique texture over extended areas with limited hardware texture memory (requiring paging) while imposing few restrictions upon a database. Extensive hardware, onerous restrictions upon a database, and/or difficult implementations which waste paging bandwidth need to be reduced or avoided.

[0019] The present invention solves the above problems and needs. In one embodiment, a novel graphics extension is provided that allows an application to seamlessly apply large contiguous texture over a database while supporting the paging of texture and operating within the constraints of limited available texture memory and real-time rendering requirements.

[0020] In one embodiment, the present invention provides a solution that allows the specification of a texture image as the border to another for texture tiling purposes. This means that when texture addressing extends beyond the region within a texture map another image is addressed instead of a repeated version of the original image or a border color or a reflected version of the image as is currently common practice. This specification of a border image would include the ability to specify different texture images for each of the 8 tiling directions: +s, −s, +t, −t, +s+t, −s−t, −s+t, and +s−t. Using this system, an array of images could be linked to one other to form a massive meta image. Within the region covered by these images, a graphics primitive such as a triangle or triangle strip which is less than the size of 3 individual images could be textured with a single unique texture tile. Tiles could optionally be paged and even joined at different resolutions. In addition more parameters could be optionally supported to allow the mapping of different sized images to be adjacent to one another (to allow different sized tiles at different resolutions over various parts of a database).

[0021] In one embodiment, a routine for texture processing uses texture tiling and adjacency information. A base texture image and adjacent border textures are loaded in texture memory. The base texture image is associated with adjacency information. A graphics primitive is then mapped to adjacent border textures identified by the adjacency information. In one example, this mapping includes evaluating texture coordinate values to determine when texture coordinates are outside a range of a base texture image being texture mapped, and determining which adjacent border texture corresponds to the texture coordinates evaluated to be outside the base image. This determination is made using adjacency information which identifies the direction of the adjacent border texture relative to the base image.

[0022] The present invention can be used by a broad base of developers and is applicable to many general rendering tasks. The implementation of the present invention can be straightforward. The size of primitives at the borders can be increased. The size of graphics primitives is not constrained by the size/redundancy of an overlap region. This improves the ease of use, reduces the database constraints and potentially increases the adoption of a system and method according to the present invention by software developers.

[0023] The present invention provides a more generally applicable extension than clip-mapping alone. This extension has broad use in graphics applications while being easy to implement and straighforward to program.

[0024] Further, geospecific texture mapping is a key requirement for many applications. The present invention makes database and software support for geospecific paging easier, it also makes it more likely to be adopted by independent hardware vendors (IHVs) given the generally useful nature of the idea.

[0025] By providing a texture object with border textures for tiling purposes, the present invention can elegantly extend the capability of existing hardware to support unrestricted texture roaming with little or no texture memory redundancy and few restrictions on database construction. It avoids the traditional problem of having to chop up the database into tiles and does not require that overlapping images in memory be created.

[0026] The present invention can be used in any graphics application, toolkit, library, software, hardware or other graphics system.

[0027] Further features and advantages of the present invention, as well as the structure and operation of various embodiments of the present invention, are described in detail below with reference to the accompanying drawings.

[0028] The accompanying drawings, which are incorporated herein and form part of the specification, illustrate the present invention and, together with the description, further serve to explain the principles of the invention and to enable a person skilled in the pertinent art to make and use the invention. In the drawings, like reference numbers indicate identical or functionally similar elements. Additionally, the left-most digit(s) of a reference number identifies the drawing in which the reference number first appears.

[0029] FIG. 1A shows an example memory representation of a clip-map.

[0030] FIG. 1B shows updating new data in a clip-map tile for a single clipped level of MIP map.

[0031] FIG. 1C illustrates how an example triangle primitive might have to be divided into parts when it overlays multiple texture image tiles.

[0032] FIG. 1D illustrates the specification of borders to avoid filtering issues in texture tiling.

[0033] FIG. 1E is a diagram of an example tile of texture and its borders that are part of a contiguous texture memory space.

[0034] FIG. 1F illustrates an example of overlapping texture borders which can be used to supply a single texture to graphics primitives without subdivision.

[0035] FIG. 2A shows an example of a graphics primitive mapped to a texture image.

[0036] FIG. 2B shows an example of a graphics primitive that extends beyond a texture image.

[0037] FIG. 3 shows how valid texture data is clamped or repeated to cover regions where the graphics primitive is over extended in a conventional texture tiling approach.

[0038] FIG. 4 shows an example according to the present invention where a texture image has eight adjacent border texture images in eight different directions.

[0039] FIG. 5 shows an example according to the present invention where a texture image has three adjacent border texture images in three different directions.

[0040] FIG. 6 shows how a graphics primitive that extends beyond the Image1 tile in FIG. 4 is texture mapped according to the present invention.

[0041] FIG. 7 shows how a graphics primitive that extends beyond the Image1 tile in FIG. 5 is texture mapped according to the present invention.

[0042] FIG. 8A shows a routine for texture processing using texture tiling and adjacency information according to one embodiment of the present invention.

[0043] FIG. 8B further shows these texture processing steps are carried out with respect to examples of FIGS. 4-7 according to the present invention.

[0044] FIG. 9 shows a routine for texture processing using texture tiling and adjacency information according to one embodiment of the present invention.

[0045] FIG. 10 shows an example of the primitive of FIG. 7 processed with a single texture unit with black border color to produce an image with texture only where coordinates fall between 0 and 1 according to an embodiment of the present invention.

[0046] FIG. 11 shows how multi-texture units can be used to carry out an embodiment of the present invention.

[0047] FIG. 12A shows an example of how texture coordinates transform from an initial texture tile map in three directions denoted by arrows to three adjacent border texture tiles according to the present invention.

[0048] FIG. 12B shows an example of how three adjacent border texture tiles are applied to a primitive when rendering with an initial texture tile map according to the present invention.

[0049] FIG. 13 is a diagram of an example architecture in an implementation of the present invention.

[0050] Terminology

[0051] The term “adjacency information” refers to any information that directly or indirectly identifies, points to, or names one or more textures adjacent to a particular texture of interest. For example, adjacency information can include but is not limited to information that identifies one or more tiles adjacent to a texture tile associated with a primitive. This adjacency information can include one or more texture handles or texture IDs for a texture object. Adjacency information is supplied for one or more potential tiling directions.

[0052] Texture Tiling with Adjacency Information

[0053] The present invention provides a method, system, and computer program product for texture tiling based on adjacency information. Adjacency information is supplied for one or more potential tiling directions. In one example, adjacency information is supplied for eight potential tiling directions radiating in eight different directions relative to an original texture image. In another example, adjacency information is supplied for three potential tiling directions.

[0054] The present invention provides a solution that allows the specification of a texture image as a border to another for texture tiling purposes. This means that when texture addressing extends beyond the region within a texture map another texture image is addressed.

[0055] This specification of a border image includes the ability to specify different adjacent textures for each of the 8 tiling directions: +s, −s, +t, −t, +s+t, −s−t, −s+t, and +s−t. In the present invention, an array of images can be linked to each other to form a massive meta image. Within the region covered by these images, any graphics primitive such as a triangle or triangle strip which was less than the size of three individual images could be textured with a single unique texture tile. Tiles could optionally be paged and even joined at different resolutions, in addition more parameters could be optionally supported to allow the mapping of different sized images to be adjacent to each other to allow different sized tiles at different resolutions over various parts of a database.

[0056] In one embodiment, an extension adds a texture clamping behavior. This extension allows an application to supply adjacent information that identifies one or more tiles adjacent to a texture tile. This adjacency information can include texture handles for a texture object. This extension can be implemented in software, firmware, hardware or any combination thereof. In one embodiment, this extension is added to a graphics application programming interface or library, such as, but not limited to OPENGL, available from Silicon Graphics, Inc. Mountain View, Calif.

[0057] When rendering with an original texture bound, if the texture coordinates are outside the range of 0.0 to 1.0 then instead of existing options to clamp or to tile the image, another adjacent texture image would be used to tile instead. Adjacency information is supplied for one or more potential tiling directions. In one example, adjacency information is supplied for eight potential tiling directions radiating in eight different directions relative to an original texture image. Supplying all eight directions provides a symmetry that appeals to software developers. In another example, adjacency information is supplied for three potential tiling directions.

[0058] In general, the number of tiling directions affects the size of a supported primitive before geometric subdivision must occur. With tiling in all directions, a graphics primitive up to two times the size of the original image tile size is guaranteed to have a unique texture object which can be bound while rendering it. With only three tiling directions supported, the graphics primitive has a guaranteed size which does not exceed the size of a texture tile. Larger sizes can be used but rely on the relationship of the primitives to the original tiling pattern. Either scenario compares extremely favorably with an overlapping texture border scheme, such as that described with respect to FIG. 1F, while avoiding the need for redundant texture downloads or complex subload work by software developers.

[0059] FIG. 12A shows an example of how texture coordinates from an initial texture tile 1 map in three directions denoted by arrows to three adjacent border texture tiles (Border Tiles 1-3). FIG. 12B shows an example of how adjacent border texture tiles (also called adjacent border images) are applied to a primitive when rendering a Tile 1 texture. Texture tiling with adjacency information is described in more detail below with a respect to a texture processing routine.

[0060] Texture Processing with Texture Adjacency Information

[0061] As described above, the present invention allows a large contiguous texture to be used even with limited texture paging resources and avoids or reduces geometry subdivision. To understand the texture processing and advantages of the present invention, it is helpful to review texture mapping briefly. As shown in FIG. 2A, in texture mapping, texture coordinates (s,t) map texels of a texture image to corresponding vertices (v0,v1,v2) of a graphics primitive. Texture coordinates are typically normalized to a range between 0 and 1 as shown in FIG. 2A. Sometimes, a graphics primitive extends beyond a texture image as shown in FIG. 2B. In this case in conventional texture tiling, the graphics primitive is drawn with valid texture data only. Texture data is unavailable for the regions where the graphics primitive is over extended. Valid texture data is either clamped or repeated to cover these regions where the graphics primitive is over extended. This is illustrated in FIG. 3.

[0062] The present invention uses adjacent border texture tiles to handle an extended graphics primitive. Two examples using eight and three border textures, respectively, are described in detail. FIG. 4 shows an example according to the present invention where an Image 1 has eight adjacent border texture images (Images 2-9) in eight different directions. These eight directions for example can correspond to 8 directions (N, NE, E, SE, S, SW, W, and NW) as shown. FIG. 5 shows an example according to the present invention where an Image 1 tile has three adjacent border texture images (Images 2-4) in three different directions. These three directions for example can correspond to three directions (labeled north N, northeast NE, and east E) as shown.

[0063] FIG. 6 shows how a graphics primitive that extends beyond the Image1 tile in FIG. 4 is texture mapped according to the present invention. To process the graphics primitive, texture is sampled from Image 1 and from each of the appropriate textures identified by the adjacency information. In this case, the primitive extends beyond the base Image 1 in all eight directions. Accordingly, the graphics primitive is mapped to texture sampled from image 1 and from each of the 8 adjacent border texture images (Images 2-9) as shown in FIG. 6.

[0064] FIG. 7 shows how a graphics primitive that extends beyond the Image1 in FIG. 5 is texture mapped according to the present invention. To process the graphics primitive, texture is sampled from Image 1 and from each of the appropriate textures identified by the adjacency information. In this case, the primitive extends beyond the base Image 1 in all three directions. Accordingly, the graphics primitive is mapped to texture sampled from image 1 and from each of the 3 adjacent border texture images (Images 2-4) as shown in FIG. 7.

[0065] FIG. 8A shows a routine 800 for texture processing using texture tiling and adjacency information according to one embodiment of the present invention (steps 810-830). In step 810, a base texture image and adjacent border textures are loaded in texture memory. In step 820, a base texture image is associated with adjacency information. In step 830, a graphics primitive is mapped to adjacent border textures identified by the adjacency information.

[0066] During texture processing in any computer graphics system or pipeline, mapping step 830 is carried out. In one example, in mapping a graphics primitive to adjacent border textures, two steps are carried out according to the present invention. The first step evaluates texture coordinate values to determine when texture coordinates are outside a range of a base texture image being texture mapped. The second step determines which adjacent border texture corresponds to the texture coordinates evaluated to be outside the base image. This determination is made using adjacency information which identifies the direction of the adjacent border texture relative to the base image.

[0067] FIG. 8B further shows these steps are carried out with respect to Images 1-4 (Base Image 1 and Adjacent Border Images 2-4) from the examples of FIGS. 4-7. Base Image 1 is assigned texture coordinate values (s,t) where both s and t coordinates are between 0 and 1.0. Adjacent Border Image 2 has texture coordinate values (s,t) where s is mapped between 0 and 1.0 and t is mapped from a range 1.0-2.0 to a range 0-1.0 (i.e., t=t−1.0). Adjacent Border Image 4 has texture coordinate values (s,t) where t is mapped between 0 and 1.0 and s is mapped from a range 1.0-2.0 to a range 0-1.0 (i.e., s=s−1.0). Adjacent Border Image 3 has texture coordinate values (s,t) where s and t are mapped from a range 1.0-2.0 to a range 0-1.0 (i.e., s=s−1.0 and t=t−1.0). Such coordinate transformation can be like that used in modulo addressing. See, also the example shown in FIG. 12A.

[0068] FIG. 9 shows a routine for texture processing using texture tiling and adjacency information 900 according to one embodiment of the present invention (steps 910-960). In step 910, texture coordinates are interpolated. At step 915, for each filter sample control proceeds to perform evaluation and determining steps (920-936). The evaluation steps (920-924) test the texture coordinate values to determine when texture coordinates are outside a range of a base texture image being rendered. In step 920, the s coordinate value is checked to see if it is greater than 1.0. If yes, control proceeds to step 922. If no, control proceeds to step 924. In step 922, the t coordinate value is checked to see if it is greater than 1.0. If yes, control proceeds to step 936. If no, control proceeds to step 934.

[0069] In step 924, the t coordinate value is checked to see if it is greater than 1.0. If yes, control proceeds to step 932. If no, control proceeds to step 930.

[0070] The determining steps (steps 930-936) determine which adjacent border texture correspond to the texture coordinates evaluated to be outside the base image. This determination is made using adjacency information which identifies the direction of the adjacent border texture relative to the base image. In step 930, an address is sampled from a texture image 1. In step 932, an address is sampled from an adjacent border texture image 2. In step 934, an address is sampled from an adjacent border texture image 4. In step 936, an address is sampled from an adjacent border texture image 3.

[0071] In step 940, texture samples (e.g., texel values) are fetched from memory.

[0072] In step 950, the texture samples are filtered to obtain a resultant texture value associated with a respective fragment of a graphics primitive. In step 960, the resultant texture value is combined with an interpolated color value to add texture detail to a final image for display or animation.

[0073] For convenience, FIG. 9 is described with respect to the example of three adjacent border textures as in FIG. 8B; however, this is not intended to limit the present invention. One or more adjacent border textures can be used as would be apparent to a person skilled in the art given this description. FIG. 9 is one implementation and is not intended to limit the present invention.

[0074] More Example Implementations

[0075] In one example, the texture sizes internal formats and other details of the original images are the same and the texture environment under these circumstances is the same for all images in the database and for all border images for a tile. The texture filtering for the fragments which fall on the boundary between adjacent images sample multiple texture images. Such fragments on the boundary will fetch texture sample values from multiple texture objects. Hardware implementations (including programmable hardware) can be used. One example of hardware which can be used is hardware which supports cube mapping and has an existing filtering capability which is flexible enough to support the present invention, as described herein. Such cube mapping hardware is suited to be adapted for an implementation of the present invention due to the extant requirement to filter similar situations at cube face boundaries.

[0076] The binding of a texture object can precipitate the binding of all adjacent texture objects. In this way, a texture object which needed to be addressed is resident and ready to use. This is not considered to be an onerous requirement since one reason for the extension of the present invention is the real-time roaming of large contiguous texture spaces while keeping the relevant useful texture resident. Any requisite adjacent textures should already be resident in texture memory if paging has been managed correctly by the graphics application.

[0077] In one example, a series of adjacent border texture images are not recursively applied, only those images immediately adjacent to the bound texture are applied. Although those other images may have adjacent texture borders themselves, they would only be used when they were the bound.

[0078] In another example, a series of adjacent images are recursively applied, and not only those images immediately adjacent to the bound texture.

[0079] Multitexture Approach

[0080] In another embodiment, the present invention uses multitexture units, texture matrices and black border colors at the expense of the availability of those units and performance impact where those units are being clamped and the additional cost of sending multiple texture coordinates. In one example implementation, four texture units are used in a multiple texture graphics implementation. Functional support for black border colors is also used. FIG. 10 shows an example of the primitive of FIG. 7 processed according to a multiple texturing embodiment of the present invention. The primitive with black border color produces an image with texture only where coordinates fall between 0.0 and 1.0.

[0081] Using a multitexture implementation, each texture unit supplies the bound texture for four quadrants in a quad of texture tiles. Each individual tile is clamped with correct filtering to a black border and the resulting texture images are summed. For example, in an OPENGL implementation the summing is carried out with a GL_ADD texture environment. FIG. 11 shows how multitexture units (which apply several textures to a single primitive) can be used to carry out the present invention. A texture unit 0 with image 1 is added through three adds (gl_add) to texture unit 1 with texture image 2, to a texture unit 2 with an image 3, and to a texture unit 3 with image 4 as shown in FIG. 11. Texture matrix operations apply the s and t transformations (s=s+1.0 and t=t+1.0) where appropriate. The result of the summed texture results are modulated with the interpolated lighting result using extensions for the more flexible combination of texture environments with interpolated color. Thus, it can be seen that the embodiment in FIGS. 10 and 11 is basically implementing the routine of FIG. 9 by using multitexture units and additive texture environments to sample from the base image and adjacent border texture images and to fetch the appropriate samples from memory. The fetched samples are combined pre-filtered against black. The black borders and texture matrices implement the evaluation tests.

[0082] For this to be most effective, in one example, the performance of the multiple texturing units while clamped to a black border are close to free due to the lack of memory access.

[0083] Example Environment

[0084] The present invention is described with reference to example computer graphics environments not intended to limit the present invention (FIG. 13). The present invention (including one or more steps of routine 900 as described above) can be implemented in software, firmware, hardware, or in any combination thereof. These examples are illustrative and not intended to limit the present invention.

[0085] FIG. 13 is a diagram that shows different layers of an architecture 1300 related to graphics processing in which the present invention can be implemented. Architecture 1300 includes one or more layers 1310-1340. As would be apparent to a person skilled in the art given this description, the present invention can be implemented in any one of layers 1310-1340, or in any combination of layers 1310-1340. Layer 1310 represents an application program. Layer 1320 represents a 3D graphics tool kit. For example, an object-oriented 3D graphics toolkit, such as, OPEN INVENTOR available from Silicon Graphics, Inc.

[0086] Layer 1330 represents a graphics application programming interface (graphics API) and/or other system support (such as, operating system and windowing system). OPENGL is an example graphics API. In one implementation the present invention can be implemented in OPENGL.

[0087] Layer 1340 represents hardware, including graphics hardware. Graphics hardware 1340 can be any graphics pipeline or system including, but not limited to, a computer graphics processor (single chip or multiple chips), high-end to low-end graphics workstation, gaming platform, system and console, network architecture (e.g., client/server, local, intermediate or wide area network), and virtual machine (e.g., a Java-created application). For example, graphics hardware can include but is not limited to a graphics engine sold by Silicon Graphics or NVIDIA Corporation, Santa Clara, Calif.

[0088] The present invention is described in terms of this example computer graphics system environment. However, given the description herein, it would be readily apparent to one skilled in the art how to implement the present invention in any computer graphics application, application programming interface (including, but not limited to, an OPENGL graphics API architecture), platform, or system including, but not limited to, a computer graphics processor (single chip or multiple chips), high-end to low-end graphics workstation, gaming platform, system and console, network architecture (e.g., client/server, local, intermediate or wide area network), and virtual machine (e.g., a Java-created application).

[0089] Description in these terms is provided for convenience only. It is not intended that the invention be limited to application in this example environment. In fact, after reading the following description, it will become apparent to a person skilled in the relevant art how to implement the invention in alternative environments.

[0090] Note an OPENGL graphics API architecture does not require use of the present invention. In other words, an OPENGL graphics API architecture can operate without using the advantages of the present invention as described herein.

[0091] Conclusion

[0092] While various embodiments of the present invention have been described above, it should be understood that they have been presented by way of example only, and not limitation. It will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the spirit and scope of the invention as defined in the appended claims. Thus, the breadth and scope of the present invention should not be limited by any of the above-described exemplary embodiments, but should be defined only in accordance with the following claims and their equivalents.