WO2000041137A1 - Method, system, and computer program product for general clip-mapping - Google Patents

Abstract

The present invention provides general clip-mapping. A method, system, and computer program product are provided for efficiently storing and addressing a subset or clip-map of an arbitrarily large texture in a fixed size of hardware texture memory. A clip-map can be stored and addressed in a fixed texture memory. Addresses in texture space are transformed so that the area of interest (that is, the general clip-map) is in the most accurate part of a floating point range (0.0 to 1.0). Each clip-map tile is associated with an exponent value. The scan converter includes a clip-map texture coordinate and exponent calculator that determines an exponent. The exponent is a function of a magnitude of at least one floating point texture coordinate correponding to a vertex of a primitive. The clip-map level of detail LOD calculator calculates a clip-map level of detail based on the exponent calculated by the clip-map texture coordinate and exponent calculator.

Description

Method, System, and Computer Program Product for General Clip-Mapping

Background of the Invention

Field of the Invention

The present invention pertains to the field of computer graphics. More particularly, the present invention relates to addressing texture.

Related Art

Texture is increasingly applied in a variety of computer graphics images and applications. Low-end and high-end graphics platforms use texture to generate realistic images and special effects. Demand is high for a wide range of complex texture from satellite images to medical data.

The size of texture databases is rapidly increasing. For example, a texture database that stores a satellite image covering the entire world at one meter resolution is available. Such a large image corresponds to a texture size of approximately 40,000,000 x 20,000,000 texels or 160 Tetrabytes (TBytes) of texture data.

Users like to fly over or visualize aspects of texture data in real-time. One practical goal of a real-time graphics system is to render a new frame without noticeable delay, that is, within about 50 milliseconds or less. Longer delays may be tolerated of course depending upon a user preference. A large texture, however, presents difficulties which can limit or prevent real time rendering of a textured image. A large texture can easily exceed available texture memory.

As a result, a large texture may have to be stored in a larger texture database or other storage site which cannot be accessed as quickly by a graphics or texture processor as texture memory. -?-

Texture size is further exacerbated in the case of mip-mapping where multiple copies of a textured image at different resolutions must also be stored. A mip-map consists of a texture pattern pre-filtered at progressively lower or coarser resolutions and stored in varying levels of detail (LOD) maps. See, e.g., the explanation of conventional texture MlP-mapping in Foley et al., Computer

Graphics Principles and Practice, Second Edition, Addison- Wesley Publishing Company, Reading, Massachusetts (1990), pages 742-43 and 826-828 (incorporated by reference herein). The benefit of MlP-mapping is that filtering is only performed once on texel data when the MlP-map is initially created and stored in LOD maps. Thereafter, texels having a dimension commensurate with pixel size are obtained by selecting the closest LOD map having an appropriate resolution. By obtaining texels from the pre-filtered LOD maps, only relatively cheap filtering, such as, trilinear filtering is performed during run-time.

One significant drawback to conventional MlP-mapping, however, is the amount of memory consumed by the various texture LOD maps. Main memory in the form of a dynamic random access memory (DRAM) or a static random access memory (SRAM) is an expensive and inefficient site for a large texture

MlP-map. Each additional level of detail map at a higher level of detail requires four times more memory. For example, a 16x16 texture array having 256 texture picture elements (texels), is four times bigger than an 8x8 texture array which has

64 texels. To put this increase in perspective, a texture MlP-map having six extra (finer) levels of detail requires over 4,096 times more memory than the original texture map at the finest resolution. Implementing large texture MIP- maps quickly becomes an expensive luxury. In addition, for large texture MIP- maps, many portions of the stored MlP-map are not used in a display image.

Memory costs become especially prohibitive in photographic texture applications where the source texture, such as. satellite data or aerial photographs, occupy a large storage area. Creating a pre-filtered MlP-map representation of such source texture data further increases memory consumption. This problem is further exacerbated by the fact that in order to increase the speed at which images are rendered for display, many of the high-performance computer systems contain multiple processors. A parallel, multiple processor architecture typically stores individual copies of the entire MlP-map in each processor memory.

There is also a need to maintain real-time display speeds even when navigating through displays drawn from large texture maps. For example, flight simulations must still be performed in real-time even when complex and voluminous source data such as satellite images of the earth or moon, are used to form large texture motifs.

Clip-map techniques have been developed to solve the above problems. A clip-map is a partial mip-map in which each level has been clipped to a specified maximum size. The standard, full size mip-map is stored in a host memory (e.g. a database). The clip-map, representing a subset of the complete mip-map, is stored in a texture memory which can be accessed quicker than the host memory or database. See, U.S. Patent No. 5,760.783 issued to Migdal et al., and "The Clipmap: A Virtual Mip-Map," Computer Graphics Proceedings, Annual Conference Series, 1998, by Migdal et al. , pp.151-158 (both of which are incorporated herein by reference). Prior to the present invention, however, clip-mapping was limited to a special case where a texture size could not exceed the addressable range of texture memory without incurring a significant penalty. In other words, special- case clip-mapping was limited to a hardware scheme where a texture map could not exceed a certain fixed size. The texture map size limit was based on the size of the texture scan conversion coordinate generation and addressing hardware.

The problem of texture databases that are larger than the available texture memory has been with us a long time. A past solution was to break up a texture into smaller titles such that a reasonable number of tiles would fit into the available texture memory. The tiles required for a certain scene would be brought in a level-of-detail appropriate to the position of the associated terrain tile. The disadvantage of this approach is that a large number of textures must be managed instead of one logical texture. Since the texture is broken up into numerous tiles, terrain also must be sliced up into the same tiles to ensure that only one texture per polygon is accessed. This tiling scheme requires complex management and overhead.

What is needed is an efficient method and system for storing and addressing a subset or clip-map of an arbitrarily large texture in a fixed size of hardware texture memory. A clip-map needs to be stored and addressed in a fixed texture memory even when the clip-map is drawn from a larger texture whose address range exceeds the addressing range of the texturing hardware.

Summary of the Invention

The present invention provides general clip-mapping. A method, system, and computer program product are provided for efficiently storing and addressing a subset or clip-map of an arbitrarily large texture in a fixed size of hardware texture memory. A clip-map can be stored and addressed in a fixed texture memory even when the clip-map is drawn from a larger texture whose address range exceeds the addressing range of the texturing hardware.

According to the present invention, addresses in texture space are transformed so that the area of interest (that is, the general clip-map) is in the most accurate part of a floating point range (0.0 to 1.0). Exponents are determined and tracked during rasterization. Each clip-map tile is associated with an exponent value. Scan conversion and texture processing are then performed taking into account the exponent.

