Decompression of three-dimensional geometry data representing a regularly tiled surface portion of a graphical object

[0002] This application is a continuation-in-part of U.S. application Ser. No. 08/988,202, entitled “Compression of Three-Dimensional Geometry Data Representing a Regularly Tiled Surface Portion of a Graphical Object” by Michael F. Deering, filed Sep. 18, 1997, now abandoned, and assigned to assignee of this application, which is a continuation-in-part of U.S. application Ser. No. 08/885,279, entitled “System and Method for Generalized Geometric Compression of Three-Dimensional Graphics Data Having Regular Vertex Structures” by Michael F. Deering, filed on Jun. 30, 1997, now abandoned, and assigned to the assignee of this application, which is a continuation-in-part of application Ser. No. 08/511,294, entitled “Method And Apparatus For Geometric Compression Of Three-Dimensional Graphics Data” by Michael F. Deering, filed Aug. 4, 1995 now U.S. Pat. No. 5,793,371, and assigned to the assignee of this application.

[0003] U.S. application Ser. No. 08/511,294, entitled “Method And Apparatus For Geometric Compression Of Three-Dimensional Graphics Data” by Michael F. Deering, filed Aug. 4, 1995.

[0004] U.S. application Ser. No. 08/511,326, entitled “Method and Apparatus for Decompression of Compressed Geometric Three-Dimensional Graphics Data” by Michael F. Deering and Aaron S. Wynn, filed Aug. 4, 1995.

[0005] U.S. application Ser. No. 08/885,279, entitled “System and Method for Generalized Geometric Compression of Three-Dimensional Graphics Data Having Regular Vertex Structures” by Michael F. Deering, filed on Jun. 30, 1997.

[0006] U.S. application Ser. No. 08/988,202, entitled “Compression of Three-Dimensional Geometry Data Representing a Regularly Tiled Surface Portion of a Graphical Object” by Michael F. Deering, filed Sep. 18, 1997.

[0007] U.S. application entitled “Compression of Three-Dimensional Geometry Data Representing a Regularly Tiled Surface Portion of a Graphical Object” by Michael F. Deering filed concurrently herewith application Ser. No. 09/095,777 filed Jun. 11, 1998 now U.S. Pat. No. 6,215,500.

[0008] The present invention relates generally to compressing and decompressing three-dimensional graphics data, and more particularly to compressing and decompressing three-dimensional geometry data corresponding to regularly tiled surface portions of graphical objects.

[0009] Three-dimensional (3-D) computer graphics systems employing large geometric models find wide use in applications such as computer-aided design (CAD), virtual reality environments, training and simulation programs, games, and location-based entertainment. Such systems typically include a 3-D graphics accelerator, a specialized rendering subsystem which is designed to off-load graphics processing functions from the host processor, thereby improving system performance. In a system with a 3-D graphics accelerator, an application program executing on the host processor generates three-dimensional geometry data including information corresponding to points on the surface of a three-dimensional graphical object. These points are usable as vertices of polygons which, when connected, may be rendered to form a representation of the graphical object. The application program causes the host processor to transfer this 3-D geometry data to the graphics accelerator, along with corresponding control and connectivity information. The graphics accelerator receives this stream of compressed 3-D geometry data, and renders the encoded polygons on an attached display device.

[0010] The process of connecting three-dimensional vertices to form a representation of a graphical object is referred to as “tiling”. FIGS. 1A and 1B each illustrate graphical objects which have been tiled into component polygons. As shown, FIG. 1A depicts a 3-D lion 60, while FIG. 1B depicts a 3-D giraffe 70. It is noted that lion 60 is primarily tiled into triangles, while giraffe 70 is tiled using quadrilaterals. Tiling may be performed using a variety of different polygons.

[0011] This transmission of graphics primitives and commands from the host processor to the graphics accelerator over the system bus is one of the major bottlenecks in computer graphics. This bottleneck is becoming more problematic as users of graphics applications programs require an ever-increasing amount of complexity (and hence, size) in the geometric models used to produce visualization effects. The result is that slow memory subsystems or slow bus subsystems may not be able to adequately supply geometry data to the relatively fast real-time rendering hardware, thereby compromising system performance. The size requirements for a large set of geometric data may also cause memory constraints.

[0012] For example, rendering a large geometric data set with one million triangles at 30 Hz requires a system bus throughput of approximately 720 MB/sec (at a ratio of 24 bytes/triangle). While such high bus bandwidths may be attainable for high-end systems, low-end to mid-range systems typically have bandwidths on the order of 250-320 MB/sec. The performance of lower cost systems is thus effected by the throughput of the system bus as geometry processing requirements increase.

[0013] Techniques such as polygon simplification and visibility culling have been used to manage such large sets of geometry data. Polygon simplification allows an object to be viewed at different levels of detail, in relation to the viewing distance from the object. Visibility culling involves stripping away invisible portions of an object from the drawing loop. These techniques, however, are not efficient when most of a given object is visible and high resolution is desired. In such cases, the full amount of geometry data must be transferred from the host processor to the rendering hardware on the graphics accelerator.

[0014] Applicant's co-pending U.S. application Ser. No. 08/511,294, however, discloses methods and systems for compression and decompression of 3-D geometry data. If the compression is performed as a pre-process, the geometry data may be stored in main memory of the computer system in compressed format. Upon rendering, geometry data is transferred directly to graphics hardware in this compressed format. Decompression may be performed off-line in software or real-time in hardware or software.

[0015] Compression performed according to the manner described in the Applicant's parent patent application may result in a 6× to 10× reduction in size of the geometry data. The bus bandwidth required to transfer this data is therefore reduced as well. High-performance graphics thus becomes much more attainable for lower-cost graphics platforms.

[0016] However, Applicant's previously disclosed compression techniques are generalized to support compression of 3-D geometry data for surface portions which are tiled in an irregular fashion. Although this patent application discloses efficient compression techniques and devices, no provisions are made for taking advantage of greater compression efficiency possible for surfaces where polygons are connected in a regular manner. That is, while the compression techniques previously disclosed may be applied to regularly tiled surface portions, the compression efficiency achieved is not optimal.

[0017] Consider the 3-D lion 60 depicted in FIG. 1A. The surface of the lion 60 (comprising triangles and rectangles) is tiled such that little regularity exists between neighboring primitives. Accordingly, the compression techniques disclosed in patent application Ser. No. 08/511,294 achieve a suitable or near-optimal level of compression for triangle strips arranged in an irregular fashion.

[0018] Consider the 3-D giraffe 70 of FIG. 1B, however. While portions such as the head of giraffe 70 are irregularly tiled (and thus suited to the previously disclosed compression techniques), the neck and parts of the body of the giraffe 70 are tiled in a fairly regular fashion. For such regularly tiled surface portions, there is a need for techniques and devices which take advantage of the regular arrangement of surface polygons to achieve greater compression efficiency. Such compression techniques and devices should preferably be compatible or usable with existing compression/decompression techniques.

[0019] The present invention comprises a system and method for compressing 3-D geometry data corresponding to a regularly tiled surface portion of a three-dimensional object. In one embodiment, the method comprises receiving 3-D geometry data which includes vertex parameter values corresponding to vertices within the regularly tiled surface portion. These vertex parameter values may include position, color (including specular color), normals, bump and displacement mapping basis vectors, quad split information, and texture mapping coordinates. The method next includes representing the surface portion in a compressed format referred to as a “vertex raster”.

[0020] Representing a surface portion as a vertex raster first includes encoding an extent value for the surface portion which defines an arrangement of the vertices to be compressed. The extent value may specify the number of vertices along with the dimensions of a regular grid of vertices within the surface portion. Furthermore, the extent value may specify connectivity information for the vertices. In one embodiment, neighboring vertices may be connected to form quadrilaterals (which are further split into triangles for compression purposes). In yet another embodiment, neighboring vertices may be connected to form other polygons (hexagons, for example). Generally speaking, the extent value is selected to best fit the connectivity of the vertices being compressed. In a preferred embodiment, the extent value specifies that the regularly tiled surface portions includes vertices arranged in a square grid that is one of a plurality of predefined sizes.

[0021] The compression method next comprises encoding vertex parameter values corresponding to vertices within the regularly tiled surface portion. Vertex parameter values may be encoded globally, locally, or using a combination of global and local values. Global specification of a vertex parameter includes setting an initial value for the parameter along with an indication of how the parameter changes value across the surface portion. In one embodiment, this indication of change is specified by setting one or more delta values. In another embodiment, a function may be specified which is usable to compute the vertex parameter value at each vertex within the surface portion.

