Computer graphics processing and selective visual display system – Computer graphics processing – Three-dimension
Reexamination Certificate
1999-06-18
2002-06-18
Nguyen, Phu K. (Department: 2671)
Computer graphics processing and selective visual display system
Computer graphics processing
Three-dimension
Reexamination Certificate
active
06407736
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention relates generally to computer graphics architecture and processing. More particularly, it relates to scan conversion of triangle-based polygon data into pixels.
2. Description of Related Art
Introduction
Three-dimensional (3-D) computer graphics systems display images, which represent real or imaginary objects in real or imaginary settings, on a two-dimensional (2-D) monitor or other output device. As a result, the user “believes” that he is seeing 3-D objects in a 3-D world. A typical computer graphics system stores such objects in one of the many existing object file formats, using 3-D coordinates to represent spheres, vectors, curves, polygons, and other simpler component objects, along with their associated object properties, such as color, texture, intensity, transparency and/or reflectivity. Environmental data such as the number, color, location, intensity, and other properties of illumination sources, as well as atmospheric properties, are included to add richness in detail to a scene containing one or more objects.
To render such a scene from a particular viewing angle onto a 2-D screen, the “front end” of a typical computer graphics system transforms the collection of objects in the scene into a set of primitives (typically polygons, such as triangles, that are independent of scale), taking into account any movement of objects over time, as well as the scene's environmental data and the user's desired viewing angle. Triangles frequently are used as the “building blocks” for 3-D objects with complex curved surfaces, because they are simple primitive objects that effectively can “cover” or represent each surface of virtually any complex object in a tiled manner. Relatively simple images might be represented with a few, relatively large triangles, whereas more complex images might require a greater number of smaller triangles. Regardless of their size, triangles typically are represented as three 3-D (x,y,z) vertices, along with color (RGB) and texture information. Of course, given sufficient memory and computational resources, pixels could be used in lieu of triangles to represent complex images even more precisely.
Front-end processing typically still is handled in software on the host system (e.g., a PC), and does not itself require hardware acceleration for most applications. The host system provides a stream of triangles to the “back end” of the computer graphics system. The order in which the host system provides these triangles does not necessarily bear any relationship to the screen location at which such triangles might be visible.
The back end of the system is responsible for “rasterizing” this set of triangles—i.e., transforming them into the particular pixels that will be displayed on the screen. It projects these 3-D triangles onto a 2-D screen, removes “hidden surfaces” to prevent portions of triangles that are obscured by other triangles from being displayed, and generates individual pixels (to be displayed on the screen) that “fill in” the visible portions of these triangles with their associated color or texture information. Back-end processing typically is relatively time-intensive, and thus often requires hardware acceleration to maintain sufficient performance.
The performance of 3-D graphics systems typically is measured by the number of triangles per second they can process. A key problem therefore is how to architect the back-end of a computer graphics system to process a stream of 3-D triangles as quickly as possible. Ideally, the back end of a system will rasterize, within the time required for one frame to be displayed on the screen (e.g., {fraction (1/60)} of a second for a monitor with a 60 Hz refresh rate), all of the triangles generated by the system's front end. This is not, however, always possible.
For example, even a moderately complex screen object, such as a person, may be represented by a sufficiently large number of triangles to cause the back end of a typical computer graphics system to take multiple “frame times” to render that object completely. If the scene is static and the person is standing still, the back end may, for example, require 120 frames or 2 seconds to render that scene. If, however, the scene changes frequently, e.g., if that person moves across the screen, the back end would have to rasterize a greater number of triangles per second, because it would have to render, within those same 2 seconds, multiple variations of the same object—i.e., the same person in different poses and at different locations on the screen. Alternatively, to render an even more complex static image (e.g., a scene with three people together at one time) within those same few seconds would also require the back end to rasterize a greater number of triangles per second. Thus, by processing a greater number of triangles per second, a system is able to render more complex images and/or update images more frequently to reflect changes over time, even though it may not be able to render every image within a single “frame time.”
Many of today's computer graphics applications handle very complex images and/or images that change very frequently. For example, digital imaging applications often require images of near-photographic quality which are represented by a large number of relatively small triangles. A computer graphics system must process many triangles relatively quickly in order to render such images within a reasonable period of time. Computer animation and virtual reality applications, on the other hand, may not require images of such complexity; but, they may require that frames be updated very frequently to reflect, for example, the many changes in a scene that result from a slight movement of a user's virtual reality headset. In either case, the system must process a larger number of triangles per second than if the images were less complex or changed less frequently.
To obtain adequate performance and process a sufficient number of triangles per second, most current computer graphics systems employ one of two general types of back-end architectures—(1) frame buffer architectures, which operate on a frame-by-frame basis, generating and writing into a buffer the pixels of each frame of an image to be displayed on the screen, and scanning out those pixels to the screen; and (2) display list architectures, which operate on a scanline-by-scanline basis, generating in scan order (and possibly writing into a buffer) the pixels of each scanline of an image to be displayed on the screen, and scanning out those pixels to the screen.
Frame Buffer Architectures
Systems based on frame buffer architectures, like all back end systems, receive 3-D triangles from the system's front end. These systems generate pixels to fill in each triangle (or at least the visible portion of each triangle), and store those pixels in a frame buffer that contains memory locations corresponding to each pixel on the screen. Typically, the order in which these systems generate pixels and store them in the frame buffer corresponds to the order in which triangles are received from the system's front end, and not necessarily the location of such triangles on the screen.
Typical frame buffer architectures employ a double-buffered approach, particularly for animation, in which two frame buffers are utilized. While the system is scanning out to the screen the pixels from the first frame buffer (containing the current image), it simultaneously is writing into the second frame buffer the pixels generated by rasterizing each triangle (for the next image). Once the system finishes processing the triangles for this second frame buffer (even if such processing requires multiple “frame times”), the system can switch buffers (on the next vertical retrace) and begin scanning out to the screen this next image from the second frame buffer, while generating a subsequent image in the first frame buffer.
If the system's back end cannot generate and store pixels in a frame buffer
Interval Research Corporation
Nguyen Phu K.
Van Pelt & Yi LLP
LandOfFree
Deferred scanline conversion architecture does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Deferred scanline conversion architecture, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Deferred scanline conversion architecture will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2967827