In one embodiment, a method for mapping texture from a general clip- map stored in a texture memory is provided. An exponent is determined. The exponent is a function of a magnitude of at least one floating point texture coordinate corresponding to a vertex of a primitive. Fixed point texture coordinates at vertices of a primitive are calculated based on the exponent. Fixed point texture coordinates in an iterated space at a pixel are then evaluated.

According to a further feature, a clip-map level of detail based on the exponent is also calculated. The iterated space texture coordinates are converted to clip-map tile specific coordinates at a clip-map tile in the general clip-map.

The clip-map tile has a level of detail corresponding to the calculated clip-map level of detail. Texel data at the clip-map tile specific coordinates can then be mapped to an object. Image data representative of the texture mapped object is stored in a frame buffer for display. In one example, a clip-map level of detail is calculated in a series of operations. First, an initial mip-map level of detail (LOD) is calculated. The initial LOD is modified by the exponent. An available level of detail is then calculated based on the modified initial LOD. Finally, the clip-map level of detail is calculated based on the available level of detail and level of detail (LOD). A pre-processing or real-time operation is used to store the general clip- map in a texture memory and to transform addresses of data in the general clip- map to a floating point range that defines a base area.

In one example implementation a graphics system is provided that supports general clip-mapping. The graphics system includes a texture memory that stores a general clip-map, a scan converter, a clip-map LOD calculator, and a texture engine. The texture engine is coupled between the texture memory and the scan converter. The scan converter includes a clip-map texture coordinate and exponent calculator that determines an exponent. The exponent is a function of a magnitude of at least one floating point texture coordinate corresponding to a vertex of a primitive. The texture coordinate and exponent calculator also calculates fixed point texture coordinates at vertices of a primitive based on the determined exponent. The scan converter further evaluates fixed point texture coordinates in an iterated space at a pixel corresponding to the fixed point texture coordinates calculated by the clip-map texture coordinate and exponent calculator. According to a further feature, a clip-map level of detail LOD calculator is coupled between the scan converter and the texture engine. The clip-map level of detail LOD calculator calculates a clip-map level of detail (LOD_clip) based on the exponent calculated by the clip-map texture coordinate and exponent calculator. The texture engine converts the iterated space texture coordinates output by the scan converter to clip-map tile specific coordinates at a clip-map tile in the general clip-map. The clip-map tile has a level of detail corresponding to the clip-map level of detail output by the clip-map level of detail calculator.

The texture engine maps texel data at the clip-map tile specific coordinates to an object. An image data representative of the texture mapped object can be stored in a frame buffer for display.

The graphics system can also include a texture database. The texture memory has a size smaller than an addressable range of the texture database. A preprocessor is coupled between the texture database and the texture memory. The preprocessor transfers the general clip-map from the texture database to the texture memory and transforms addresses of data in the general clip-map to a floating point range that defines a base area equal to or smaller than the size of the texture memory.

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

Brief Description of the Figures

The accompanying drawings, which are incorporated herein and form a 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: FIG. 1A is diagram that shows an example of a 32K X 32K texture represented as a 2K X 2K clip-map.

FIG. IB is a view of the top levels of the clip-map of FIG. 1A.

FIG. 2 is a diagram that shows updating of a clip-map in response to movement of a viewpoint.

FIG. 3 is a diagram that shows the relationship between a large texture database and a general clip-map according to the present invention.

FIG. 4 is a top view of the general clip-map shown in FIG. 3.

FIG. 5 A is a diagram that illustrates transformation of addressing in the large database to floating point range at a base area of the general clip-map.

FIG. 5B is a diagram of a primitive transformed to addressable base area of FIG. 5 A according to an embodiment of the present invention.

FIG. 5C is a diagram of an example database translation according to an embodiment of the present invention. FIGs. 6A and 6B are a flowchart of a routine for general clip-mapping according to an embodiment of the present invention.

FIG. 7 is a block diagram of a raster subsystem for performing general clip-mapping according to an example of the present invention.

The present invention will now be described with reference to the accompanying drawings. 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. Detailed Description of the Preferred Embodiments

TABLE OF CONTENTS

I. Overview and Discussion

II. Terminology

III. Special Clip-Mapping

A. Generation of the Clip-Map

B. Updating the Clip-Map

C. Special Clip-Map Hardware Algorithm

IV. General Clip-Mapping 1. Transforming the Data to Be Centered upon 0.0 to

1.0 Range That Defines the Base 64k X 64k Area

2. Determine Exponent

3. Evaluate Texture Coordinates at a Pixel

4. Calculation of Mip-Map Level of Detail 5. Calculation of LOD Available

6. Calculation of Clip-map LOD

7. Convert the Texture Coordinates to Tile Specific Coordinates

8. 3D Clip-Mapping 9. Example Environment

10. Example Implementation

Conclusion

/. Overview and Discussion

The present invention provides general clip-mapping. Texture address and size limitations in special clip-mapping are overcome. In the following description, a terminology section is provided. An example of special clip- mapping is discussed. In particular, an example hardware implementation for special clip-mapping is described. This example implementation for special clip- mapping processes texture smaller than a fixed texture size. The fixed texture size is further limited to the size of addressable texture space supported by texture memory. Next, general clip-mapping according to the present invention is described. General clip-mapping allows a clip-map to be generated and texture processed from any large texture in a general space. Textures larger than the fixed texture addressable space of the texture memory can be used. In one embodiment, a general space is an arbitrarily large address space with a well defined origin at 0.0.

II. Terminology

To more clearly delineate the present invention, an effort is made throughout the specification to adhere to the following term definitions as consistently as possible. The term "texture map" refers to source data representing a particular texture motif at its highest resolution. A "texture MlP-map" and equivalents thereof such as a "MlP-map of texel data" are used broadly to refer to any multi- resolution texture map, including but not limited to, a conventional multum in parvo MlP-map representation of a texture map at successive multiple levels of details (LOD).

"Clip-map" refers to a subset of a texture MlP-map. A clip-map is a multi- resolution map made up of a series of tiles wherein at least some of the tiles JO-

represent smaller, selected portions of different levels of detail in a MlP-map. One-dimensional or multi-dimensional texture data can be used. For example, when two-dimensional texture data sets are used, clip-map tiles can be two- dimensional texel arrays. When three-dimensional texture data sets are used, these tiles can be three-dimensional texel arrays, i.e. cubes. In general, the term

"clip-map tile" refers to any region of a clip-map level, and is not limited to a particular dimension or shape or to a particular memory storage arrangement.