[0022] Vertex parameter values may also be encoded locally, on a per-vertex basis. In one embodiment, control bits are set which indicate what type of vertex parameters are to be encoded in the per-vertex data stream. This allows the per-vertex data stream to be encoded without the need for stop bits which specify the end of the stream. Locally specified values may be encoded by a variety of techniques, including absolute values, delta-encoded values, and delta-delta encoded values.

[0023] Global and local specification of parameter values may also be combined advantageously. A vertex raster representing one surface portion, for example, may use global specification of position and local specification of color values. Furthermore, global and local specification may also be used for the same parameter. For example, a locally specified z-displacement value may be used in combination with a globally specified position value to perform displacement texturing (which is used to simulate wrinkles or bumps on the surface of a graphical object).

[0024] In an embodiment in which the extent value is one of a number of predetermined sizes, these predetermined sizes may not be large enough to represent a given surface portion. In such cases, a step command may be utilized to re-use the global parameters of one vertex raster with newly specified per-vertex data. In one embodiment, a step command includes a value which indicates the direction of the new surface portion relative to the previously specified surface portion. Use of the step command may increase compression efficiency since global data does not need to be re-specified.

[0025] In one embodiment, the extent value of a surface portion specifies that neighboring vertices are arranged in a regular grid. These neighboring vertices are usable to form a plurality of quadrilaterals, which each may be further divided into a pair of triangles for rendering. For a given quadrilateral, there are two possible ways to perform this division. If no connectivity is specified for a quadrilateral within a surface portion, a default tessellation is performed in one embodiment. In an alternate embodiment, tessellation may be performed on a quad-by-quad basis through the use of an explicit split bit, which indicates the manner in which a particular quadrilateral is to be divided. Performing tessellation on a per-quadrilateral basis may lead to reduced visual artifacts and “jagginess” in rendered images.

[0026] Another common artifact in 3-D images occurs when a surface portion represented in a given resolution is adjacent to a surface portion represented in a lower resolution. This results in a visually unappealing and unrealistic image. To diminish this effect, a surface portion represented as a vertex raster may include one or more edges represented in half-resolution mode. In this mode, the one or more edges provide an area of intermediate resolution between the two surface portions. This provides a smoother flow in the resultant image.

[0027] The present invention also comprises a system and method for decompressing compressed 3-D geometry which represents regularly tiled surface portions. In one embodiment, the decompression method first includes receiving the 3-D geometry data which includes an extent value and encoded vertex parameter values. The method next includes receiving initial values for globally specified vertex parameters, followed by receiving one or more corresponding delta values. These delta values indicate how the vertex parameters change value across the surface portion being represented. In one embodiment, these one or more delta values are applied according to a vertex traversal order specified by the extent value.

[0028] Next, the method includes receiving a stream of per-vertex (local) data, which includes one or more vertex parameter values for each vertex. These values may be encoded as absolute values, delta-encoded values, or delta-delta encoded values. The method includes accessing the vertex parameter values for a current vertex (which typically begins with a predetermined initial vertex). The method then includes generating final parameter values for the current vertex using globally specified values, locally specified values, or both.

[0029] During decompression, vertex parameter values for selected vertices are stored into a mesh buffer for use in forming subsequent primitives. The selected vertices are typically determined according to the decoded extent value. In a surface portion which includes a regular grid of vertices, for example, all vertices on the bottom row of the grid are initially stored into the mesh buffer without forming any drawing primitives in one embodiment. These stored values are then accessed during traversal of the next row of vertices in order to form a plurality of geometric primitives.

[0030] After generating final vertex parameter values for the current vertex, a determination is made as to whether one or primitives are to be assembled using the current vertex. If no explicit connectivity information is supplied, drawing primitives are generated according to a predetermined default connectivity. If connectivity is explicitly defined in the compressed data, however, primitives are generated accordingly. In one embodiment, this connectivity information includes quad split bits which indicate a tessellation direction for a quadrilateral region formed by neighboring vertices within the represented surface portion. One or more primitives may be formed from a given current vertex value.

[0031] The method continues with selecting a next vertex to be the new current vertex. This includes accessing the vertex parameter values for the new current vertex from the per-vertex data stream. The method then continues as described above until the last vertex (typically predetermined by the vertex traversal order) is reached.

[0032] The present invention thus provides efficient systems and methods for compression and decompression of 3-D geometry data corresponding to regularly tiled surface portions.

[0033] A better understanding of the present invention can be obtained when the following detailed description of a preferred embodiment is considered in conjunction with the following drawings, in which:

[0034] FIG. 1A illustrates a tessellated 3-D object with an irregularly tiled surface;

[0035] FIG. 1B illustrates a tessellated 3-D object with regularly tiled surface portions;

[0036] FIG. 2 illustrates a computer system which includes geometry compression capabilities according to the present invention;

[0037] FIG. 3 is a simplified block diagram of the computer system of FIG. 2;

[0038] FIG. 4 illustrates a client-server network which transfers compressed geometry data according to the present invention;

[0039] FIG. 5 depicts a method for compressing geometry data according to a preferred embodiment of the present invention;

[0040] FIG. 6 illustrates a surface portion including a 5×5 grid of vertices which may be represented as a vertex raster according to the present invention;

[0041] FIG. 7 depicts the format of a command to set the size of a surface portion according to a preferred embodiment of the present invention;

[0042] FIG. 8 depicts the format of a command to initialize parameters to be interpolated across the surface portion according to a preferred embodiment of the present invention;

[0043] FIG. 9 illustrates a traversal order of the vertices of a surface portion according to a preferred embodiment of the present invention;

[0044] FIGS. 10A-B depict the format of commands to vary parameters to be interpolated across the surface portion according to a preferred embodiment of the present invention;

[0045] FIGS. 11A-C illustrate surface portions with various delta U and delta V position values;

[0046] FIGS. 12A-C depict the format of commands which specify streams of per-vertex data according to a preferred embodiment of the present invention;

[0047] FIGS. 13A-B depict the format of command which set mode bits used in geometry compression and decompression according to a preferred embodiment of the present invention;

[0048] FIG. 14 depicts the format of a step vertex raster command according to a preferred embodiment of the present invention;

[0049] FIG. 15 illustrates a regularly tiled surface portion which may be compressed using the step vertex raster command according to a preferred embodiment of the present invention;

[0050] FIG. 16 depicts a method for compressing geometry data using the step vertex raster command according to a preferred embodiment of the present invention;

[0051] FIG. 17A depicts aliasing effects caused by splitting surface portion quadrilaterals in only one direction.

[0052] FIG. 17B depicts reduced aliasing effects exhibited by a preferred embodiment of the present invention which allows designation of split direction on a per-quadrilateral basis.

[0053] FIG. 18 illustrates a surface portion tessellated with quad split bits according to a preferred embodiment of the present invention;

[0054] FIG. 19 depicts the format of a set edge half resolution command according to a preferred embodiment of the invention;

[0055] FIGS. 20A-D depict surface portions with each of the half-rez edge bits set according to a preferred embodiment of the present invention;

[0056] FIG. 21 depicts a surface portion that utilizes half-rez mode according to a preferred embodiment of the present invention in order to reduce aliasing effects for a given object;

[0057] FIG. 22 depicts a block diagram of a graphics sub-system according to one embodiment of the present invention;

[0058] FIG. 23 illustrates a generalized flowchart for performing decompression of regularly tiled surface portions according to one embodiment of the present invention;

[0059] FIG. 24 illustrates a flowchart for performing decompression of regularly tiled surface portions which include quad split bits; and

[0060] FIG. 25 illustrates a flowchart for performing decompression of regularly tiled surface portions which include a bottom edge represented in a half-resolution mode.

[0061] Incorporation by Reference

[0062] Co-pending U.S. application Ser. No. 08/511,294, filed Aug. 4, 1995, entitled “Method and Apparatus for Geometric Compression of Three-Dimensional Graphics Data”, issued as U.S. Pat. No. 5,793,371, on Aug. 11, 1998, and assigned to the assignee of this application, is hereby incorporated by reference as though fully and completely set forth herein.

[0063] Co-pending U.S. application entitled “Method of Producing a Sequence of Triangles From a Vertex Raster With and Without Half Resolution Edges While Decompressing a Compressed Geometry Stream”, filed Jan. 15, 1998 by Jeffrey M. Chan, issued on Feb. 22, 2000 as U.S. Pat. No. 6,028,607, is hereby incorporated by reference as though fully and completely set forth herein.

