A computing-device implemented method for compressing data, where such devices include a computer, personal digital assistant (PDA), home appliance, and the like. The data includes bandwidth intensive information such as that used in video conferencing, MPEG and equivalent types of digital video encoding, multi-media data transfers, and interactive gaming. In one implementation, a 3D model has objects defined therein. Each object is defined according to a data collection, each element within the collection having a first data size. A distance is determined between a reference point in the model, and a bounding box for an object. A data reduction factor is selected based, at least in part, on the distance. The data collection is compressed according to the distance by mapping each data of the first data size to data having a second data size smaller than the first data size. Other compression methods and apparatus are disclosed.
|
1. A computing-device implemented method for compressing and transferring model data from a content provider to a recipient, comprising:
determining a zoom range for a model object defined according to a data collection of data elements, each data element within the data collection having a spatial location defined at least in part with a standard-format floating point number having a first data size; selecting a data reduction factor based at least in part on the zoom range; and compressing the data collection according to the zoom range by mapping each standard-format floating point number of the first data size to data having a second data size smaller than the first data size.
10. A computing-device implemented method for data decompression, such data having been compressed by determining a zoom range for a model object defined according to a data collection having elements of a first data size, selecting a data reduction factor based at least in part on the zoom range, and compressing the data collection according to the zoom range by mapping each data of the first data size to data having a second data size smaller than the first data size, the method comprising:
receiving a compressed data collection corresponding to a model object; and expanding the data collection according to a predetermined expansion factor by mapping each data of the second data size back to data having the first data size.
11. An article of manufacture comprising:
a machine readable medium; and a plurality of instructions stored on the machine readable medium to implement a method for compressing and transferring model data from a content provider to a recipient, such that, when executed, the plurality of instructions cause a processor to: determine a zoom range for a model object defined according to a data collection of data elements, each data element within the data collection having a spatial location defined at least in part with a standard-format floating point number having a first data size; select a data reduction factor based at least in part on the zoom range; compress the data collection according to the zoom range by mapping each standard-format floating point number of the first data size to data having a second data size smaller than the first data size; determine a length n based at least in part on the zoom range; convert each standard format floating point number into a nonstandard-format floating point number comprising an n-bit length mantissa and an optional sign-bit; construct a transmission packet comprising plural nonstandard-format floating point numbers of equal bit-length followed by a stop word; and provide the transmission packet to the recipient. 12. An article of manufacture comprising:
a machine readable medium; and a plurality of instructions stored on the machine readable medium to implement a method for compressing and transferring model data from a content provider to a recipient, such that, when executed, the plurality of instructions cause a processor to: determine a zoom range for a model object defined according to a data collection of data elements, each data element within the data collection having a spatial location defined at least in part with a standard-format floating point number having a first data size; select a data reduction factor based at least in part on the zoom range; compress the data collection according to the zoom range by mapping each standard-format floating point number of the first data size to data having a second data size smaller than the first data size; provide a directed graph, such graph comprising a start node, interior nodes, and leaf nodes, each interior and leaf node storing a binary value, such that a recording of a graph traversal from the start node to a particular leaf node corresponds to a particular floating point bit sequence; and truncate each standard-form at floating point number by traversing the directed graph according to the bit values within such standard-format floating point number, and replacing such standard-format floating point number with a record of such traversal; wherein different traversals of the graph can yield records of differing lengths. 13. An apparatus comprising:
a processor; and a machine readable medium, coupled to said processor, having stored thereon a plurality of programming instructions to implement a method for compressing and transferring model data from a content provider to a recipient, such that when executed by the processor the instructions operate to: determine a zoom range for a model object defined according to a data collection of data elements, each data element within the data collection having a spatial location defined at least in part with a standard-format floating point number having a first data size; select a data reduction factor based at least in part on the zoom range; compress the data collection according to the zoom range by mapping each standard-format floating point number of the first data size to data having a second data size smaller than the first data size; provide a directed graph, such graph comprising a start node, interior nodes, and leaf nodes, each interior and leaf node storing a binary value, such that a recording of a graph traversal from the start node to a particular leaf node corresponds to a particular floating point bit sequence; and truncate each standard-format floating point number by traversing the directed graph according to the bit values within such standard-format floating point number, and replacing such standard-format floating point number with a record of such traversal; wherein different traversals of the graph can yield records of differing lengths. 2. A method according to
determining a length n based at least in part on the zoom range; and converting each standard-format floating point number into a nonstandard-format floating point number comprising an n-bit length mantissa and an optional sign-bit.
3. A method according to
constructing a transmission packet comprising plural nonstandard-format floating point numbers of equal bit-length followed by a stop word; and providing the transmission packet to the recipient.
4. A method according to
for each standard-format floating point number, determining a truncation factor based at least in part on the zoom range; converting each such standard-format floating point number into a nonstandard-format floating point number truncated according to the truncation factor; and constructing a transmission packet comprising at least one pairing of an indicator field followed by a following nonstandard-format floating point number; wherein the indicator field identifies a bit length for each following nonstandard-format floating point number.
5. A method according to
for each standard-format floating point number, determining a truncation factor based at least in part on the zoom range; converting each such standard-format floating point number into a nonstandard-format floating point number truncated according to the truncation factor; and constructing a transmission packet comprising groupings of plural indicator fields having fixed length followed by corresponding nonstandard-format floating point numbers, such indicators indicating the bit length for such corresponding numbers; and packing the transmission packet into a first data word, wherein packing includes determining whether the transmission packet is larger than the first data word, and if so, packing a remaining portion of the transmission packet into at least one subsequent data word.
6. A method according to
providing a directed graph, such graph comprising a start node, interior nodes, and leaf nodes, each interior and leaf node storing a binary value, such that a recording of a graph traversal from the start node to a particular leaf node corresponds to a particular floating point bit sequence; and truncating each standard-format floating point number by traversing the directed graph according to the bit values within such standard-format floating point number, and replacing such standard-format floating point number with a record of such traversal; wherein different traversals of the graph can yield records of differing lengths.
7. A method according to
constructing a transmission packet by packing truncated floating-point numbers into a first data word; wherein packing includes determining whether the transmission packet is larger than the first data word, and if so, packing a remaining portion of the transmission packet into at least one subsequent data word.
8. A method according to
providing the directed graph to the recipient; receiving a first transmission packet having n bits; preparing a first traversal record by traversing the directed graph according to the n-bit sequence within the first transmission packet; and if a leaf node is reached during such traversal, identifying the first floating point number as the first traversal record.
9. A method according to
receiving a second transmission packet having m bits; and if a leaf node is not reached after the n-bit traversal, then continuing traversing the directed graph according to the m-bit sequence within the second transmission packet; and if a leaf node is reached during such traversal, identifying the first floating point number as the combined bit sequences traversed from the first and second transmission packets.
|
The present invention generally relates to the fields of data compression, and more particularly, to compressing 3D multimedia transfers over a network connection.
3D multimedia includes video conferencing, interactive games, web-page content, audio/visual (A/V)recordings, to name but a few (hereafter collectively "A/V data"). A/V data requires significant storage space, as well as substantial bandwidth to transmit the data over a network. Since most data recipients do not have sufficient bandwidth to receive the A/V data in its original form, A/V data has traditionally been retrieved over a local high-speed bus or specialized high-speed data links.
For example, consider computerized games. Games include simple single-user simulators for pinball, cards, gambling, fighting, etc., or more complex multiple-player turn-taking games where each player competed against the game and ultimately compared scores. Well-known high-tech gaming systems include the Nintendo® and Sony PlayStation® gaming systems. These and other games use geometry to describe two and three-dimensional objects within gaming models. In particular, complex object surfaces are usually represented by a combination of one or more basic object shapes, such as splines, non-uniform rational splines (NURBs), texture maps, and (monohedral) triangle tesselation. Typically, an arbitrary object is defined by triangle tesselation, each triangle having associated spatial coordinate tuples X, Y (and perhaps Z), color, normal, and other attributes. This information, when multiplied by hundreds or thousands of polygons in moderately complex objects, amounts data that must be retrieved from dedicated graphics systems and local storage of graphics data. The data transfer requirements prohibit play against remote players. Although some games have been designed to use a modem to directly call a remote player and establish a game, this solution was often clumsy, slow, and inconsistent; rich content transfer was infeasible.
Or, consider video conferencing applications. As with games, these applications concern transferring large volumes of data. However, these applications must transfer the data to remote locations (e.g., conference participants). Therefore, they have required high-speed data links, e.g., at a minimum, a 128 K-bit bonded ISDN connection to the remote participant, or more preferably, a T1 or faster frame-relay connection. Unfortunately, these speedy connection backbones are not generally available to users, and require complex technical support to maintain an active link. Conferencing also shares the modem-game limitation of requiring direct user-to-user connections.
With the recent advent of ubiquitous low-cost Internet connections, it has become a relatively straightforward matter to form a network communication link between multiple remote participants. This has spurred interest in using these generally available links to transfer A/V data. Unfortunately, due to the cost and technical complexity of maintaining ISDN, Frame Relay, and other high-speed links, Internet connections are commonly relatively slow modem-based connections. Since modem connections only generally realize an average modem bit rate of 14-40 KBits per second, these connections are not able to transfer, in reasonable time, rich game content, conferencing data, or other A/V data. This problem is exacerbated with each additional remote participant, since A/V data must now be distributed to multiple recipients--further consuming bandwidth resources.
In an effort to reduce bandwidth constraints, and take advantage of the easily-available slow networking connections, there have been efforts to compress A/V data. For example, data and geometry compression has previously been used to reduce information content in 2D and 3D models. Previous compression attempts include image compression (e.g., JPEG), defining objects with shared features (e.g., shared edges), small texture maps for large areas, etc. Examples of some of these and other techniques can be found in U.S. Pat. No. 5,740,409 which teaches a 3D graphics accelerator for compressed geometry, and U.S. Pat. Nos. 5,793,371, 5,867,167, and 5,870,094 which teach various methods for more-efficiently encoding 3D models. These compression techniques are readily applicable to A/V game data (which use models), as well as other A/V data representing data in a compatible compressible format, such as Moving Picture Experts Group (MPEG) digital video encoding.
In addition to geometry compression, general purpose data compression procedures has also been applied to A/V data. Such techniques include Huffman encoding (See Huffman, "A Method For Construction Of Minimum Redundancy Codes", Proceedings IRE, 40, 10 pages 1098-1100 (September 1952)), Tunstall encoding (See Tunstall Doctoral thesis, "Synthesis of Noiseless Compression Codes", Georgia Institute of Technology (September 1967)), and Lempel-Ziv encoding (See "A Universal Algorithm For Sequential Data Compression", IEEE Transactions on Information Theory, IT-23, 3, pages 337-343 (May, 1977)), and run-length encoding of model data (see, e.g., U.S. Pat. No. 3,656,178). These general purpose compression techniques are applicable to all data formats.
Unfortunately, even after application of general purpose and geometric compression, there still remains a significant amount of information that needs to be transferred before games, conferencing, viewers of 3D multimedia, interactive 3D chat rooms, and other applications of A/V data appear to operate as if they are retrieving their data from local storage or high-speed links. Thus, some further data reduction is needed.
A computing-device implemented method for compressing data, where such devices include a computer, personal digital assistant (PDA), home appliance, and the like. A distance is determined between a reference point in a model, and a bounding box for a model object defined according to a data collection, each element within the collection having a first data size. A data reduction factor is selected based, at least in part, on the distance. The data collection is compressed according to the distance by mapping each data of the first data size to data having a second data size smaller than the first data size. Other compression methods and apparatus are disclosed.
Although the present invention is applicable to a wide range of application programs, services, and devices which require transmitting rich content (such as A/V data) over a network, the following description focuses on delivering rich multimedia content from a gaming environment to players distributed over the network. The gaming paradigm has been chosen since it teaches delivery of A/V data as required for applications such as video conferencing, while also discussing the logistical complexity inherent in having multiple participants interactively affecting the delivery of A/V data.
As shown multiple players 102-108 are in communication with a content provider. In one embodiment, the players utilize an Internet browser as a playing device, where the browser has an installed plug-in (e.g., helper application) to aid in processing content transmitted by the provider. However, instead of a browser, other network application programs, such as dedicated gaming applications, can be used. For simplicity, it is assumed that the provider 100 acts as a central data distribution point for game data, transmitting all required data to each player 102-108. However, it is understood that gaming software can be configured so that players directly send each other information, or that one player or other network location may be used as a distribution point for other players (e.g., to distribute processing load).
Also shown is a game coordinator 112 that can be used as a central point for initiating or joining in to games in progress. Such a coordinator is useful in contexts such as the Internet, since players are routinely assigned random network addresses by their Internet Service Provider. Since a network connection between computers usually requires the computers to know each others' network address, a known coordinator can facilitate such connections by allowing players to contact the coordinator and publish their currently assigned network address. The coordinator can then redirect interested players to one or more content providers (e.g., 100). A coordinator may also be used to hide player identities from content providers, such as through network address hiding, or to coordinate player registration with different providers. Many corporations are now providing centralized "hubs" to facilitate game play; see, e.g., the MSN Gaming Zone (formerly the Internet Gaming zone) by Microsoft Corporation of Redmond Washington at http://games.msn.com or http://www.microsoft.com/games.
Typically, when a player contacts a provider, the provider attempts to transmit game content to the player. If the player's browser is not yet configured to receive such content, this can trigger an automatic notification to the player to install the requisite plug-in, driver, or other data needed to play the provider's game.
Once a player has come into communication with a content provider, the provider must send game content to the player. As discussed above, various methods have been employed to reduce the amount of data that actually needs to be sent to such players. A significant amount of such data includes transmitting coordinate values for objects within a 3D model. It is advantageous to somehow further reduce the amount of space required for storing such coordinates.
A 3D game model generally includes multiple objects, such as objects representing each player (e.g., a car or a ship), and objects for things present within the game environment (e.g., walls, trees, rocks, asteroids, scenery, background, etc.). Each object is typically defined by many triangles (e.g., hundreds or thousands), where each triangle has associated attributes such as spatial position, orientation, appearance, etc. The more realistic an object, the more triangles are needed to represent it. (Note that triangles are not strictly necessary to represent an object, however current rendering engines usually require all objects to be broken down into triangle format as such engines have hardware support for displaying triangles.)
Each triangle has a spatial location defined by 3 vertices. In a 3D model, each vertex is defined by X, Y, and Z coordinates identifying its location in the game's 3D space. Each vertex coordinate is stored as a floating point number, usually in the illustrated single-precision 32-bit IEEE-754 format 200. Thus, each of the hundreds or thousands of triangles in an object may require up to 96 bits to represent the triangle. Note that 96 bits is an upper bound due to reductions according to vertex sharing, e.g., two adjacent triangles only require 4 vertices, not 6. As discussed above, other geometry compression and data reduction techniques can also be applied.
As shown, each single precision format floating-point number has an 8 bit exponent 204 and a 24 bit mantissa 206 (significand). (Note that the mantissa has 24 bit precision which only requires 23 bits, since for all non-zero numbers a leading 1 bit can be implied.) The exponent is stored in biased (i.e., excess-n) form, where a bias 208 is subtracted from a stored number to obtain its actual value. Thus, even for a small object defined by only 100 vertices, this object requires 9,600 bits (32×100×3) to represent the positions of each of the vertices. And, given that a game typically includes many objects, and several players that need to receive such position information, a significant amount of data must be transferred simply to identify object positions.
Consequently, a more compact method for encoding floating point values would lessen this burden. When defining a particular floating point format, the general problem is performing a trade off between the size of the mantissa 206 and the size of the exponent 204. That is, choosing between numeric accuracy and numeric range. Increasing the size of the mantissa gives better accuracy; increasing the size of the exponent increases the range of the numbers that can be represented. This balance between accuracy and range can be applied to reduce the overall number of bits required to store coordinate values for objects within a 3D model. When accuracy is not needed, the bit lengths can be reduced.
Generally floating point numbers are in the format of (-1)SignBit×Mantissa×2Exponent, where the mantissa corresponds to the fractional part of a real number, and the 2Exponent shifts the decimal point appropriately. One method of reducing floating-point storage requirements is to unitize all object coordinates with respect to a local origin for the bounding box. By unitizing values, storing an exponent is unnecessary since it can be now implied by the bit precision of a mantissa 218. That is, if the mantissa encodes the value 12345678 (base 10), it is known a priori that the value encoded is really 0.12345678 or 1.2345678×10-1. Implying the exponent represents an immediate 25% saving over traditional 32 bit formats. Note also that if all values are restricted to be positive, a further bit saving is possible by implying a sign bit 220 for positive values.
As shown in
For example, in one embodiment of the invention, suppose a model of size 10×10×10 is to be displayed, and that it includes a sub-model of size 2×2×2 at position 3×3×3. The sub-model includes, among other things, a vertex at position 3.21×3.21×3.21. Further, assume that the coordinate system is always normalized, and that exactly two digit precision is utilized. If the vertices of the sub-model are stored compared to the localized coordinates, then: the coordinates are restated with respect to the position of the sub-model: 3.21->0.21; the coordinates are scaled to the size of the sub-model; and, the coordinates are truncated to two significant digits. If the coordinates are unitized but not localized, then: the coordinates are not restated; the coordinates are scaled to the size of the model: 3.21->0.321; and, the coordinates are truncated to two significant figures: 0.321->32. Normally these operations are performed for each dimension of each vertex, however only one coordinate of one vertex has been discussed in this example.
In this embodiment, when compressed coordinates are restored, the operations are reversed. For localized coordinates: truncated figures are converted to a number, so 42->0.42; numbers are unscaled, so 0.42->0.21; and, coordinates are un-restated, so 0.21->3.21. For non-localized coordinates: truncated figureas are converted to a number, so 32->0.32; and, numbers are unscaled, so 0.32->3.2. (Note that the localized coordinates have remained the same, while the non-localized coordinates have moved slightly.)
Floating-point representations can be further compressed through specification of desired precision for stored values. That is, either through direct support by a model's developer, or through analysis of model data being sent to a player, floating-point values can be adaptively adjusted to suit expected use of a model's object. For example, a game developer can determine that, based on an object's predicted usage, n=6 bits is all that is required to encode an object's floating point values while still providing satisfactory visual performance. (Note that one can elect to keep an exponent component (e.g., not imply it), or choose to limit its precision in accord with the following discussion on limiting mantissa precision.) There are several conditions through which the need for precision can be determined by a model's developer, or automatically.
One such determination condition is when a designer, in designing a game, knows the expected uses for an object. In such cases, an object's representation can be tailored to reduce data space consumption. If, for example, it is known that a particular object represents background scenery that will always be "far away" from game players, then it is not necessary to maintain precise accuracy for feature coordinates. This is true because from a far distance, rendered object features will collapse and be indistinct. Therefore it is unnecessary to retain precise object feature data. (In fact, certain rendering systems will not even attempt to render object features when it is known that the feature would have a negligible impact on an output device (e.g., the screen).) In such circumstances, the precision available in a standard floating point value will be wasted, and a formula can be applied to truncate bit precision based on the theoretical distance of the object from viewers (e.g., players). The nature of the truncation formula depends on the distances involved.
Or, automatic truncation can be determined according to the offset 230 between bounding-box 222 origin and model origin (e.g., coordinate 0,0,0 for the model's 3D space). Distance-based precision reduction can also be determined according to distance between a viewing perspective and an object's bounding box 222. Thus, in a multi-user environment, each user will see different levels of detail according to their perspective on the model. The percentage of bit precision reduction can be computed as a linear reduction, stepwise grouping of distance ranges, or other formula. Distances can be compared against a maximum possible model (bounding) coordinate, a maximum-distanced object presently within the model, a maximum discernible distance (e.g., a distance beyond-which there is no effect on an output device), or some other criteria.
To recreate original model data, the offset 230 and distance-based scaling factor is tracked for the object 224, allowing its local coordinates to be converted back in to the model's coordinate system.
For a given vertex (feature point or otherwise), an evaluation is performed to determine the relative proximity of the given vertex 250, 252, to the other vertices for the object. When feature points are being used, the evaluation is made with respect to other feature points 254. The proximity evaluation is used to determine an additional percentage of reduction for coordinate encoding. Vertex proximity is roughly classified as being near, medium, and far. These classifications correspond to a respective 50%, 55%, and 60% reduction in floating-point precision reduction for coordinate values. (Note that these reduction factors are arbitrary.)
If we assume initial application of the
Additionally, precision determination can be adaptively modified according to dynamic player connection factors, such as network speed, efficiency, or load, and communication speed, latency, etc. Other characteristics of a model and its objects can also be used to determine a required precision for floating point values. However, once a particular precision is determined, floating-point values can be sent from a provider to a recipient as follows.
Also shown is an m-bit wide field 266 is used to flag the end of a vertex sequence. The size and necessity of this field will depend on the encoding arrangement utilized by a particular embodiment of the invention (e.g.,
As shown, initial entries 300, 302, 304 identify the sizes of vertices X 306, Y 308 and Z 310. As illustrated, X is 20 bits wide, which would correspond to the first field having a value of 12. Since the combination of the three fields and X is 32 bits, these items completely fill up one data word.
Y is 23 bits wide, corresponding to a second field 302 value of 15. Z 310, however, is only 8 bits wide. If one assumes a length of 8 bits, then the third field would be all zeros. Following the Z value is the beginning of the first field for the next trio of vertices. However, since Y 308 and Z 310 are 31 bits in length, only the first bit of the next first field 312 fits into the second data word. The remainder of field 312 is continued in the third data word, and so on.
It will be appreciated that the
In this configuration, floating point values can be arbitrarily truncated according to where leaf nodes are placed. That is, during encoding of standard floating-point values, the graph can be bit-wise traversed until a leaf node is reached. At such point, a record of the traversal corresponds to the new encoding (e.g., truncated) format for such standard floating-pint value. For example, a leaf node 338 can correspond to a truncated floating point value having mantissa bit sequence 000--the effect is to decide that for a particular model, no floating point value will have three leading zero bits. So, during encoding of a 32-bit binary value 110100100 . . . 001, it would be truncated into a 3-bit value of 110. Similarly, another leaf node 336 would correspond to a longer bit sequence 0110001, providing better precision. Assuming both the provider and recipient have a copy of this graph in local storage, decoding is trivial. For received vertex data, a bit-wise traversal of the graph will properly separate out vertex values. Leaf nodes imply value separation. Additionally, this format offers a modicum of error correction since an inability to consume all bits in an encoding sequence will indicate a transmission error, allowing for error recovery.
A first operation 350 is to define the object, where such object is ultimately defined according to plural triangles. The plural triangles are defined according to a set of vertices, which if geometry is being optimized, the vertices are being shared among the different triangles.
A subsequent operation 352 is to determine a floating-point precision for the object. As discussed above, this can be determined according to model developer identified zoom range for the object, or by other methods.
A subsequent operation 354 is to begin transferring an object's encoded data to a recipient. This operation takes place during game play, and at this point, the entire 3D model has previously been created, and statically identifiable precision determinations already defined for all objects. This operation includes, however, adjusting a current precision determination according to dynamic factors discussed above, such as intra-object proximity. On transfer of object data from a content provider 100 to a recipient, e.g., player 1 102, all vertex values are packaged 356 according to one of the methods illustrated above for
On receipt of the compressed vertex data, the player then re-expands 358 the vertex data back into a standard IEEE-754 format. This is performed since today's rendering hardware typically requires the data to be in a standard format. This operation is optional if a chipset for directly processing truncated floating point values as described herein is available.
After re-expansion 358, the object is integrated 360 into local model memory (or other storage) for use during game play. The net effect of the packaging 356 and expansion 358 compression process is to have fully formed floating point values in both the content provider 100 and player 102-108 environments, but where the client-side values have undergone loss of precision, that are insignificant to perceptual effects, to aid in transmission of the values.
FIG. 12 and the following discussion are intended to provide a brief, general description of a suitable computing environment in which the invention may be implemented. The invention may be described by reference to different high-level program modules and/or low-level hardware contexts. Those skilled in the art will realize that program module references can be interchanged with low-level instructions.
Program modules include procedures, functions, programs, components, data structures, and the like, that perform particular tasks or implement particular abstract data types. The modules may be incorporated into single and multi-processor computing systems, as well as hand-held devices and controllable consumer devices. It is understood that modules may be implemented on a single computing device, or processed over a distributed network environment, where modules can be located in both local and remote memory storage devices.
An exemplary system for implementing the invention includes a computing device 402 having system bus 404 for coupling together various components within the computing device. The system 404 bus may be any of several types of bus structure including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of conventional bus architectures such as PCI, AGP, VESA, Microchannel, ISA and EISA, to name a few. Note that only a single bus is illustrated, although plural buses typically achieve performance benefits. Typically, attached to the bus 402 are a processor 406, a memory 408, storage devices (e.g., fixed 410, removable 412, optical/laser 414), a video interface 416, input/output interface ports 418, and a network interface 420.
The processor 406 may be any of various commercially available processors, including Intel processors, or the DEC Alpha, PowerPC, programmable gate arrays, signal processors, or the like. Dual, quad processors, and other multi-processor architectures also can be used. The system memory includes random access memory (RAM) 422, and static or re-programmable read only memory (ROM) 424. A basic input/output system (BIOS), stored in ROM, contains routines for information transfer between device 402 components or device initialization.
The fixed storage 410 generally refers to hard drive and other semi-permanently attached media, whereas removable storage 412 generally refers to a device-bay into which removable media such as a floppy diskette is removably inserted. The optical/laser storage 414 include devices based on CD-ROM, DVD, or CD-RW technology, and are usually coupled to the system bus 404 through a device interface 426, 428, 430. The storage systems and associated computer-readable media provide storage of data and executable instructions for the computing device 402. Note that other storage options include magnetic cassettes, tapes, flash memory cards, memory sticks, digital video disks, and the like.
The exemplary computing device 402 can store and execute a number of program modules within the RAM 422, ROM 424, and storage devices 410, 412, 414. Typical program modules include an operating system 432, application programs 434 (e.g., a web browser or network application program), etc., and application data 436. Program module or other system output can be processed by the video system 416 (e.g., a 2D and/or 3D graphics rendering device), which is coupled to the system bus 404 and an output device 438. Typical output devices include monitors, flat-panels displays, liquid-crystal displays, and recording devices such as video-cassette recorders.
A user of the computing device 402 is typically a person interacting with the computing device through manipulation of an input device 440. Common input devices include a keyboard, mouse, tablet, touch-sensitive surface, digital pen, joystick, microphone, game pad, satellite dish, etc. One can also provide input through manipulation of a virtual reality environment, or through processing the output from a data file or another computing device.
The computing device 402 is expected to operate in a networked environment using logical connections to one or more remote computing devices. One such remote computing device 442 may be a web server or other program module utilizing a network application protocol (e.g., HTTP, File Transfer Protocol (FTP), Gopher, Wide Area Information Server (WAIS)), a router, a peer device or other common network node, and typically includes many or all of the elements discussed for the computing device 402. The computing device 402 has a network interface 420 (e.g., an Ethernet card) coupled to the system bus 404, to allow communication with the remote device 442. Both the local computing device 402 and the remote computing device 442 can be communicatively coupled to a network 444 such as a WAN, LAN, Gateway, Internet, or other public or private data-pathway. It will be appreciated that other communication links between the computing devices, such as through a modem 446 coupled to an interface port 418, may also be used.
In accordance with the practices of persons skilled in the art of computer hardware and software programming, the present invention is described with reference to acts and symbolic representations of operations that are sometimes referred to as being computer-executed. It will be appreciated that the acts and symbolically represented operations include the manipulation by the processor 406 of electrical signals representing data bits which causes a resulting transformation or reduction of the electrical signal representation, and the maintenance of data bits at memory locations in the memory 408 and storage systems 410, 412, 414, so as to reconfigure or otherwise alter the computer system's operation and/or processing of signals. The memory locations where data bits are maintained are physical locations having particular electrical, magnetic, or optical properties corresponding to the data bits.
Having described and illustrated the principles of the invention with reference to illustrated embodiments, it will be recognized that the illustrated embodiments can be modified in arrangement and detail without departing from such principles.
For example, while the foregoing description focused--for expository convenience--on compressing floating point values for vertices, it will be recognized that the same techniques and analyses can be applied to different numeric values needing transport between a content provider and a player (e.g., for compressing sound effects). Consequently, in view of the wide variety of alternate applications for the invention, the detailed embodiments are intended to be illustrative only, and should not be taken as limiting the scope of the invention. Rather, what is claimed as the invention, is all such modifications as may come within the scope and spirit of the following claims and equivalents thereto.
Smith, Peter D., Kenyon, Jeremy A.
Patent | Priority | Assignee | Title |
10467200, | Mar 12 2009 | Pegasystems, Inc. | Techniques for dynamic data processing |
10469396, | Oct 10 2014 | PEGASYSTEMS INC | Event processing with enhanced throughput |
10481878, | Oct 09 2008 | OBJECTSTORE, INC | User interface apparatus and methods |
10572236, | Dec 30 2011 | Pegasystems, Inc. | System and method for updating or modifying an application without manual coding |
10698599, | Jun 03 2016 | PEGASYSTEMS, INC, | Connecting graphical shapes using gestures |
10698647, | Jul 11 2016 | PEGASYSTEMS INC | Selective sharing for collaborative application usage |
10838569, | Mar 30 2006 | Pegasystems Inc. | Method and apparatus for user interface non-conformance detection and correction |
11048488, | Aug 14 2018 | Pegasystems, Inc.; PEGASYSTEMS, INC | Software code optimizer and method |
11057313, | Oct 10 2014 | Pegasystems Inc. | Event processing with enhanced throughput |
11567945, | Aug 27 2020 | PEGASYSTEMS INC | Customized digital content generation systems and methods |
6842177, | Dec 14 2001 | University of Washington | Macroblock padding |
7113194, | Jan 30 2001 | Qualcomm Incorporated | Method and apparatus for rotating an image on a display |
7209141, | Dec 14 2001 | University of Washington | Macroblock padding |
7283562, | Sep 26 2002 | International Business Machines Corporation | Method and apparatus for scaling input bandwidth for bandwidth allocation technology |
7302440, | Jul 27 2001 | METATOMIX, INC | Methods and apparatus for statistical data analysis and reduction for an enterprise application |
7613712, | Oct 07 2002 | OBJECTSTORE, INC | Methods and apparatus for identifying related nodes in a directed graph having named arcs |
7640239, | Jul 27 2001 | OBJECTSTORE, INC | Methods and apparatus for real-time business visibility using persistent schema-less data storage |
7660246, | Sep 26 2002 | TWITTER, INC | Method and apparatus for scaling input bandwidth for bandwidth allocation technology |
7831604, | May 15 2001 | OBJECTSTORE, INC | Methods and apparatus for enterprise application integration |
7846026, | Dec 15 2003 | Cole Kepro International, LLC | Gaming machine door with adjustable cross member |
7890517, | May 15 2001 | OBJECTSTORE, INC | Appliance for enterprise information integration and enterprise resource interoperability platform and methods |
8073053, | Sep 22 2004 | Sovereign Peak Ventures, LLC | Image encoding device that encodes an arbitrary number of moving pictures |
8250525, | Mar 02 2007 | PEGASYSTEMS, INC | Proactive performance management for multi-user enterprise software systems |
8335704, | Jan 28 2005 | PEGASYSTEMS INC | Methods and apparatus for work management and routing |
8335792, | May 15 2001 | OBJECTSTORE, INC | Methods and apparatus for enterprise application integration |
8390639, | Jan 30 2001 | Qualcomm Incorporated | Method and apparatus for rotating an image on a display |
8412720, | May 15 2001 | OBJECTSTORE, INC | Methods and apparatus for querying a relational data store using schema-less queries |
8479157, | May 26 2004 | Pegasystems Inc. | Methods and apparatus for integration of declarative rule-based processing with procedural programming in a digital data-processing evironment |
8495034, | Dec 30 2010 | Teradata US, Inc. | Numeric, decimal and date field compression |
8572059, | May 15 2001 | OBJECTSTORE, INC | Surveillance, monitoring and real-time events platform |
8880487, | Feb 18 2011 | PEGASYSTEMS, INC | Systems and methods for distributed rules processing |
8924335, | Mar 30 2006 | PEGASYSTEMS, INC | Rule-based user interface conformance methods |
8959480, | May 26 2004 | Pegasystems Inc. | Methods and apparatus for integration of declarative rule-based processing with procedural programming in a digital data-processing environment |
9092319, | Feb 19 2004 | Telefonaktiebolaget LM Ericsson (publ) | State memory management, wherein state memory is managed by dividing state memory into portions each portion assigned for storing state information associated with a specific message class |
9189361, | Mar 02 2007 | Pegasystems Inc. | Proactive performance management for multi-user enterprise software systems |
9195936, | Dec 30 2011 | Pegasystems Inc.; PEGASYSTEMS, INC | System and method for updating or modifying an application without manual coding |
9270743, | Feb 18 2011 | Pegasystems Inc. | Systems and methods for distributed rules processing |
9658735, | Mar 30 2006 | Pegasystems Inc. | Methods and apparatus for user interface optimization |
9678719, | Mar 30 2009 | Pegasystems Inc. | System and software for creation and modification of software |
9754384, | Apr 18 2012 | SUZHOU SUPERENGINE GRAPHICS SOFTWARE TECHNOLOGY DEVELOPMENT CO , LTD | Relevant method and device for compression, decompression and progressive transmission of spatial data |
Patent | Priority | Assignee | Title |
3656178, | |||
5155772, | Dec 11 1990 | AVAYA Inc | Data compression system for voice data |
5367620, | Sep 25 1990 | Brother Kogyo Kabushiki Kaisha | Character output device |
5388209, | Aug 02 1991 | Sony Corporation | Apparatus for high-speed recording compressed digital data with increased compression |
5552898, | Jul 06 1994 | XEIKON N V ; Xeikon NV | Lossy and lossless compression in raster image processor |
5583977, | Oct 21 1993 | Apple Inc | Object-oriented curve manipulation system |
5638498, | Nov 10 1992 | Adobe Systems, Inc | Method and apparatus for reducing storage requirements for display data |
5710916, | May 24 1994 | Panasonic Corporation of North America | Method and apparatus for similarity matching of handwritten data objects |
5740409, | Jul 01 1996 | Oracle America, Inc | Command processor for a three-dimensional graphics accelerator which includes geometry decompression capabilities |
5751809, | Sep 29 1995 | Intel Corporation | Apparatus and method for securing captured data transmitted between two sources |
5790979, | May 10 1993 | Translation method in which page-table progression is dynamically determined by guard-bit sequences | |
5793371, | Aug 04 1995 | Oracle America, Inc | Method and apparatus for geometric compression of three-dimensional graphics data |
5852710, | Oct 28 1994 | Seiko Epson Corporation | Apparatus and method for storing image data into memory |
5867167, | Aug 04 1995 | Sun Microsystems, Inc. | Compression of three-dimensional graphics data including quantization, delta-encoding, and variable-length encoding |
5870094, | Aug 04 1995 | Sun Microsystems, Inc. | System and method for transferring compressed three-dimensional graphics data |
5930813, | Dec 21 1995 | Adobe Systems Incorporated; Adobe Systems, Inc | Method and system for designating objects |
5977979, | Oct 31 1995 | ACTIVISION PUBLISHING, INC | Simulated three-dimensional display using bit-mapped information |
6246422, | Sep 01 1998 | Oracle America, Inc | Efficient method for storing texture maps in multi-bank memory |
6249604, | Nov 19 1991 | Technology Licensing Corporation | Method for determining boundaries of words in text |
6304940, | Aug 14 1997 | International Business Machines Corporation | Shared direct access storage system for MVS and FBA processors |
6313838, | Feb 17 1998 | Oracle America, Inc | Estimating graphics system performance for polygons |
Executed on | Assignor | Assignee | Conveyance | Frame | Reel | Doc |
Sep 10 1999 | KENYON, JEREMY A | WildTangent | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 010269 | /0145 | |
Sep 15 1999 | SMITH, PETER D | WildTangent | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 010269 | /0145 | |
Sep 18 1999 | WildTangent, Inc. | (assignment on the face of the patent) | / | |||
May 26 2000 | WILDTANGENT, INC , A WASHINGTON CORPORATION | WILDTANGENT, INC , A DELAWARE CORPORATION | MERGER SEE DOCUMENT FOR DETAILS | 014210 | /0279 | |
Apr 03 2019 | WildTangent, Inc | GAMIGO INC | ASSIGNMENT OF ASSIGNORS INTEREST SEE DOCUMENT FOR DETAILS | 050170 | /0494 |
Date | Maintenance Fee Events |
Dec 27 2006 | REM: Maintenance Fee Reminder Mailed. |
Jan 05 2007 | M1551: Payment of Maintenance Fee, 4th Year, Large Entity. |
Jan 05 2007 | M1554: Surcharge for Late Payment, Large Entity. |
Jan 05 2007 | STOL: Pat Hldr no Longer Claims Small Ent Stat |
Jun 26 2009 | LTOS: Pat Holder Claims Small Entity Status. |
Dec 10 2010 | M2552: Payment of Maintenance Fee, 8th Yr, Small Entity. |
Dec 04 2014 | M2553: Payment of Maintenance Fee, 12th Yr, Small Entity. |
Date | Maintenance Schedule |
Jun 10 2006 | 4 years fee payment window open |
Dec 10 2006 | 6 months grace period start (w surcharge) |
Jun 10 2007 | patent expiry (for year 4) |
Jun 10 2009 | 2 years to revive unintentionally abandoned end. (for year 4) |
Jun 10 2010 | 8 years fee payment window open |
Dec 10 2010 | 6 months grace period start (w surcharge) |
Jun 10 2011 | patent expiry (for year 8) |
Jun 10 2013 | 2 years to revive unintentionally abandoned end. (for year 8) |
Jun 10 2014 | 12 years fee payment window open |
Dec 10 2014 | 6 months grace period start (w surcharge) |
Jun 10 2015 | patent expiry (for year 12) |
Jun 10 2017 | 2 years to revive unintentionally abandoned end. (for year 12) |