In one example, a clip-map (also called a general clip-map or GCM when general space is involved) has a stack part. The stack part consists of one or more finest levels of a clip-map. These levels are all subsets of the same levels of a root mip-map. In one example, the levels are square tiles.

In another embodiment, a clip-map has a stack part and a pyramidal part. The pyramidal part consists of the one or more coarsest levels of a clip-map. These levels are exactly the same as corresponding conventional mip-map levels at the same resolutions.

"Special space" refers to a texture address space that restricts special clip- mapping and other texture processing to the addressability of a machine. In one example, the origin of special space is at the lower left hand corner of the maximum accuracy region of addressability. "General space" refers to an arbitrarily large address space used in general clip-mapping according to the present invention. In one example, the origin of general space is well-defined at 0.0.

Finally, example texel array dimensions are sometimes given in convenient 1 k x 1 k, 2k x 2k, etc., shorthand notation in this description. In actual implementations using digital processing, Ik equals 1,024, 2k equals 2,048, etc.

HI. Special Clip-Mapping

One goal is to fly over or access a single texture of arbitrary size at realtime rates. For large textures, it would be very expensive, if not impossible, to implement such a scheme in hardware according to special clip-mapping. The texture addressing hardware would have to be large enough to be able to address the entire single texture of arbitrary size. Accordingly, this example is restricted to a hardware scheme that can handle a fixed size texture map. In special clip-mapping, the basic idea is to have a normal mip-map stored in host memory, but to only store a subset of the mip-map in texture memory. This subset covers all the texture that is required to render a particular frame. An example of generating a clip-map and updating a clip-map in special space is described below. The algorithm described in this section is basically the one implemented on Infinite Reality. See, "InfiniteReality: A Real-Time Graphics

System," Computer Graphics Proceedings, Annual Conference Series, 1997 ', pp. 293-302 (incorporated herein by reference). Generating a clip-map and updating a clip-map are further described in U.S. Patent No. 5,760,783 issued to Migdal et al., and "The Clipmap: A Virtual Mip-MapJ Computer Graphics Proceedings, Annual Conference Series, 1998, by Migdal et-7/., ppJ51-158 (both of which are incorporated herein by reference).

A. Generation of the Clip-Map

As mentioned above, in one example implementation a clip-map is a subset of a normal mip-map. To generate a clip-map, for each level of the mip- map, starting at the finest level, a user chooses a region surrounding the point of interest in the texture to load into the clip-map. The size of this region is a fixed number of texels that is user programmable (typical sizes are 512x512, 1024x1024, and 2048x2048 texels). The size of this region is constant in the number of texels stored per level (also called tiles). This means that each subsequently coarser level-of-detail holds four times the area of the immediately finer level. Eventually the clip-map tile size matches the mip-map level size. At this point, and for all coarser levels, the clip-map is stored exactly like a mip-map. FIG. 1 A shows an example of a 32K X 32K texture 100 represented as a 2K X 2K clip-map 120. Clip-map 120 includes two parts: a clip-map stack 122 and a clip-map pyramid 124. As shown in FIG. 1 A, clip-map stack 122 includes four levels of constant size tiles (2K X 2K) in texture memory. Each of these four tiles covers a progressively larger portion of a source image mip-map level and at progressively coarser resolution. Clip-map pyramid 124 includes 12 levels corresponding to the same 12 levels of a normal mip-map.

Clip-map stack 122, also called the stack part, has tiles which are the finest resolution levels of clip-map 120. These tiles are all subsets of corresponding levels in a normal mip-map representation of texture 100. Tiles can be square to make addressing simpler but other tile shapes can be used. Clip- map pyramid 124, also called a pyramid part, includes the coarsest several levels of a clip-map.

FIG. IB is a view of the top levels of clip-map 120 of FIG. 1A as viewed along a viewpoint extending down to a clip-map center in the center of the finest resolution tile in clip-map stack 122. For clarity, only three tiles of clip-map stack 122 and one tile of clip-map stack 124 are shown in FIG. IB.

In one example implementation, the clip-map is generated from the mip- map data using a restrictive set of rules which define the relative positions of the clip-map levels. The reason for these rules is to make the hardware implementation as simple as possible, as well as to limit the number of variables (hardware registers) needed to describe a clip-map. These restrictions can be relaxed of course depending upon a particular implementation and available hardware (or software) resources. The first step is to choose the center of the stack part of the clip map, designed (s_ccnlre, t_cenlre). These are chosen to integer texel accuracy. The finest level tile is made up of the subset of the mip-map data equally surrounding the center on all sides. All the other tiles in the stack part of the clip-map are generated by taking the finest level's center position, shifting it down the appropriate number of times, and equally surrounding the center on all sides with data from that level. The above operations can be expressed in equations (l)-(6) as follows: centre n = V centre » LOD (1) centre centre » LOD (2)

C = c tile„ left_n °centre„ (3)

2 tile.