[0064] FIG. 2—Computer System

[0065] Referring now to FIG. 2, a computer system 80 is depicted which includes three-dimensional geometry compression and/or decompression capabilities according to one embodiment of the present invention. As shown, the computer system 80 comprises a system unit 82 and a video monitor or display device 84 coupled to the system unit 82. Various input devices may be connected to the computer system, including a keyboard 86 and/or a mouse 88, or other input.

[0066] Application software may be executed by the computer system 80 which generates three-dimensional geometry data describing graphical objects to be rendered on display device 84. As will be described further below, computer system 80 is configured to compress the three-dimensional geometry data. The compressed 3-D geometry data may then be stored in the memory of computer 80. The compressed 3-D geometry data stored in the memory may then be later transferred over a network or transferred to a 3-D graphics accelerator within computer system 80 for decompression and rendering. Alternatively, the compressed 3-D geometry data is used to create a medium, such as a CD-ROM, which may be used for applications such as games. The compression advantageously results in decreased transmission time of the compressed geometry data over a network or to a graphics accelerator, as well as reduced memory requirements for storing the compressed geometry.

[0067] When the computer system 80 is configured for geometry decompression, the computer 80 receives compressed 3-D geometry data. This data may be received from a network, the host CPU of computer 80, or from a memory medium (such as a CD-ROM) coupled to the computer system.

[0068] FIG. 3—Computer System Block Diagram

[0069] Referring now to FIG. 3, a simplified block diagram illustrating the computer system 80 of FIG. 2 is shown. Elements of the computer system 80 which are not necessary for an understanding of the present invention are not shown for convenience. As shown, the computer system 80 includes a central processing unit (CPU) 102 coupled to a high speed bus or system bus 104. A system memory 106 is also preferably coupled to the high speed bus 104.

[0070] The host processor 102 may be any of various types of computer processors, multi-processors and CPUs. The system memory 106 may be any of various types of memory subsystems, including random access memories and mass storage devices. The system bus or host bus 104 may be any of various types of communication or host computer buses for communication between host processors, CPUs, and memory subsystems, as well as specialized subsystems.

[0071] A 3-D graphics accelerator 112 according to the present invention is coupled to the high speed memory bus 104. The 3-D graphics accelerator 112 may be coupled to the bus 104 by, for example, a cross bar switch or other bus connectivity logic. It is assumed that various other peripheral devices, or other buses, may be connected to the high speed memory bus 104, as is well known in the art. Further, the graphics accelerator 112 may be coupled through one or more other buses to bus 104.

[0072] The host processor 102 may transfer information to and from the graphics accelerator 112 according to a programmed input/output (I/O) protocol over the host bus 104. In one embodiment, the graphics accelerator 112 accesses the memory subsystem 106 according to a direct memory access (DMA) protocol, or through intelligent bus mastering.

[0073] In one embodiment, three-dimensional geometry data is generated by a graphics application program executing on computer system 80. The resulting 3-D geometry data is compressed prior to or subsequent to storage in system memory 106. The geometry data may be compressed by host CPU 102 executing a software compression program from system memory 106, or transferred to a specialized hardware unit within system unit 82 for compression. If the computer system 80 is also being used to render the 3-D geometry data, the compressed data is transferred from system memory 106 to graphics accelerator 112 over system bus 104. Graphics accelerator 112 decompresses the transferred compressed geometry data, rendering the resulting primitives accordingly on display device 84. The compressed 3-D geometry data may also be transferred over a network for subsequent decompression (as discussed with reference to FIG. 4), or stored to a removable medium such as a CD-ROM. It is noted that 3-D graphics accelerator 112 may not be necessary if computer system 80 is used strictly for compression purposes. This may be the case if computer system 80 is used to store the compressed data to a memory medium or transfer the data over a network.

[0074] As described below, the compression system and method described herein is preferably directed toward compression of surface portions of three-dimensional objects which are regularly tiled. As also described below, the decompression system and method described below operate to decompressed compressed 3-D geometry data which has been compressed to take advantage of regular tiling of primitives included in the geometry data. In one embodiment, the compression system and method selectively performs different types or levels of compression on surface portions of 3-D geometry data, depending on whether the portion being compressed is regularly or irregularly tiled. Correspondingly, the decompression system and method selectively may perform different types of decompression depending on the particular surface portion being decompressed.

[0075] FIG. 4—Computer Network

[0076] Referring now to FIG. 4, a computer network 120 is shown comprising at least one server computer 122 and one or more client computers 126. (In the embodiment shown in FIG. 4, client computers 126A-B are depicted). Server 122 and client(s) 126 may be joined through a variety of connections 124, such as a local-area network (LAN), a wide-area network (WAN), or an Internet connection. In one embodiment, server 122 stores pre-compressed 3-D geometry data in accordance with the present invention. Clients 126A-B may connect to server 122 to download the compressed geometry. One or more of clients 126 receive the compressed 3-D geometry data and then decompress the compressed geometry data for rendering. Alternately, one or more of clients 126 may generate 3-D geometry data, perform compression, and transfer the compressed geometry to server 122 for storage. In still another embodiment, the compressed 3-D geometry data may be transferred between client computers 126.

[0077] FIGS. 5-13—Geometry Compression of a Regularly Tiled Surface Portion

[0078] FIG. 5 illustrates a compression method 200 for data defining a regularly tiled surface portion of a three-dimensional object. As shown, method 200 first includes step 210, in which the three-dimensional geometry data is tiled. In one embodiment, the geometry data may be represented as a generalized triangle strip. In another embodiment, the geometry data may be represented in generalized triangle mesh format. As described in U.S. patent application Ser. No. 08/511,294, a generalized triangle mesh format encodes position and connectivity of the geometry data, and utilizes space efficiently by allowing vertex information to be reused. One algorithm that may be utilized to generate a generalized triangle mesh representation is described in “Optimized Geometry Compression for Real-time Rendering” by Michael Chow in the proceedings of IEEE Visualization97.

[0079] In step 220, a regularly tiled surface portion is selected to be represented in compressed format. This compressed format is referred to herein as a “vertex raster”. Generally speaking, a vertex raster includes an associated extent and sufficient information to determine one or more vertex parameter values within the specified extent. As will be described below, the extent portion of the vertex raster may specify one of a plurality of predefined sizes or may specify an arbitrary size and shape of the surface portion and the vertices included therein. FIG. 6 depicts a regularly tiled surface portion 300 which is to be represented as a vertex raster. Although a vertex raster may be of any given extent, the extent of the vertex raster shown in FIG. 6 is a 5×5 square grid of vertices.

[0080] In step 230, the extent of the vertex raster is specified in the encoded data stream. In a preferred embodiment, the extent value of a vertex raster is encoded as a 2-bit value which is indicative of a square grid which is one of three defined sizes: 5×5 (25 vertices), 9×9 (81 vertices), or 17×17 (289 vertices). It is noted that various other predefined sizes may be used instead of, or in addition to, the predefined sizes recited above. For example, a regularly tiled surface portion may be represented as a 3×5 vertex raster in one embodiment.

[0081] In one embodiment, specifying an extent for a vertex raster also implicitly defines connectivity information for vertices within the regularly tiled surface portion represented by the vertex raster. Consider surface portion 300 in FIG. 6. In one embodiment, an extent value for surface portion 300 specifies that the vertices are to be connected into squares (or, more generally, quadrilaterals or “quads”). Each quad is typically split (or “tessellated”) into a pair of triangles which are then encoded in a compressed geometry data stream. It is noted that a given quad may be tessellated in one of two directions: from the lower left corner to the upper right corner or from the upper left corner to the lower right corner. In one embodiment, if no explicit tessellation information is specified on a quad-by-quad basis, all quads are assumed to be split in a default direction (such as the default direction shown for all quads in FIG. 6). As will be described below, explicit connectivity information may also be supplied within a vertex raster.

[0082] Furthermore, the vertices of a surface portion do not necessarily have to be grouped as quadrilaterals in order to be represented as a vertex raster. For example, consider a surface portion which is tiled in a hexagonal manner. A vertex raster may be defined for such a surface portion which specifies vertices which are to be assembled into hexagons rather than quads or triangles. Also, a vertex raster may also be defined for an irregularly tiled surface portion which is irregular in a predictable fashion.