^S right,, ^S centre,, ^{+ '} - 1 (4)

2 tile

¹ b honttttonmm,, '' c ret>n rtttrreo, _ >■ J

? tile„ t top„ = t cent ,re„ + — y ^ - 1 (6)

The pyramidal part of the clip-map is simply copied from the root mip- map, that is, the portion of the normal mip-map having level of detail (LOD) maps corresponding to the clip-map pyramidal part. The point where the clip- map switches from the stack part to the pyramidal part is a function of the original mip-map size and the selected tile size for the stack part of the clip-map.

B. Updating the Clip-Map

The clip-map generated above is useful when the eye is looking near the center of the stack (although a correct image will be generated no matter where the eye looks into the texture, it will just not use the finest levels of detail of the data available in the original mip-map). In many applications the eyepoint is continually moving over the texture. The clip-map needs to be updated so that the center of the stack more or less corresponds to the place being observed from the eyepoint. It is far too expensive (and unnecessary) to completely replace the stack levels with new data centered on the new viewpoint. Instead the levels can be incrementally updated with the new texture information as it becomes necessary. The idea is to overwrite the new information over the old texture information that is no longer needed. Updating is needed in both the s and t direction simultaneously. FIG. 2 illustrates how this works.

The top row of FIG. 2 shows a situation where the center of view has moved to the right. New texture information appears to the right (shown crosshatched), while old texture information that is no longer required is on the left (shown dotted). The majority of the texture information (shown with diagonal lines) is valid for both the old and new viewpoints, there is no need to reload this information. The solution used to be efficient is to keep the information that does not need to be updated in place and load the new texture over the old texture.

The bottom row of FIG. 2 shows the same set of steps where a displacement of the viewpoint occurs in both s and t texture coordinates. In this case, looking at FIG.2 the viewpoint moves to the right and up. New texture data is shown in three different areas to make it clear where it is stored in texture memory over the old texture. These areas of new texture are added to the top, to the top right corner, and to the right hand side of the tile.

The updated texture clip-map tiles need to be addressed properly. In this example, to do this requires only two numbers, an s offset and t offset designated (S _ct, t_φel). The actual texture address for a clip-map tile is generated from the tile specific address as follows:

^{5 = S}tile ^{+ S} offset (7) = tfde + * offset (8)

This calculation is done for clip-map tile levels in the stack part not for levels that are in the pyramidal part of the clip-map.

In order to avoid having two offset registers per tile in the stack part of the clip-map, the same rigid rules that apply to clip-map generation can be forced to the definition of offsets. This means that an offset in the finest level exactly determines the offset in all the other levels of the stack part of the clip-map. For example, given an offset of 8 in s in the finest level of the clip-map, the offset will be 4 in the next coarser level, 2 in the level coarser than that, 1 in the level coarsest than that and 0 for all the other levels. If the initial offset were 7, the other offsets would be 3 , 1 , and 0. It is not necessary to update the pyramidal part of the clip-map, since each level (LOD) includes the entire texture. The need for a separate set of offset registers can be eliminated, if the offsets are restricted to being tied to the clip-map origin position. This optimization is described further in the general clip-mapping section below.

C. Special Clip-Map Hardware Algorithm

One example of a clip-map hardware implementation has two basic responsibilities: (1) determine the appropriate clip-map level to be used, and (2) generate the addressing information for these levels. These responsibilities are carried out in the following example clip-map algorithm described below with respect to seven steps. Functionality for this example clip-map algorithm can be implemented in hardware for fast processing.

1. Determine the s and t coordinates for the current pixel. This is done in exactly the same way as a normal mip-map of the size of the root mip- map of the clip-map. 2. Calculate the level-of-detail (LOD_mφ) of the texture for this current pixel. This is done exactly the same as for a normal mip-map. The LOD algorithm takes into account the effects of anisotropic filtering (if it is turned on). If it is determined that the LOD is completely in the pyramidal part of the clip- map, steps 3, 4, and 5 are skipped. If the finer of the two required clip-map levels is in the stack part and the coarser is in the pyramidal part, steps 3, 4, and 5 are only done for the finer level. In this example, the finest level is defined to be LOD 0. 3. Calculate the finest level of detail available (LOD_available) for the texture coordinates generated in Step 1. This needs to be done because it is possible that the LOD requested in Step 2 does not exist in the clip-map for the texture coordinates generated in Step 1. This calculation is not affected by anisotropic filtering.

This determination is done simply by determining the distances in s and t from the stack parts center (s_cenlre, t_cenlre) and the sample point (s, t). The actual samples pulled out of texture memory are taken into account in this calculation. The largest of the two distances can be used to determine the initial LOD_available. The above set as equations:

^Sdist ^— centre (9)

dist centre (10)

^maXdist = ^maX(^Sώst ■ t, dist , (I D

( tilesize

LOD, available log₂(max_ώst) - log₂ LOD g. uard (12)

The above equations assume tiles in the stack part of the clip-map are square. Different tile shapes would require adjustments to the equations as would be apparent to a person skilled in the art given this description. Also the above equations are conservative in the determination of maximum distance by one texel on the left and lower edges of the tile.

This calculation can also be adjusted to switch to a coarser level of detail, even though the tile for a given LOD is strictly available at the given sample position. This adjustment is necessary because as the data is being downloaded dynamically into the edges of the tiles in response to the movement of the stack parts centre, the data along the edges may not be completely updated before it is requested (unless of course a user is willing to incur a performance penalty to guarantee that the data update is complete). Instead a guard band of several texels (LOD_guard) is defined. The guard band is programmable. If the samples fall into this guard band region, LOD_avaιlable is forced to a coarser level. This makes the tiles slightly smaller in effect. Since the value of the guard parameter can be as large as the tile size, it can be used to force the LOD to go down to the pyramidal part of the clip-map, in the extreme. This is useful for times when a user wishes to move very quickly through the database (like in a god's eye view) and valid data cannot be kept in the stack part of the clip-map.

5. Then the two calculated LODs (LODmip and LODavailable) are compared. The coarser one is chosen as the actual clip-map LOD (LOD^_p). 6. Convert the s and t texture, coordinates into tile specific texture coordinates.

First determine the fine and coarse texture coordinates for a normal mip- map. s_βne = {s » LOD_clφ) - 0.5 (13)

tfi_ne ={t» LOD_dψ)-05 (14)

S_co∞e = {s » {L D_clψ + 7))-0.5 (15)

tco_arse = (t » (L D_clφ + 7)1 - 0.5 (16)

Then determine the tile offsets for the fine and coarse levels-of-detail.

^lUes e

^Slιleoffset_f ~ [^S centre >> LOD_clφ (17) 2 ^tUesιze deoffset_j ^~ centre ^>> *-OD_cllp (18)

^offse_t. = {^centre » (LOD_elψ + l)) - ^ - (19)

t_lileoffset, = ^centre » (lODj,. + l)) - ^*- ₍₂₀) Then calculate the texture download offsets.

^S dwnldoffset _f ^{= S} dwnldoffset ^{> >} LUD _hp (21 )

¹ dwnldoffset _f ^{= l} dwnldoffset ^>> LOD_clip (22)

^Sdwnldoffset_c ^{= S}dwnldoffset >> + 1) (23)

^t dvnldoffset _c ~ * dwnldoffset ^>>

+ 1) (24)

Then we apply the tile offsets and the texture download offsets to the initial clip-map coordinates to get the final texture coordinates.

^Sclip_f = (^S ~ ^Stileoffset_f + ^do_Wnldoffset_c ) % tU^βSlZe (25)

^tcli_P/ = (^{f ~ t}tileoffset_f ^{+ t} ownldoffset _c ) ^% tUesiz^β (26)

_clipc = {s - s_tileoffselc + s_{downldoffsetc} ) % tilesize (27)

tclip_c = it - ttileoffset ^{+ t} downldoffset _c ) ^% tU^βSiZ^β (28)

7. The two sets of final texture coordinates (fine and coarse) in equations (25) to (28) are then used to generate a filtered textured value for the pixel as is done for a conventional mip-map.

IV. General Clip-Mapping

A more general form of clip-mapping than supported by the above special clip-mapping is needed. Databases have texture that can easily exceed the size of 64k x 64k that can be supported by graphics hardware, especially texturing hardware. A method and system for general clip-mapping is needed which can make use of the special case supported by the hardware that can support a general case where the database is unlimited.

General clip-mapping has many advantages and features. General clip- mapping provides the ability to roam and render a 64M x 64M region of an infinitely large database. Users also can render scenes that cover more than the 64k x 64k region that is addressable by the texturing hardware. In one practical example, levels align properly when a user starts to move around a large or nearly infinite database. In another example, the general clip-mapping is compatible with the implementation of special clip-mapping on an Infinite Reality machine sold by Silicon Graphics, Inc. (SGI).

General clip-mapping according to one embodiment of the present invention will be described with reference to FIGs. 3 to 7. According to the present invention, addresses in texture space are transformed so that the area of interest (that is, the general clip-map) is in the most accurate part of a floating point range (0.0 to 1.0). Exponents are determined and tracked during rasterization. Each clip-map tile is associated with an exponent value. Scan conversion and texture processing are then performed taking into account the exponent. One embodiment for general clip-mapping is described with respect to an example routine 600 and an example raster subsystem 700 that carries out routine

600 (FIGs. 6A, 6B, and 7). In describing the operational steps of routine 600 reference is also made to FIGs. 3, 4, and 5A-5C. FIG. 3 shows a diagram of the relationship between a large database 300 and a general clip-map 310. FIG. 4 is a top view of general clip-map 310 showing the top-most and finest resolution clip-map tiles 400, 410, and 420 with their respective exponent values 0, 1, and

2. FIG. 5A is a diagram that illustrates transformation of addressing from an arbitrarily large range 0 to infinity-n in general space 502 of large database 300 to a floating point range (0.0 to 1.0) at a base area 500 (that covers at least the 64K x 64K tile 400) of general clip-map 310. FIG. 5B is a diagram of a primitive transformed to addressable base area 500. FIG. 5C is a diagram of an example texture database address translation.

Routine for general clip-mapping 600 includes steps 610-694. Graphics system 700 includes database 300, host processor 702, geometry engine 704, preprocessor 710, scan converter 720, LOD calculator 730, texture engine 740, texture memory 750, memory access controller (MAC) 754, texture filter 760, frame buffer 770, and display 780.

In step 610, general clip-map 310 is first generated and stored in texture memory 750. For example, general clip-map 310 can be generated from texture in database 300 as described above with respect to special clip-mapping. GCM

310 can then be stored in texture memory 750. Ciip-map 310 can be generated by preprocessor 710 (or by host processor 702 or texture engine 740) in a preprocessing stage. Data that the user would like to see is then already stored in clip-map 310 in texture memory 750. Alternatively, step 610 can be carried out on the fly by host processor 702, texture engine 740. or by a separate functional unit (not shown).

As shown in FIGs 3 and 4, the entire stack part of clip map 310 is addressable with general clip-mapping. Thus, the addressable data in general clip-map stack 310 can include data which is unaddressable with special clip- mapping. For comparison, the areas of tiles shown with solid lines correspond to the limited area addressable by a single special clip-map. The remaining area of general clip-map 310 shown with dotted lines is only addressable using general clip-mapping. For example, in a 17 level stack (corresponding to a 64k x 64k finest LOD) the coarsest LOD in the stack part (there is no pyramidal part in this case) represents a maximum of 64M x 64M of texture (assuming a 1 k x 1 K clip- map tile size).

In one "stack only" example of the present invention, the stack 310 can include all of the areas of tiles shown in solid lines and dotted lines in FIG. 3 (that is, the entire large rectangle in stack 310) as described above. In another "with pyramidal part" example of the present invention, the stack 310 can include a stack part and a pyramidal part. In general, the stack part can be one or more tiles in stack 310. A user can set the level or tile at which the pyramidal part begins depending upon a user's needs. For example, as shown in FIG. 3, a GCM pyramidal part 316 can begin at a tile 430 (coarser than tiles 400-420 described below) and continue for all coarser tiles. The pyramidal part can help a user reduce storage requirements for the GCM stack 310. The stack part then includes all of the finer tiles (400-420 and up) in stack 310. Note all of the data in tiles 400 - 420 (both the solid and dotted lines) is included in the GCM stack part and is addressable in under general clip-mapping. For comparison, a special clip- mapping pyramidal part 312 is shown where the pyramidal part begins at tile 400. Only the area in solid lines is addressable under special clip-mapping.

In sum, the problem is how to address all of the data in a GCM stack with or without a pyramidal part. This data can include data outside the region addressable by the special clip-mapping (i.e., texturing) hardware. The first step in the solution is to define the floating point coordinates that determine the mapping of texture onto geometry. Accuracy is sacrificed if the lower left hand corner of database 300 is defined as (0,0) because of the nature of floating point calculations. Accuracy would decrease as the rendered region (clip-map 310) moved from the origin.

1. Transforming the Data to Be Centered upon 0.0 to 1.0

Range That Defines the Base 64 k X 64k Area

According to one embodiment of the present invention, in step 620, addresses of data in clipmap 310 is transformed to be centered upon a floating point range that defines a base area 500. In the example shown in FIGs. 4 and

5 A, a moveable addressable region (the 64k x 64k region 400, 500) is defined as having its lower left corner at (0,0) and its upper right corner at (1 ,1) within a general space 502. Tile square 400, 500 represents the location of the base addressable region. FIG. 5C shows an example transformation according to step 610 implemented as a database address translation and applied to the vertices of triangle 550. In effect, this database addresses translation keeps the highest accuracy part of the floating point range over the region that most needs it. In other words, step 610 is needed to move the area of interest 500 (as well as the area with the highest required accuracy) into the most accurate part of the floating point range (0.0 to 1.0) in general space 502. As shown in the example of FIG. 5C, after the database address translation, triangle 550 is addressed in an address space with a new origin closer to triangle 550.

The region outside the base addressable region can be defined using what are thought of as being wrap bits in OPENGL. The results of this scheme are illustrated in FIG. 5B. The solid and dotted squares 500-520 correspond to the squares 400-420 of FIG. 4. This calculation in step 620, is done by a user or a graphic application programming interface or machine, such as, PERFORMER sold by SGI. Graphics systems which accept texture coordinates as floating point values, such as, a system supporting OPENGL, can send floating point values directly to a texture coordinate calculator chip. Wrap bits need to be interpreted to refer to the addressable region outside the base. For example, changes can made to OPENGL to allow for this alternate interpretation of the wrap bits. Since the calculation of texture coordinates in scan conversion hardware

720 is done in fixed point and this method requires floating point, a fast approximation is used in the rendering hardware to make this work. The approximation is based on the fact that the further one gets away from the 64k x

64k central region 500, the less accuracy is needed. There are two reasons for this: 1) assuming a proper positioning of the clip-map center things far away will be at a coarse LOD, and 2) this data is available at a coarse LOD (relative to the data in the 64k x 64k region.) The approximation used in the present invention amounts to simulating floating point by using fixed point and managing an exponent. 2. Determine Exponent