[0083] In one embodiment, it is noted that adjacent surface portions of a graphical object may each be represented as a vertex raster. In such an embodiment, each surface portion may share vertices along the common edge(s). Accordingly, the vertices in the vertex rasters representing the adjacent surface portions may also each include information on the common vertices.

[0084] As will be described below, the extent of the vertex raster is used during decompression to determine parameter values for each of the vertices within the surface portion represented by the vertex raster. The format of the “SetVertexRasterSize” command in a preferred embodiment of the present invention is shown in FIG. 7. Two bits are used in the command to specify one of the three predefined raster sizes. In an alternate embodiment, the vertex raster may be of an arbitrary size. This arbitrary size may be given explicitly, or may be encoded in the per-vertex data stream as “stop codes” which indicate the end of a row or data or of the entire raster.

[0085] In addition to specifying an extent of a surface portion, a vertex raster also includes sufficient information to decompress vertex parameter values of vertices within the surface portion represented by the vertex raster. As will be described below, the vertex parameter values of the regularly tiled surface portion may be specified per-vertex (explicitly), by interpolation values, or using a combination thereof. In one embodiment, the vertex parameter values specified within a vertex raster include (i) position values, (ii) color values, (iii) normal values, (iv) texture map coordinates, (v) bump/displacement mapping values, and (vi) surface material properties.

[0086] In one embodiment, initial values of selected parameters may be specified within a vertex raster along with an indication of how these values change across the vertex raster. For example, consider a surface portion of a graphical object in which positional coordinates vary in a regular fashion. For such a surface portion, initial position values may be specified which correspond to a predetermined vertex within the surface portion. Then, positional delta values may be specified which indicate how position values change from vertex-to-vertex within the surface portion represented by the vertex raster. Interpolation may also be performed upon other vertex parameter values, such as those listed above. Values encoded in this manner are also referred to as being globally specified values.

[0087] Vertex parameter values may also be specified explicitly, on a per-vertex basis. In one such embodiment, a vertex raster may include an extent, an encoding specifying what parameters are included in the vertex raster, followed by a stream of per-vertex data. The size of this vertex data is determinable from the extent of the surface portion and the size of the data specified for each vertex. While this technique may not achieve the compression possible using the interpolation values described above, compression still results from not having to explicitly encode connectivity information for the regularly tiled surface portion. Values encoded in this manner are also referred to as being locally specified values.

[0088] These two techniques (interpolation and per-vertex data) may also be combined within a single vertex raster. That is, certain vertex parameter values may be specified by a interpolation, while others may be specified on a per-vertex basis. For example, a vertex raster representing a given surface portion of a graphical object may include position values which are specified by interpolation and color values which are specified on a per-vertex basis. In yet another embodiment, a given vertex parameter value may be computed using global and local values. One example of this technique is the use of locally specified z-displacement values to perturb globally specified normal values.

[0089] In the flowchart of method 200 shown in FIG. 5, both techniques for specifying vertex data are utilized. Interpolated values are encoded in steps 240-250, while per-vertex data is encoded in step 260. These steps are described in further detail below.

[0090] In step 240, initial values of selected parameters are specified for vertices in the surface portion represented by the vertex raster. These selected parameters correspond to an initial vertex, which is typically in a predefined location within the surface portion. The values of the remaining vertices are interpolated across the raster during the decompression process based on the initial values set in step 240. Since these parameters are interpolated for each vertex in the surface portion, these parameters do not have to be specified on a per-vertex basis in the compressed data stream, thereby saving memory and bus bandwidth. The initial parameter values are specified, in one embodiment, using a “SetVertexRasterStart” command in a preferred embodiment of the invention. One possible format for this command is shown in FIG. 8.

[0091] As shown in FIG. 8, the “SetVertexRasterStart” command specifies one of five vector registers (i=0 to 4). Each of these vector registers includes a different interpolatable parameter. The assignment of these vector registers in a preferred embodiment is shown below in Table 1.

[0092] Vector register 0 (VR0) includes initial position data, and is configured in a preferred embodiment to store 16-bit fixed point values for x, y, and z coordinates. VR1 is configured to store 4 16-bit color values in a preferred embodiment: red, blue, green, and alpha. The alpha value is optional depending on the state of a mode bit discussed below. VR2 stores the x-y-z components of a global normal value, while VR3-4 store basis vectors used to assist in bump and displacement mapping. In a different embodiment, the vector registers may be configured differently. For example, a different number or a different size per register may be used. Similarly, other attributes relating to the vertices may be stored in the vector registers in place of or in addition to the parameters shown above. In one embodiment, a vertex raster representation may include zero to five SetVertexRasterStart commands, one for each vector register. In this embodiment, if no vector registers are specified, vertex parameter values are specified on a per-vertex basis.

[0093] In step 250, delta values are set for the parameters selected in step 240, indicating how these parameters vary across the surface portion represented by the vertex raster. In a preferred embodiment, these delta values may be specified in both the U and V directions (not to be confused with the names sometimes used for texture mapping coordinates). The U and V directions are shown for one embodiment of a regularly tiled surface portion in FIG. 9. FIG. 9 also depicts the vertices within surface portion 300 labeled according to the order in which the vertices are processed during decompression (and hence the order in which interpolation is performed). Similarly, the order shown in FIG. 9 also refers to the order in which per-vertex data is stored within the vertex raster representation of surface portion 300. As shown in FIG. 9, the U direction, in one embodiment, refers to the direction between vertices on a particular row. Conversely, the V direction, in one embodiment, refers to the direction between successive rows.

[0094] Referring now to FIGS. 10A and 10B, the formats for commands which, in one embodiment, set the delta values for the parameters selected in step 240 are shown. FIG. 10A depicts the format of the “SetVertexRasterStepDU” command, while the “SetVertexRasterStepDV” command format is depicted in FIG. 10B. The Vertex Raster Delta-U vector registers are configured to store three (four, in the case of VRDU1) fixed point values which indicate the change between each vertex in the raster in the U direction for a particular quantity. For example, the x-y-z values in VRDU0 indicate the position difference (Δx, Δy, and Δz) between any two adjacent vertices in FIG. 9 within the same row. The Vertex Raster Delta-V registers are configured similarly (VRDV0 values specify the position difference between any two adjacent vertices in FIG. 9 within the same column). In one embodiment, these delta registers allow position, global color, global normal, and bump/displacement vectors to be specified once (by the “SetVertexRasterStart” command), with the remaining values for the vertices of the raster interpolated during decompression, thereby reducing the size of the encoded data stream. The values specified by the “SetVertexRasterStep” commands are effectively the derivative of the value represented by VRi (i=0-4) with respect to the U or V planar coordinate.

[0095] Note that all of the vector registers are optional with respect to the vertex raster; that is, none, some, or all of them may be set. Even with no values interpolated in the vertex raster, the connectivity information is still inherent in the vertex raster representation. This eliminates the need for mesh buffer push and reference bits which are used explicitly in generalized triangle mesh format. The use of the vector registers VR0-44 is advantageous where applicable, however, since greater compression ratios may be achieved.

[0096] Although the vertices of surface portion 300 are arranged in a square grid, the formats of the vertex raster step commands described above allow specification of surface portions that have vertices arranged in alternate fashions. This is facilitated by having separate step commands for the U and V direction, which both allow changes in each of the x, y, and z coordinates. By appropriate encodings of the SetVertexRasterStepDU and SetVertexRasterStepDV commands, surface portions such as 400, 410, and 420, depicted in FIGS. 11A-C, may be compressed according to the present invention. Surface portion 400 includes vertices organized as a rectangular grid, while surface portions 410 and 420 are organized as rhombuses (with no right angles) and parallelograms (with unequal adjacent sides and unequal interior angles), respectively.

[0097] In step 260, optional per-vertex is specified for vertices in the surface portion represented by the vertex raster. In one embodiment, this information is specified using one of the commands shown in FIGS. 12A-C. FIG. 12A depicts the format of an “ExecuteVertexRaster” command according to one embodiment of the invention. This command is followed by a stream of per-vertex data. In one embodiment, the format of the per-vertex data is pre-specified using an additional command described below. In this manner, the end of the stream of per-vertex data may be determined by multiplying the number of vertices by the data size for a given vertex. This allows another geometry command to immediately follow the per-vertex data without necessitating stop bits for the execute command. There area also other techniques which obviate the need for stop bits in the per-vertex data stream. One such technique that uses header-body pairs is described in greater detail below. Because the per-vertex data follows in-line with the command, no other opcodes are needed until all data points corresponding to each of the vertices in the raster have been read. In a preferred embodiment, the execute command includes per-vertex data for 25, 81, or 289 vertices.

[0098] Alternately, the vertex raster data may be specified starting at a memory address by the “ExecuteVertexRasterIndirect” command shown in FIG. 12B. This allows the same per-vertex data to be used for different rasters while changing the interpolation parameters as described above. Compression efficiency is advantageously increased by use of this command.

[0099] The “ExecuteVertexRaster32Indirect” command shown in FIG. 12C is used for vertex rasters with a special memory format: 32-bit rgba pixels. The vertex raster data starts at the address specified, but after 5, 9, or 17 pixels (depending on the size value), the raster data continues at address+stride, where stride is the width of the raster in bytes. Both the address and stride are 32-bit word-aligned in a preferred embodiment of the invention.

[0100] As described above, various vertex parameter values may be specified on a per-vertex basis. In a preferred embodiment, the per-vertex attributes which are specified as part of a given vertex raster is determined by the state of mode bits set by the most recent “SetState” and “SetState2” commands. The format of these commands in one embodiment is shown in FIGS. 13A and 13B. A description of the operand fields of the SetState command is given in Table 2.

[0101] The “dde” bit enables delta-delta encoding and is discussed further below. The “bnv” and “bcv” bits, when set, specify that normals and colors, respectively, are part of the per-vertex data which follows the “ExecuteVertexRaster” command. If the “cap” bit is set, the per-vertex color values include an alpha value in addition to rgb components. Finally, if the “qsp” bit is set, a tessellation bit is specified for each quadrilateral in the vertex raster. These separate tessellation bits are used for anti-aliasing purposes and are discussed further below.

[0102] A description of bit fields in the SetState2 command is given in Table 3 below.

[0103] The SetState2 command is an extension of the mode bits set by the SetState command described above. The “scp” bit indicates that specular color values are present in the per-vertex information. This specular color values is interpreted as a texture map coordinate if the “tex” bit is set. Likewise, the local color value (controlled by the “bcv” bit) is interpreted as a coordinate from an alternate texture map if the “tx2” bit is set.

[0104] The “psrc” bits determine how the vertex positions are computed between successive vertices in the surface portion being represented as a vertex raster. If psrc=00, the xyz positions are explicitly specified for each vertex in the surface portion (even if VR0 has been initialized). Although this does not take full advantage of the vertex raster symmetry, the connectivity information is still implicitly defined by the raster. Hence, there is no need for the explicit mesh buffer pushes and references that are used in a generalized triangle mesh with no vertex raster command.

[0105] If psrc=01, the initial value for the xyz position data is interpolated across the vertices of the vertex raster according to the predefined U and V delta values. Referring again to FIG. 9, the initial position values (as specified by the SetVertexRasterStart command) are applied to vertex 0. The delta U value is then applied to vertex 0 to obtain the position data for vertex 1. The same procedure is followed for vertices 2, 3, and 4. To determine the position of vertex 5, the delta V value is applied to vertex 0. The delta U is then applied to vertex 5 to calculate vertex 6 (and subsequently, vertices 7, 8, and 9). In this mode, greater compression efficiency may be achieved relative to psrc setting ‘00’, in which position data is explicitly specified for every vertex.

[0106] When psrc=10, xyz positions are interpolated from VR0 as described above. Additionally, z displacement values are present in the per-vertex data. The z displacement values are used to perform displacement texturing, in which the surface is offset by a small amount in order to simulate a wrinkle or a bump. In many cases, this is more effective than bump mapping (in which the surface normal is perturbed), particularly near the silhouette of a shaded object. The psrc=11 encoding is not currently used in a preferred embodiment of the invention.

[0107] Bit fields vr1, vr2, vr3, and vr4 in the SetState2 command are used by the decompression unit to determine if the various vector register quantities are enabled for a particular raster. If a bit is not sent for a particular quantity, the decompression unit does not forward on a value for that quantity (e.g., a local normal) to a subsequent stage of the rendering hardware. In one embodiment, the vr state bits correspond to those attributes which are initialized by the SetVertexRasterStart command.

[0108] In alternate embodiments, additional state bits are employed which specify additional data to be included in the per-vertex data of the raster. It is further noted that the per-vertex data of the raster may be encoded in a variety of manners, including the compression techniques disclosed in the parent patent application for positions, colors, and normals.

[0109] FIGS. 14-16—StepVertexRaster Command

[0110] As described above, for a preferred embodiment of the present invention, vertex rasters may be defined to represent regularly tiled surface portions having vertices arranged in square grids that are one of three predetermined sizes: 5×5, 9×9, and 17×17. The grids are limited to these sizes in a preferred embodiment in order to simplify the decompression hardware. As a result, however, an entire regularly tiled surface portion may not be able to be represented by a single vertex raster structure in some instances. In these cases compression efficiency would be compromised if all the vertex raster data had to be re-specified.

[0111] In order to circumvent this limitation while still maintaining a manageable vertex raster size, a “StepVertexRaster” command may be used. The format for this command according to one embodiment of the present invention is shown in FIG. 14. The stepVertexRaster command takes a single argument, “dir”. This three bit field encodes one of three possible directions in which to move the current vertex raster. The encoding of the dir field in a preferred embodiment is shown in Table 4 below:

[0112] It is noted that in an alternate embodiment, the encoding of the dir field may be expanded to represent additional directions to move the current raster (e.g., −V; −U, +V; etc.).

[0113] An example of a use for the StepVertexRaster command is illustrated in FIG. 15. FIG. 15 depicts a 9×5 regularly tiled surface portion 500 of a three-dimensional object. In a preferred embodiment as described above, this size surface portion is not able to be represented as a single vertex raster. In one embodiment, surface portion 500 may be divided into two 5×5 surface portions 510A-B and efficiently compressed using a combination of the method described with reference to FIG. 5 and the StepVertexRaster command of FIG. 14. A method 600 for compressing surface portion 500 is shown in FIG. 16.

[0114] As shown, method 600 proceeds according to method 200 described above. Surface portion 500 is tiled and selected to be encoded a vertex raster in steps 210 and 220. In step 230, the extent of the first vertex raster (510A) is set as a 5×5 square grid. Next, initial values are set up in the VR registers for the vertex 0 of raster 510A in step 240. In step 250, delta U and delta V values are stored specifying how the parameters initialized in step 240 vary across the raster. In step 260, an execute vertex raster command is issued, followed by optional per-vertex data for the raster.

[0115] After vertex raster 510A is specified by steps 210-260, a StepVertexRaster command is issued in step 270. In the example shown in FIG. 15, vertex raster 510B is the next to be encoded. With respect to vertex raster 510A, raster 510B is located in the +U direction. The StepVertexRaster command in step 270 therefore includes a dir bit field value of ‘000’ in a preferred embodiment.

[0116] In one embodiment, execution of the StepVertexRaster command causes the values of the active vector registers to be interpolated in the direction specified by the ‘dir’ value. In the example above, the delta U values are multiplied by 4 and added to the initial active VR values to obtain the initial values for raster 510B. No change is calculated in the V direction. Furthermore, the stepVertexRaster command causes the per-vertex data specified by the previous vertex raster command to be re-executed with respect to the new values in the VR registers.

[0117] As shown in FIG. 16, step 270 may be repeatedly executed. Upon execution of each step command, new values are calculated for the VR registers. These new values are then used as a basis for interpolation across vertices of the newly-specified surface portion. Upon issuance of yet another step command, the most recently calculated VR register starting values are used as a basis for calculating new VR register starting values.

[0118] Because interpolation values do not have to be redundantly specified for raster 510B, the compression efficiency is advantageously increased for surface portion 500. In a different embodiment, the command(s) to step the vertex raster may be supplied by additional data in the per-vertex information or as additional operands to the execute raster command. The specification of a step function for vertex rasters effectively allows compression of the compressed geometry data, advantageously reducing the amount of data encoding.

[0119] FIGS. 17-18—Quad Split Tessellation

[0120] In the surface portions depicted above, the quadrilaterals formed by the intersection of row and column lines are shown as all being tessellated in the same (default) direction. Regardless of which direction is chosen as a default, undesirable visual artifacts may result. Consider the representation of the letter “C” 650 shown in FIG. 17A. For letter 650, each quad in the surface portion is tessellated in the same direction (upper left to lower right corner). This results in portions of letter 650 having jagged edges.