In step 630, an exponent (exp) is determined. The floating point coordinates translated in step 620 are sent to a scan converter 720. Scan converter 720 generates texture coordinates at pixel centres. Its hardware operates in fixed point, and gives full accuracy only in a base address range (e.g., a range of 64k to 64k). Since address ranges outside of 64k x 64k need to be handled, additional steps are performed when transforming the floating point input into a fixed point representation.

In particular, according to the present invention, scan converter 720 includes a texture coordinate and exponent calculator 725. Texture coordinate and exponent calculator 725 examines floating point texture coordinates and takes the largest. For example, six floating point texture coordinates (sOJO, si, tl, s2, t2) define vertices of a triangle in a two-dimensional texture with a texture coordinate space addressed by two coordinates (s, t). Texture coordinate and exponent calculator 725 examines the six floating point texture coordinates and determines a value tex_max equal to the magnitude of the largest texture coordinate as described in the equation (29):

te*m_ax = m^ U ol ' - i l - h U ^ l) (29)

An exponent value (exp) is then determined by taking the base 2 log of tex_max as follows:

exp = log₂( ex_max) (30)

As shown in the example of FIGs. 4 and 5B, if the exp term is 0 this means that drawing is done entirely in the base region 400 and full accuracy is available for rendering calculations. If exp is not zero it means that at least part of the triangle 550 that is being rendered is outside the base region. In this case, the accuracy of this triangle's calculations will be less accurate in bits by the size of the exponent. For example, as shown in FIG. 4, an exponent value equal to one (exp = 1) is calculated for address ranges between 64K x 64K and 128K X 128K the next coarser tile 410 portions of a triangle primitive. An exponent value equal to two (exp = 2) is calculated for address ranges between 128K X 128K and 256K X 256K.