[0121] In contrast, the representation of the letter “C” 660 is formed using selective splitting of quadrilaterals. That is, each quadrilateral in the surface portion of FIG. 17B is split in a manner most befitting the object being drawn. Accordingly, letter 660 has a reduced degree of “jagginess” with respect to letter 650.

[0122] Objects may thus exhibit serrated edges if the split direction does not match the strongest color change within a given quadrilateral. Quad tessellation direction may be specified using values in the encoded data stream, or, alternatively, through the use of a quad split difference function calculated dynamically during decompression. The use of either method advantageously results in fewer artifacts in the final rendered image.

[0123] The qsp field of the SetState command is set in order to enable explicit specification of quad tessellation in the vertex raster. That is, when the qsp field is set, the per-vertex data stream following the ExecuteVertexRaster command includes a bit value for each quadrilateral, indicating the split direction. An example of tessellation performed on a per-quadrilateral basis is shown in FIG. 18.

[0124] Referring now to FIG. 18, surface portion 700 includes a 5×5 grid of vertices divided into 16 quadrilaterals. Each of the quadrilaterals is labeled by its corresponding split bit. Quadrilaterals labeled with a ‘0’ (the default direction) are split from the lower left corner to the upper right, while quadrilaterals labeled with a ‘1’ are split from the upper left to lower right corners.

[0125] In a preferred embodiment, when the qsp bit is not set by the SetState command, a difference function may be used to automatically determine the quad split direction during rendering. In one embodiment, this difference function is given by the following equation: $\mathrm{diff}\left(A,B\right)=\left|\frac{\left(r_A-r_B\right)}{2}+\left(g_A-g_B\right)+\frac{\left(b_A-b_B\right)}{4}\right|.$

[0126] This equation may be applied to opposing vertices within a given quadrilateral in order to determine which pair has the “strongest” color change. Using this technique requires no additional data to be transferred during encoding since the split bit is calculated as a function of the color values (which are sent anyway). Compression efficiency is advantageously increased. It is noted, however, that while this technique is appropriate for color determination, it may be incorrect for lighting computations. That is, the split direction may produce a “smoother” color flow, but may produce a less realistic lighting effect. For this reason, in an alternate embodiment, the correct split direction may be determined after lighting.

[0127] As an example of the use of the difference function, consider a 5×5 mesh with vertices 0 to 24. A particular quadrilateral is denoted by vertex n, where n is the upper right vertex in the quadrilateral (hence n may take the values 6-9, 11-14, 16-19, and 21-24). The difference equation may thus be applied to pairs (n−6, n) and (n−5, n−1). If the (n−5, n−1) pair has the greater difference function, the quadrilateral is split in the default tessellation direction (lower left vertex to upper right). Alternatively, the quadrilateral is split from the upper left to lower right vertex if the (n−6, n) pair has the greater difference function. It is noted that the above equation is an approximation of red-green-blue to black and white color space conversion.

[0128] It is noted that in a different embodiment, an alternative difference function may be used. Similarly, encodings of split direction may also differ in other embodiments. It is further noted that the automatic split determination may be enabled/disabled through the use of a mode bit in one embodiment.

[0129] FIGS. 19-21—Half-resolution Mode

[0130] One common artifact in 3-D graphics is when an object in the background of a scene (represented in low resolution) moves to the foreground of a scene (into high resolution). Typically this transition from low to high resolution occurs as a heavyweight switch, resulting in an unappealing (and unrealistic) visual effect. One solution to this problem is to represent the edge (or edges) of a surface portion of an object in an intermediate resolution during the transition from low to high resolution. This representation is referred to as “half-resolution”, or “half-rez”, mode. The use of this mode is described below as it relates to vertex rasters, although half-rez mode is also applicable to generalized triangle mesh formats.

[0131] Referring now to FIG. 19, the format of the “SetEdgeHalfRez” command is shown. As depicted, the command includes four one-bit operands (el, et, er, and eb), which may be used to independently set half-rez mode for each of the four sides of the current vertex raster. (Note that when half-rez mode is used without vertex raster mode, only the top and bottom bits are applicable in one embodiment).

[0132] FIGS. 20A-D illustrate surface portions with each of the four bits turned on. For example, surface portion 800A shown in FIG. 20A has the “el” (left edge) bit turned on. Surface portions 800B-D shown in FIGS. 20B-D have the “er”, “et”, “eb” bits set respectively. Note that any combination of the four bits may be set (that is, a surface portion may have more than one edge represented in half-rez mode).

[0133] The use of half-rez mode allows more realistic visual effects. As an object moves from low-resolution to high-resolution (or vice-versa), surface portions may be intermediately represented as half-resolution. In this manner, a “patch” may adapt its tessellation to what is required in the area.

[0134] An example of half-rez mode is given by surface portion 810 in FIG. 21. As shown, surface portion 810 includes sub-portions 810A-D. Sub-portion 810A, being closest to the viewer, is represented as a 9×9 square grid of vertices, while sub-portions 810B-D (which are farther away) are represented as 5×5 arrays of vertices. In order to lessen the abruptness of the resolution change between surface sub-portions 810, two edges of sub-portion 810A are represented in half-rez mode.

[0135] FIG. 22—Decompression Hardware

[0136] A block diagram of one embodiment of graphics accelerator 112 depicted in FIG. 3 is shown with reference to FIG. 22. As shown, graphics accelerator 112 receives a compressed geometry stream 904. Stream 904 may be conveyed from main memory via a system bus, or from a separate computer system via a network. Compressed geometry stream 904 may include 3-D geometry data compressed using a variety of different techniques, such as those disclosed herein and in the Applicant's parent patent application. Compressed geometry stream 904 may also include uncompressed 3-D geometry data. Both the compressed and uncompressed geometry data describes vertices (and associated attributes) which are usable for assembling into drawing primitives (typically triangles) which may then be rendered by a graphics pipeline. Stream 904 also typically includes control information for the corresponding data.

[0137] The data in geometry stream 904 is conveyed to a geometry decompression unit (GDU) 910. In one embodiment, GDU 910 receives stream 904, compresses any compressed geometry data, and assembles a plurality of drawing primitives using connectivity information specified in stream 904. As will described below, GDU 910 includes a mesh buffer 912, which is usable for decompression of geometry data represented in vertex raster or generalized triangle mesh format. The primitives assembled by GDU 910 are then conveyed to one or more front-end processing units 920. Although two units (920A-B) are shown in FIG. 22 for simplicity, graphics accelerator 112 may include other configurations in alternative embodiments.

[0138] In one embodiment, mesh buffer 912 includes a fixed number of storage locations usable for storing parameter values associated with one or more vertices. In this manner, vertices (and corresponding parameters values) which are used in forming multiple primitives may be pushed into mesh buffer 912 upon first use. When later needed, these values may be accessed from mesh buffer 912 which avoids the need to re-specify these vertices in compressed stream 904. In one embodiment, mesh buffer 912 is organized as a stack, and is accessed by providing an offset into the stack.

[0139] Generally speaking, front-end processing units 920 are responsible for transforming vertices from a model space coordinate system (typically defined by the graphics program which generated the geometry data) to a coordinate system specified by the display device. This series of steps, commonly referred to as the front-end of the graphics pipeline, includes such operations as modeling transformation, perspective division, clipping, trivial rejection of primitives, and screen space transformation. The drawing primitives generated by processing units 920 are represented in a coordinate system (screen or device space) which may easily be drawn by rasterization unit 930.

[0140] In one embodiment, rasterization unit 930 receives drawing primitives represented in device space coordinates. Rasterization unit 930 then renders these primitives on display device 84 using processes such as edge interpolation, span interpolation, and texture mapping. Unit 930 may optionally include a z-buffer unit for performing hidden surface removal.

[0141] In an alternate embodiment of graphics accelerator 112, GDU 910 performs decompression of stream 904, but does not assemble the vertices into triangle primitives. Instead, the vertices are tagged and conveyed to front-end processing units 920. Similar to the embodiment described above, units 920A-B perform transformation operations on the received vertices, outputting vertices represented in device coordinate space. Concurrently, GDU 910 sends connectivity information to rasterization unit 930, referencing the tagged vertices being processed by units 920. In this embodiment, rasterization unit 930 assembles the received vertices into primitives for rendering on display device 84.

[0142] FIGS. 23-25—Decompression Flowcharts