In step 640, fixed point texture coordinates (s_fix._d,t_fi-._ed) are calculated based on the exponent (exp) and texture size. Exp is determined in step 630. Texture size is a variable (s_texsιze , t-_exs,_ze ) defined by the user or set to a default value in scan converter 720. Hardware in scan converter 720 applies the size of the texture to the dimensionless texture coordinates.

fixed ~ mantissa texsize . ( ^J ' J where s_man.₁-_sa represents the value of texture coordinate s shifted right a number of times equal to the value of exp. Similar calculations are made to calculate t_{fi ed}

fixed ^~ mantissa texsize . (->■<-) where t---_an-_ls-a represents the value of texture coordinate t shifted right a number of times equal to the value of exp. These calculations are performed to determine fixed s and t for all three vertices of a triangle primitive.

3. Evaluate Texture Coordinates at a Pixel

In step 650, the fixed point vertices, calculated in step 640, are transformed to fixed point texture coordinates at a pixel center (s,,t,). For example, a barycentric evaluation can be used by scan converter 720 to perform this transformation. Scan converter 720 simply keeps track of the exponent. On a per-pixel basis, scan converter 720 outputs a set of texture coordinates s,t in fixed point (722) and an exponent value (exp) to texture engine 740 and LOD calculator 730. In this way, the fixed texture coordinates are evaluated in a modified special space called iterated space (hence the I subscript) that is the same as in special space except for the shift right described by the exponent term (step 650).

4. Calculation ofMip-Map Level of Detail

In step 660, a mip-map level of detail (LOD_m,_p,_nιt) is calculated. This is done as in a normal mip-map LOD calculation. A level of detail (LOD) is calculated for each pixel (e.g., a pixel, pixel pair, pixel quad, or other pixel-based reference) according to standard LOD calculation techniques based on the pixel dimension and texel dimension.

In step 670, initial mip-map level of detail (LOD---._pιmt) is modified by the exponent to determine a mip-map level of detail (LOD_mιp), as shown below:

LOD min = LOD mwinit , + ex rp (33)

Calculation of LOD Available

In step 680, an available level of detail (LOD_avaιlabIe) is calculated as follows according to the invention:

(*_{cβΛ rø} » exp) - ^; (34)

tdist {t centres » (35)

max^ = max(^ ,t^) (36)

LOD a.vailable log₂(max-te) - (37)

In this example, the above equation is calculated with 10 fractional bits for the log2. The log operations allow the normalized distances at an LOD to be compared. This normalized distance is given by the fractional part of the result of the log operation. The guard term (LOD_guard) specifies a band of one or more texels. This guard term allows a band of texels to be ignored at the edge of the clip-map to allow texture updates on the fly into this space.

In this calculation, the center of the stack is in the center of the general clip-map. This calculation is efficient; however, the present invention is not intended to be limited by this example. Other calculations can be made as would be apparent to a person skilled in the art given this description. For example, a center of a stack can be offset or translated relative to the center of the general clip-map.

6. Calculation of Clip-map LOD

In step 690, the actual clip-map LOD. (LOD_dψ) is calculated by comparing the two LODs (LOD_mip and LOD_avajlab|_e) calculated in steps 680 and 690. The coarser value is chosen as the actual clip-map LOD (LOD_clip).

In the example system of FIG.7, LOD calculator 730 performs each of the steps 660-690. LOD calculator 730 outputs LOD_cljp to texture engine 740.

Convert the Texture Coordinates to Tile Specific Coordinates

In step 692, the texture coordinates in iterated space (s„ t,) are converted to fine and coarse sets of clip-map tile specific coordinates (s_chpf, t_clipf) and (s_clipc, t_clipc). First, the general space texture coordinates (s_g , t_g ) are determined by summing s and t offsets (s_ofrg, t_ofTg) and special space coordinates (s_s,t_s):

^s _. ^{= s}s ^{+ s}off_g (38)

Offsets s_ofTg and t_ofr represent the distance from the original old origin to the current new origin. These offsets can be set by a user or set to a default value. The iterated space texture coordinates s, , t, calculated in step 650 are shifted right by the exponent to obtain special space coordinates (s_s,t_s): s_s = s, « exp (40) t_s = t, « exp (41)

Next general space coordinates are calculated at the fine and coarse clip- map LODs (s_clιpf, t_c,,_pf, s_clιpc, t_chpc) In one example, fine and coarse clip-map LODs (s_chpf, t_clιpf, s_clιpc, t_clιpc)are calculated as shown in equations (42) to (45) below:

c'ψf S. » [LOD_clφ exp + \s o/Jg » LOD _ψ +K_c-0.5 % tilesize (42)

^l lψ_f t, » LOD, dtp ^■exp t_o » LOD_clψ

*)) + K -0.5\ % tilesize (43)