[0143] A generalized flowchart depicting a decompression method 930 according to one embodiment of the present invention is shown with reference to FIG. 23. As shown, method 930 first includes a step 932, in which an extent of the surface portion being represented is set within a decompression unit, such as GDU 910 shown in FIG. 22. In one embodiment, the extent of a surface portion may be encoded using a format such as the “SetVertexRasterSize” command described above with reference to FIG. 7. Other encodings for the extent value may be utilized as well in other embodiments.

[0144] The extent value indicates to the decompression hardware the arrangement of vertices within the surface portion. This allows the decompression hardware to properly connect a stream of vertex data into the correct drawing primitives. In different embodiments, the extent value may indicate the shape of a surface portion, the number of vertices within the surface portion, or both. The extent value may also be a value which indicates that the vertices of the surface portion being represented are arranged according to one of a predefined number of arrangements recognized by GDU 910. As described above, the “SetVertexRasterSize” command specifies that the surface portion includes either 25, 81, or 289 vertices arranged in a regular grid with an equal number of rows and columns. In a different embodiment, this command may specify that the grid is organized in an alternate fashion.

[0145] Method 930 next includes steps 934 and 936, in which global parameter values and corresponding delta values are initialized. In one embodiment, step 934 includes decoding the “SetVertexRasterStart” command described above with reference to FIG. 8. Execution of this command, in one embodiment, sets initial values in vector registers 0-4. Each of the 5 vector registers is predefined to represent a specific vertex parameter. In alternate embodiments, other vertex parameters may be added as well. These initial values of the vertex parameters typically correspond to values of the vertex parameters at the first vertex traversed within the surface portion (see FIG. 9).

[0146] In one embodiment, step 936 includes decoding the “SetVertexRasterStep” commands described above with reference to FIGS. 10A-B. Execution of this command, in one embodiment, sets delta values for the predetermined vertex parameters corresponding to the registers. It is noted that even though a register is reserved for a particular vertex parameter (e.g., color), for a given surface portion, that vertex parameter may not necessarily be specified in a given geometry stream.

[0147] As described above, there are two “step” commands specified in one embodiment of the present invention. One step command sets delta values for components of a specified vertex parameter along a first direction (such as the direction taken when traversing vertices along a given row of the surface portion). A second step command sets delta values similarly along a second direction (such as between columns) within the surface portion.

[0148] As described above, specifying vertex parameter values in the manner described above (steps 934 and 936) is referred to as global parameter specification. This is in contrast to the per-vertex (or local) specification of vertex parameter values also employed according to one embodiment of the present invention. Global parameter specification may be performed differently in other embodiments. For example, changes in a vertex parameter may be specified through initial values and one or more equations which define the parameter relative to its position within the vertex traversal order. Other techniques are also possible. It is further noted that it is possible to represent a surface portion as a vertex raster without encoding any globally specified parameters. Compression is still achieved since the connectivity (and, hence, the mesh buffer push bits) are specified implicitly by the extent value.

[0149] Method 930 next includes step 938, in which GDU 910 (or other decompression unit) begins accessing the stream of per-vertex data which includes local values for the vertex parameters. As described above, in one embodiment, specification of an extent value implies a predefined vertex traversal order. Furthermore, in one embodiment, it is known before receiving the per-vertex data, what parameters are specified for each vertex. (In one embodiment, this information is determined by control commands such as those described with references to FIGS. 13A-B). With the number of vertices known, as well as the number of parameters per vertex, the stream of per-vertex data may be accurately processed.

[0150] Consider a given surface portion with two parameters (color and normals) specified locally. If it is known that only two parameters are specified for each vertex, GDU 910 can correctly determine that after accessing two values at the beginning of the stream of per-vertex data, subsequent parameter values are associated with the next vertex in the vertex traversal order. In such a manner, GDU 910 is able to access local parameter values for the first (or next) vertex specified by the current vertex raster representation.

[0151] The stream of per-vertex data may be encoded using a variety of different techniques. In one embodiment, each of the parameters in the per-vertex stream is of a predetermined length, facilitating the retrieval of data. In a preferred embodiment, the per-vertex stream is encoded using the header-body technique described in the Applicant's parent patent application. Generally speaking, the per-vertex data includes fixed-length header portions which are usable to determine a length of a corresponding variable-length body portions. Each header-body pair includes a data portion that includes one or more local data values. The data portion may be included wholly in the fixed-length header (indicating a zero-length body portion), wholly within the body portion, or in both the header and body. To implement a high-speed decompression unit, header and body pairs may be separated in the data stream by header and body pairs of other instructions.

[0152] For example, consider the following sequence of header-body pairs: H1, B0, H2, B1, H3, B2, etc. This indicates that header-body pair H1-B1 are separated within the per-vertex stream by the body portion of the previous pair (B0) and the header portion of the next pair (H2). This allows GDU 910 sufficient time to determine the length of the corresponding body portion. In one embodiment, the body length is determined by presenting the fixed-length header portion to a decompression table. (In one embodiment, there is a separate decompression table for each type of parameter). In response, the decompression table returns one or more decompression parameters corresponding to the current header-body pair being processed. These decompression parameters may include, but are not limited to, the amount of the data portion present in the header portion, the length of the body portion, whether the values in the data portion are absolute or relative, and a normalization coefficient for the values in the data portion.

[0153] As described above, various decompression parameters are specified, in one embodiment, for each header-body pair (which includes a vertex parameter value for the current vertex being processed). In step 940, these decompression parameters and the globally specified values are utilized to generate a final vertex parameter value. In one embodiment, a final vertex parameter value may be generated a) solely from globally specified values, b) solely from the per-vertex stream, or c) using a combination of the globally specified values and the per-vertex data.

[0154] For case a), a final vertex parameter value is generated by applying the delta values to the current working value (which is either the initial value or the value for the previous vertex). For case b), the final parameter value is generated according to the manner in which the value is encoded. If the value is absolutely specified, the normalization coefficient (if any) is applied to the value in the data portion in order to generate the final value. If the per-vertex value is delta-encoded, the normalized data value is added to the value of the parameter at the previous vertex.

[0155] Compression according to the present invention also allows delta-delta encoding of values in one embodiment. This is useful if a certain vertex parameter changes in a slightly irregular fashion. (In many instances, the delta-delta value for a particular vertex may be zero, effectively indicating the last delta is to be applied again to generate the final parameter value for the particular vertex). In one embodiment, the use of delta-delta encoding is enabled through a control instruction such as the “SetState” command described above with reference to FIG. 13A. In this embodiment, setting of the dde bit alters the interpretation of the absolute/relative bit within the decompression table, causing an absolute setting within a decompression table to indicate relative (delta) encoding, with relative encoding now specifying delta-delta encoding. Because delta-delta values may in some instances be smaller than delta values, compression efficiency is enhanced through the use of this technique. Thus, to generate a final vertex parameter for case c), the parameter value for the previous vertex, the previous delta, and the delta-delta value for the current vertex are all added.

[0156] With the final parameter values generated for a particular vertex in step 940, a determination is made whether to perform a mesh buffer push in step 942. This determination is made using the previously specified extent value as well as the current vertex position. For example, in one embodiment, it is predetermined that the entire first row of vertices are all pushed into the mesh buffer for later use. This push operation is performed in step 944. In one embodiment, the vertex and all associated parameters are all pushed into the mesh buffer.

[0157] In step 946, a determination is made whether or not a primitive is to be assembled. For example, in one embodiment, no primitives are assembled until vertices on the second row are accessed. For the vertices on the first row, then, step 950 is performed subsequent to step 946. If the determination is made that a primitive is to be assembled, method 930 next proceeds with step 948.

[0158] In step 948, connectivity information is analyzed in order to determine which vertices are to be used (in addition to the current vertex) in order to assemble the drawing primitive. In one embodiment, connectivity information includes that implicitly defined by the extent value as well as quad split information. It is noted that after processing a given vertex, a plurality of primitives may be formed. Accordingly, after execution of step 948, method 930 returns to the determination step of 946.

[0159] Once all primitives have been assembled for the current vertex, a determination is made in step 950 whether the current vertex is the last vertex (as specified by the previously specified vertex traversal order) within the surface portion. If the current vertex is not the last vertex, the next vertex is processed in step 938 and execution of method 930 continues. If the current vertex is the last vertex, however, method 930 concludes with step 952.

[0160] If a step vertex raster command is executed subsequent to completion of method 930, the next surface portion may be processed by using the values of the global parameters from the last vertex of the previous raster representation and proceeding to step 938 of method 930. The next stream of per-vertex data may then be processed as described above.