^C'ψc s, » [LOD_CIΨ - exp₊ l)) + (s_oJfg » LOD_clψ + l) + K_c - 0.5 % tilesize (44)

'clip, - t, » (LOD_clψ - exp₊ l)) + _tqffg » LOD_dlp + l)+ K_e - 0.5 % tilesize (45)

For completeness, equations (42) to (45) can be derived as shown in equations (46) - (62) below:

^S fineg ^{= S}S » ^LODclιp (46)

^{1 '}fineg = » LOD_clψ (47)

S_βneg=S_g»[LOD_clψ + \ (48)

tf,_ncg = t_g»{LOD_{c p} + \ (49) Substituting in the relations for -s and s .

Sf_meg = ((•*, « exp) + s_offg) » LOD_clψ (50)

tfineg = (('/ « ^QXP) ^{+ t}offg) » LOD_clψ (51)

Scoarseg = ((* « ^ ) + ^offg) » ( LOD_clψ + l) (52)

tcoarseg = ((' « ^eXP) + * offg) » { ^^ODcl,p + l) (53)

Re-arranging terms to minimize the size of the calculations yields:

S_βneg = (^s, » (LOD_clιp - exp)) + (s_offg » LOD_chp) (54)

'fineg = ('- » ( ^LODcl,_P ^~ P)) + { <off_g » LOD_clφ) (55)

^Scoarseg = (^S, » ( ^LODcl,p ^~ ^P+ *)) + ( _oJfg » LOD_clψ + l) (56)

t_coarseg = (', » ( ^ D_clψ - exp+ l)) + (t _offg » LOD_clψ + l) (57)

Then calculate the final clip-map coordinates. Clip-map addresses can be expressed as:

^clφ + K_C - 0.5 mod {tilesize) (58) Substituting in terms derived in the previous steps into the above equation yields:

>dψf s, » (LOD_clip - exp)) + (s_ojrg » LOD_clψ) + K_c - tilesize (59)

clip . t, » (LOD_CIΨ - exp)) + (t_offg » LOD_clφ ) + K_c - 0.5 % tilesize (60)

^Sclφ_c ~ s, » [LOD_chp - exp+ l) + (s_ojrg » LOD_dψ + 1 + K - 05 % tilesize (61)

= [(', » {^LODc,_Ψ ^~ P^{+ l})) ⁺ {^t _ffε » ^LOD< clip 1 + ^ - 0.5 % tilesize (62)

In step 694, rendering is completed by mapping texture data identified by the fine and coarse clip-map tile specific coordinates (s_chpf, t_c,,_pf, s_clιpc, t_clιpc) calculated in step 692. This rendering can proceed as in normal mip-mapping and need not be described in further detail.

Steps 692 and 694 are carried out in texture engine 740. Texture engine 740 then outputs the fine and coarse clip-map tile specific coordinates (s _ιpf, t _ιpf, s_C| , t_clιpc) to memory access controller 754. Memory access controller 754 retrieves the texel data identified by the fine and coarse clip-map tile specific coordinates (s _ιpf, t_clιpf, s_{c pc}, t_clιpc). Texture engine 740 maps the retrieved texel data to the obj ect or scene being rendered using any conventional texture mapping operation or technique. Texture filter 760 can perform blending, filtering, accumulation and/or any other downstream texture processing and rendering operation. Final image data is then stored in frame buffer 770 for display on display unit. Such rendering can proceed as in normal mip-mapping and need not be described in further detail as would be apparent to a person skilled in the art given this description. 8. 3D Clip-Mapping

3D clip-mapping is a natural extension to 2D clip-mapping. The offsets and adjustments made to the s and t coordinates are just extended to the r coordinate. We propose implementing special clip-mapping for 3D textures, not general clip-mapping.

Impressive amounts of virtual 3D maps can be supported. For example a 64k x 64K x 64k 3D mip-map would take up 256 TBytes of storage uncompressed. Represented as a 256 x 256 x 256 clip-map it would take 146 MBytes. This is 0.00006% of the original data!

9. Example Environment

The present invention is described in terms of a computer graphics display environment for displaying textured images. Texture can be stored in any way including, but not limited to, texture stored in the form of a multi-resolutional texture map, such as, a MlP-map. Moreover, sophisticated texture motifs covering a large area, such as satellite data and aerial photographs, exploit the advantages of the general clip-map system and method described herein. However, as would be apparent to a person skilled in the pertinent art, the present invention applies generally to different sizes and types of texture patterns limited only by the imagination and resources of the user. Although the present invention is described herein with respect to two- dimensional texture mapping, the present invention can be extended to texture mapping in at least three or more coordinate dimensions when the requisite additional software and/or hardware resources are added. See, e.g., U.S. Patent No. 5,490,240 (incorporated herein by reference in its entirety). 10. Example Implementation

Routine 600 can be implemented as a general clip-mapping (GCM) module. For example, as would be apparent to a person skilled in the art given the present description, the GCM module can be implemented in software, firmware, hardware, or any combination thereof. For example, routine 600 can be implemented primarily as software, i.e., a computer program code executing on a processor. One or more of the steps (or a portion of the functionality of a step) in routine 600 can be implemented and accelerated using hardware, if available. When the present invention is implemented using software, the invention can be sold or distributed as a computer program product having a computer useable medium. In this document, the term "computer program product" is used to generally refer to a removable storage unit, a hard disk installed in a hard disk drive, or a carrier wave carrying software over a communication path (e.g., wireless link or cable) to a communication interface. Thus, a computer useable medium can include magnetic media, optical media, or other recordable media, or media that transmits a carrier wave or any data signal. These computer program products are means for providing software to a computer system.

Software (also called a computer program or computer control logic) can be stored in main memory and/or secondary memory. Computer programs can also be received via a communications interface. Such computer programs, when executed, enable a computer system (uni -processor or multi-processor) to perform the features of the present invention in routine 600 as discussed herein. In particular, the computer programs, when executed, enable a processor to perform the features of the present invention. Accordingly, such computer programs represent controllers of a computer system.

In an embodiment where the invention is implemented using software, the software may be stored in a computer program product and loaded into computer system using a removable storage drive, hard drive, or communications interface. Alternatively, the computer program product may be downloaded to computer system over a communications path. The control logic (software), when executed by one or more processors, causes the processor(s) to perform the functions of the invention as described herein. In another embodiment, the invention is implemented primarily in firmware and/or hardware using, for example, hardware components such as application specific integrated circuits (ASICs). Implementation of a hardware state machine so as to perform the functions described herein will be apparent to persons skilled in the relevant art(s). Given the description herein, it would be readily apparent to one skilled in the art 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 workstations, gaming platforms, systems and consoles, network architectures (e.g., client/server, local, intermediate or wide area networks), and virtual machine (e.g., a Java-created application). For example, the present invention can be implemented in software or after hardware modifications on an INFINITE REALITY, OCTANE, or 0₂ graphics workstation manufactured by Silicon Graphics, Inc. See, e.g., "InfiniteReality: A Real-Time

Graphics System," Computer Graphics Proceedings, Annual Conference Series, 1997, pp. 293-302 (incorporated herein by reference). Other raster graphics architectures can be used such as those described in Foley et al, Computer Graphics, Addison- Wesley Publishers, U.S.A. (1996), chapter 18, pp. 855-922 (incorporated herein by reference). Calculations can be performed in fixed-point or floating point arithmetic.

Of course, these specific computer graphics systems are recited as examples of systems which can support the present invention, but do not necessarily have to have the present invention to operate. For example, 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.

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 preceding description, it will become apparent to a person skilled in the relevant art how to implement the invention in alternative environments.

Conclusion

While specific 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.

Claims

What Is Claimed Is:

1. A method for mapping texture from a general clip-map stored in a texture memory, comprising the steps of:

(A) determining an exponent, the exponent being a function of a magnitude of at least one floating point texture coordinate corresponding to a vertex of a primitive; and

(B) calculating fixed point texture coordinates at vertices of a primitive based on at least the exponent determined in said determining step.

2. The method of claim 1, further comprising the steps of: (C) evaluating fixed point texture coordinates in an iterated space at a pixel corresponding to the fixed point texture coordinates calculated in said step (B).

3. The method of claim 2, further comprising the steps of:

(D) calculating a clip-map level of detail based on the exponent; and (E) converting the iterated space texture coordinates evaluated in said evaluating step (C) to clip-map tile specific coordinates at a clip-map tile in the general clip-map having a level of detail corresponding to the calculated clip-map level of detail.

4. The method of claim 3, wherein said step (D) comprises the steps of: calculating an initial mip-map level of detail (LOD); modifying the initial LOD by the exponent determined in said determining step; calculating an available level of detail based on the modified initial LOD; and calculating a clip-map level of detail based on the available level of detail.

5. The method of claim 3, further comprising the step of mapping texel data at the clip-map tile specific coordinates to an object such that image data representative of the texture mapped object can be stored in a frame buffer for display.

6. The method of claim 1, further comprising the steps of: storing the general clip-map in a texture memory; transforming addresses of data in the general clip-map to a floating point range that defines a base area.

7. A graphics system, comprising: a texture memory that stores a general clip-map; a scan converter; and a texture engine coupled between said texture memory and said scan converter; wherein said scan converter includes a clip-map texture coordinate and exponent calculator that determines an exponent, the exponent being a function of a magnitude of at least one floating point texture coordinate corresponding to a vertex of a primitive, and calculates fixed point texture coordinates at vertices of a primitive based on at least the determined exponent.

8. The system of claim 7, wherein said scan converter further evaluates fixed point texture coordinates in an iterated space at a pixel corresponding to said fixed point texture coordinates calculated by said clip-map texture coordinate and exponent calculator.

9. The system of claim 8, further comprising: a clip-map level of detail LOD calculator; coupled between said scan converter and said texture engine; wherein said clip-map level of detail LOD calculator calculates a clip-map level of detail (LOD _ιp) based on said exponent calculated by said clip-map texture coordinate and exponent calculator; and said texture engine converts the iterated space texture coordinates output by said scan converter to clip-map tile specific coordinates at a clip-map tile in the general clip-map having a level of detail corresponding to the clip-map level of detail output by said clip-map level of detail LOD calculator.

10. The system of claim 9, wherein said clip-map level of detail LOD calculator comprises: means for calculating an initial mip-map level of detail (LOD); means for modifying the initial LOD by the exponent determined in said determining step; means for calculating an available level of detail based on the modified initial LOD; and means for calculating a clip-map level of detail based on the available level of detail.

1 1. The system of claim 9, wherein said texture engine maps texel data at said clip-map tile specific coordinates to an object such that image data representative of the texture mapped object can be stored in a frame buffer for display.

12. The system of claim 7, further comprising: a texture database, said texture memory having a size smaller than an addressable range of said texture database; a preprocessor coupled between said texture database and said texture memory; wherein said preprocessor transfers the general clip-map from said texture database to said texture memory and transforms addresses of data in the general clip-map to a floating point range that defines a base area equal to or smaller than the size of said texture memory.

13. A method for general clip-mapping, comprising the steps of: storing a general clip-map in a texture memory; transforming addresses of data in the general clip-map to a floating point range that defines a base area; for vertices of a primitive, determining an exponent; calculating fixed point texture coordinates based on the exponent; evaluating texture coordinates in an iterated space at a pixel corresponding to the vertices of the primitive; calculating an initial mip-map level of detail (LOD); modifying the initial LOD by the exponent determined in said determining step; calculating an available level of detail based on the modified initial LOD; calculating a clip-map level of detail based on the available level of detail; and converting the iterated space texture coordinates evaluated in said evaluating step to clip-map tile specific coordinates at a clip-map tile in the general clip-map having a level of detail corresponding to the calculated clip-map level of detail.

14. A system for general clip-mapping, comprising: means for storing a general clip-map in a texture memory; means for transforming addresses of data in the general clip-map to a floating point range that defines a base area; for vertices of a primitive, means for determining an exponent; means for calculating fixed point texture coordinates based on the exponent; means for evaluating texture coordinates in an iterated space at a pixel corresponding to the vertices of the primitive; means for calculating an initial mip-map level of detail (LOD); means for modifying the initial LOD by the exponent determined in said determining means; means for calculating an available level of detail based on the modified initial LOD; means for calculating a clip-map level of detail based on the available level of detail; and means for converting the iterated space texture coordinates evaluated in said evaluating means to clip-map tile specific coordinates at a clip-map tile in the general clip-map having a level of detail corresponding to the calculated clip- map level of detail.

15. The method of claim 6, further comprising the step of permitting a user to select a level at which a pyramidal part begins in the general clip-map.

16. The system of claim 12, wherein the general clip-map includes at least a stack part.

17. The system of claim 12, wherein the general clip-map includes at least a stack part and a pyramidal part; and further comprising means for permitting a user to select a level at which a pyramidal part begins in the general clip-map.