[0161] Method 930 described above gives a general overview of one embodiment of the decompression process. Method 960, shown in FIG. 24, provides a more detailed implementation which handles both implicit and explicit connectivity information. Method 960 is first described with reference to surface portion 300 depicted in FIG. 6, in which the quadrilaterals formed by neighboring vertices are all split in the same (default) direction. For purposes of the following examples, the vertex traversal order is assumed to be that shown in FIG. 9 (beginning from the lower left corner). Accordingly, the vertex numbers utilized in the following examples may be understood from FIG. 9. For instance, vertex 2 is the middle vertex on the bottom row in each of the examples given below. It is noted that many other vertex traversal orders are also possible. It is further noted that any of the procedures for generation of final parameter values may be employed within method 960.

[0162] FIG. 23 describes the notion of forming a primitive. With reference to FIG. 24, a primitive is considered to be formed when all of its vertices are “drawn” (passed to units 920 for processing). In one embodiment, replacement codes such as those used in generalized triangle strip format dictate how drawn vertices are combined to form triangle primitives.

[0163] Proceeding from initial state 962, method 960 proceeds to step 964, in which a vertex and its associated parameters are accessed from compressed geometry stream 904 by GDU 910. For the first row of vertices in surface portion 300 (vertices 0-4), all vertex parameter values are pushed into mesh buffer 912 in step 966. These vertices are not drawn, however, indicating that no primitives are formed. A determination is made in step 968 as to whether the current vertex is the last vertex of the first row. If the current vertex is not the last vertex of the first row, method 960 returns to step 964 and processes the next vertex.

[0164] If the current vertex is at the end of the first row, however, the first vertex of the current row (vertex 0 in FIG. 9) is accessed from mesh buffer 912 and drawn in step 970. The attributes of this vertex are next loaded into GDU 910 registers in step 972. These loaded values are used, if needed, to calculate parameters values of the first vertex of the next row (vertex 5), which are accessed in step 974. The parameters of vertex 5 are also pushed into mesh buffer 912 and then drawn in step 974.

[0165] In step 976, a determination is made as to whether a quad split bit is set for the current quadrilateral within compressed geometry stream. In one embodiment, a de-asserted quad split bit indicates that a quadrilateral should be tessellated in the default direction (upper right corner to lower left). If this bit is set, however, the quad is split from the upper left corner to lower right. If a quad split bit is not specified, the quad is tessellated in a predetermined default direction in one embodiment.

[0166] In one embodiment of a vertex raster representation of surface portion 300, no quad split bits are set. Accordingly, method 960 proceeds to step 978, in which parameters of the next vertex of the current row (vertex 6) are accessed. These parameters are pushed into mesh buffer 912 and the vertex is drawn in step 980. A first triangle primitive within surface portion 300 is now formed, with vertices 0, 5, and 6 all being drawn. The next triangle primitive is formed in step 982, in which the next vertex of the previous row (vertex 1) is drawn. This steps effectively forms the primitive defined by vertices 5, 6, and 1.

[0167] In step 990, the current vertex is tested to determine if it is the last vertex in the current row. If the vertex is not the last in the current row, method 960 returns to step 976 to check the next quad split bit. Method 960 continues as described above, forming the remaining triangle primitives between the bottom two rows of vertices. When the last vertex in the second row is detected in step 990, a further check is made in step 992 to determine if the current vertex is the last in the surface portion. Since this is not the case in this example, method 960 proceeds with step 970, in which the first vertex of the current row (vertex 5) is accessed from mesh buffer 912 and drawn (again). Then vertex 10 of the third row is drawn in step 974. The quad split bit for this vertex is checked in step 976, and formation of triangle primitives continues as described above. Method 960 eventually exits at step 994 when vertex 24 is detected in step 992.

[0168] Next, method 960 is described using surface portion 700 as input. Method 960 begins as described above, accessing vertex parameter values for vertices 0-4 and pushing these values into mesh buffer 912 in steps 964-966. When vertex 4 is detected in step 968, vertex 0 is retrieved from mesh buffer 912 in step 970. Then the attributes of vertex 5 are accessed from stream 904 and drawn in step 976. So far, the steps for surface portion 700 correspond to those taken for surface portion 300, with vertices 0 and 5 both being drawn.

[0169] Since the quad split bit for the first quadrilateral in surface portion 700 is split, however, method 960 next proceeds to step 984, in which the next vertex of the previous row (vertex 1) is accessed from mesh buffer 912 and drawn. This forms a triangle defined by vertices 0, 5, and 1. In steps 986 and 988, a second triangle is formed from vertices 5, 1, and 6. Method 960 then returns to step 976, where the next quad split bit is checked. Based on the result of this determination, two more triangles are formed and the method returns to step 976. When all triangles are formed for the current row, method 960 returns to step 970. Decompression of the remainder of surface portion 700 proceeds as described above.

[0170] FIG. 25 depicts a method for decompressing a surface portion in which a bottom edge is designated as being half-rez (as described above with reference to FIG. 19). One example of such a surface portion is portion 800D in FIG. 20D. As depicted in FIG. 20D, some vertices on a half-rez edge are not utilized in forming any of the triangle primitives within surface portion 800D. Method 1000 shown in FIG. 25 accounts for this fact.

[0171] From initial state 1002, method 1000 proceeds to step 1004, in which the first vertex (vertex 0) is accessed from stream 904. Vertex 0 and its attributes are pushed into mesh buffer 912 in step 1006. Vertex 1 and associated parameters are accessed in step 1008. Because vertex 1 is not utilized for triangle formation, however, the attributes accessed in step 1008 are not used. In spite of the fact that these attributes are not used, a dummy mesh buffer push is performed in step 1010. This is done so that subsequent rows may access mesh buffer 912 in the same fashion whether or not the bottom edge is represented in half-rez mode or not.

[0172] In steps 1012-1014, vertex 2 and its attributes are retrieved from stream 904 and pushed into mesh buffer 912. Since vertex 2 is not the last vertex in the row, method 1000 returns to step 1008. This results in vertex 3 being allocated a dummy position in mesh buffer 912, and vertex 4 having its attributes pushed into an “actual” position within mesh buffer 912.

[0173] At this point, vertices 0-4 are pushed into mesh buffer 912 with either placeholder or actual entries. Method 1000 next proceeds to steps 1018-1020, in which vertex 0 is accessed from mesh buffer 912 and drawn. In step 1022, vertex 5 is accessed from stream 904, drawn, and pushed into mesh buffer 912. Next, vertex 6 is accessed, drawn, and pushed in step 1024. This completes formation of the triangle primitive defined by vertices, 0, 5, and 6.

[0174] Method 1000 continues with step 1026, in which the next vertex from the previous row whose attributes have not been dropped is drawn. This corresponds to vertex 2, since vertex 1 is not used in triangle formation This step also completes formation of the triangle defined by vertices 0, 2, and 6. (These vertices are used instead of three most recently drawn vertices since half-rez edges correspond to “star” triangle strips. These formations are drawn in generalized triangle strip format using the “replace middlest” vertex command). Next, in step 1028, the next vertex from the current row, vertex 7, is accessed, pushed, and drawn, forming a primitive from vertices 6, 2, and 7.

[0175] In step 1030, a determination is made that the end of the row has not been reached. Thus, method 1000 continues with step 1024. Steps 1024-1028 repeat, forming three primitives using vertex groups (2, 7, 8),(2, 8, ,4) and (8, 4, 9), respectively.

[0176] With the first row of primitives drawn, method 1000 continues processing by executing steps 970-994 of method 960 until the last vertex of surface portion 800D is reached.

[0177] Method 1000 is usable to perform decompression on a regularly tiled surface portion in which the bottom edge is represented in half resolution. Decompression of surface portions in which other edges are represented in half-rez is performed similarly. For more information, refer to related co-pending application entitled “Method of Producing a Sequence of Triangles From a Vertex Raster With and Without Half Resolution Edges While Decompressing a Compressed Geometry Stream”, filed Jan. 15, 1998 by Jeffrey M. Chan. It is noted that in alternate embodiments, quad split bits and half-rez edges may be processed differently.

[0178] Although the system and method of the present invention have been described in connection with the described embodiments, it is not intended to be limited to the specific form set forth herein, but on the contrary, it is intended to cover such alternatives, modifications, and equivalents, as can be reasonably included within the spirit and scope of the invention as defined by the appended claims.