Method and Apparatus for Anti-Aliasing Polygon Edges in a Computer Imaging System

This invention relates to computer image generation (CIG) systems and, more particularly, to a novel color determination means for use in a display processor and to novel methods for processing of image data describing object faces, for display of two-dimensional representations of those objects in a real-time imaging system.

Real-time computer image systems are being designed to provide realistic image reproduction for a variety of simulator systems, such as tank simulators and flight simulators. Such simulators are used as training devices which permit a combatant to obtain practice without the necessity of going out into the field and using the actual combat systems. The simulators enable a user, such as a pilot or tank gunner, to maintain and improve his skills without the cost associated with live training. It is thus very advantageous to provide the user with video display realism which is beneficial for training and practice purposes.

In a typical real-time computer image generation system, such as a flight simulator system, image generation can be broken into three separate processing stages: Controller, Geometry Processor, and Display Processor. These three processing stages or sections each work independently on data representative of or corresponding to one of three consecutive scenes to be displayed. The Controller processes data on a scene or image for a fixed time, which may be either a field time of 16.67 milliseconds or a frame time of 33.3 milliseconds, usually the former, and then passes its processed data to the Geometry Processor. This particular field and frame time corresponds to that time for a typical television format display, i.e., two interlaced fields per frame with thirty frames per second. The Geometry Processor has an equal time to do its calculations and at the end of that time its results are sent to the Display Processor. The Display Processor always processes one interlace field for a video display in one field time. For each time interval, all three processors are kept busy, so that, at any given time, the processors are working on three separate scenes. Each section processes inputs and generates outputs during the interval, so data flows through the three stages in a sequential manner. The computational load is spread out among the specialized processor sections, so this allows new scenes to be displayed each field or frame time, even though the results are delayed three fields or frames.

For example, in a flight simulator system, pilot inputs are received by the Controller and after being processed sequentially by the Controller, the Geometry Processor and Display Processor, the output is sent as a color scene to video displays observed by the pilot in the simulator. The data seen by the pilot starts out as simple control inputs applied to an environment definition and is converted to pixel video display information. In the controller, the pilot inputs are used to calculate the new position and orientation of the aircraft, and from this, a mathematical rotation matrix is calculated that is used to rotate objects from the reference coordinate system to a display coordinate system. Any other information dealing with the aircraft, with the position of targets and with other aircraft is also calculated in the Controller. In some applications, the Controller is a general-purpose computer.

The Geometry Processor reads, from a database, descriptions of objects that are potentially visible in the stored three-dimensional digital representation of the scene. The objects that are read are rotated into display coordinates using the rotation matrices calculated in the Controller. Edges of these three-dimensional objects are clipped by the Geometry Processor if they extend beyond the view window boundaries. The Geometry Processor mathematically projects the three-dimensional data onto the two-dimensional display window. Object faces which extend beyond display window boundaries are clipped in two-dimensional image space. In addition, the Geometry Processor calculates (as by use of a depth-buffer or the like) which objects are in front or behind other objects and stores this information in a priority list. Each object processed is made up of individual faces, where each face is in the form of a polygon bounded by straight edges. The priority list contains the order of all faces in the scene, with the first face in the list as the highest priority face, and the last face in the list as the lowest priority face. Whenever two faces overlap on the display, the higher priority face will be visible, and the lower priority face will be obscured. Lastly, the Geometry Processor calculates the display end points for the edges that bound the two-dimensional faces, and also calculates the coefficients of the line equations that describe these bounding edges.

The Display Processor receives the two-dimensional face descriptions, along with face color, face fading information, a face priority list, cell texturing level-of-detail blending, translucency, curvature shading etc., and uses this information to output data describing to a color display each pixel in the scene. Each color display in the system is typically made up of 1024 lines of video information, with each line having 1024 individual color dots or pixels. However, other combinations of lines and pixels per line are certainly possible. The Display Processor has to resolve, for each pixel, what the color of the pixel should be, given that many faces can be present in a pixel, and that certain portions of faces may be covered by other faces. Since there can be 1024 by 1024 pixels in the display, and all these need to be calculated in 1/60th of a second, the processing load in the Display Processor is very high. To calculate video for a multi-display system (a single system has contained as many as 14 displays), the Display Processor must perform in excess of 10 billion computations per second. Due to the tremendous processing load, a Display Processor can drive only a few displays. In some systems, a single Controller and Geometry Processor can be used to drive several Display Processors with several displays connected to each Display Processor. The Display Processor therefore represents the majority of processing in a real-time computer image generation system, and for this reason most of the effort to improve the capabilities and realism of a CIG system is concentrated in the Display Processor area.

One persistent problem has been to process pixel color intensity information in an anti-aliasing manner, which allows for suitable high-definition edge effects to be visible while preventing undesirable video data components ("distortion") from taking on the identity of a desired component, so as to appear as the wrong color, or degree of translucency, in that pixel.

In accordance with the invention, a display processor in a real-time computer image generator includes: edge interception calculator means, receiving input data signals characterizing the display space (I,J) coordinates of each of at least three vertices of each polygon to be displayed, for determining which edges, if any, of each sequential pixel of the display raster, are cut by a polygon edge, and the location of the cut along the determined edge; the edge crossing data signals for all polygons affecting each pixel are stored on a per-pixel basis in a frame buffer, along with color data for each of the faces occupying any portion of that pixel; and a post processor means, receiving data signals characterizing, for each pixel to be displayed, 12 edges of a constellation of four adjacent pixels, for resolving edge relationships and mixing polygon color intensity data to determine the final, observable color of each pixel to be displayed by a display means receiving the video data output of the CIG.

A method for determining the final viewable color of each pixel to be displayed by a display means receiving the video data output of a real-time computer image generator, comprises the steps of: first receiving input data signals characterizing the display space (I,J) coordinates of each of at least three vertices of each face polygon to be displayed; and then utilizing the vertex data to determine which polygon edges, if any, cut one of the sequence of pixels forming the display raster; and then determining the location of the cut along the associated pixel edge. The edge crossing data signals for all polygons affecting each pixel are stored on a per-pixel basis in a frame buffer, along with color data for each of the polygons occupying any portion of that pixel; and, for each pixel to be displayed, a constellation of several (e.g. 12) edges of selected adjacent pixels, are processed for resolving edge relationships and mixing polygon color intensity data to determine the final, observable color of each display pixel.

Accordingly, it is an object of the present invention to provide novel apparatus and methods for determining the color intensity of each pixel in a computer image system display.

This and other objects of the invention will become apparent upon reading of the following detailed description of presently preferred embodiments, when considered in conjunction with the associated drawings.

FIG. 1 is a schematic block diagram of a computer image generation (CIG) system in which the apparatus and methods of the present invention may be practiced;

FIG. 2 is a spatial diagram illustrating the relationship between an object face polygon, in object space, and a corresponding image face polygon, in image space, and the picture elements (pixels) of the display raster upon which the image face will appear;

FIG. 2a is a magnified portion of the image display of FIG. 2, in the vicinity of the desired polygon to be displayed;

FIG. 3a is a view of an array of display pixels, upon which a pair of face polygons are imaged;

FIG. 3b is a view of an array of display pixels, upon which a face polygon is positioned, and shows the various sampling corners C, pixel edges E and edge distances D necessary for operation of a pixel color data determination method in accordance with the present invention;

FIG. 3c is a representation of a pixel corner Co in constellation with its adjacent corners, edge crossings and distances, and useful in appreciating several aspects of the present invention;

FIG. 4 is a block diagram of a color intensity subassembly, in accordance with the principles of the present invention, for use in a CIG display processor;

FIGS. 5a, 5b, 5d and 5e are flow charts respectively for the respective edge-determination, segment length determination, small polygon filtering and color mixing process portions utilized in the method of operation of the color intensity subassembly;

FIG. 5b' illustrates an 8-pixel, 12-segment constellation about each pixel-being-operated-upon and is useful in understanding method operation;

FIG. 5b" illustrates one aspect of line length determination in the present method;

FIG. 5c illustrates blend color implementation in a 3.times.3 pixel constellation;

FIG. 6a illustrates the complementary sets of corners sampled for different translucency levels and different binary values of a Pattern Select bit, while FIGS. 6b-6g illustrate various different translucency operations and conditions, and are all useful in appreciating the manner in which translucent "look-through" is achieved;

FIG. 7 is a schematic block diagram of one possible implementation of a novel post-processor edge-register/resolver means for a color intensity subassembly in accordance with the invention; and

FIGS. 8a-8g show the entire possible set of pixels having a pair of edges cut by a single polygon edge, and the single possible case of a pixel having all four edges cut by edges formed between four polygons overlapping in that one pixel.

Referring initially to FIG. 1, a functional block diagram of a computer image generation system 10, such as an aircraft cockpit simulation system, is illustrated. The reader is referred to the existing CIG art, including such publications as U.S. Pat. No. 4,727,365, issued Feb. 23, 1988 to Bunker et al., for "Advanced Video Object Generator" and U.S. Pat. No. 4,825,391, issued Apr. 25, 1989 to D. Merz, for "Depth Buffer Priority Processing For Real Time Computer Image Generating Systems", both of which are incorporated herein in their entireties by reference.

The system includes a Controller unit 12, a Geometry Processor unit 14, and a Display Processor unit 16. The Display Processor unit 16 displays information to a cockpit display window 18 to simulate the movement of the aircraft over a scene. A pilot-trainee 20 is linked to the computer image generation system 10 through input control interface 22. The pilot's maneuvering action in the cockpit is fed to input control interface 22. The input control interface converts the appropriate flight data such as air-craft position, aircraft roll, pitch, and yaw attitude, from the pilot to the Controller 12.

In the Controller 12, the pilot inputs are used to calculate a new position and orientation of the aircraft, and from this, a mathematical rotation matrix is calculated that is used to rotate objects from the reference coordinate system to a display coordinate system, which is well known in the art. Other information dealing with the scene, the position of targets, or other aircraft is calculated in the Controller. In some computer image generation systems the Controller unit is a general purpose computer.

The Controller unit 12 is updated periodically by the most recent aircraft orientation. This orientation includes the aircraft roll, pitch, and yaw, and position from the pilot via the input control interface 22, to the Controller 12. The Controller 12 works on a scene for a field or frame time and then passes data to the Geometry Processor 14.

The Geometry Processor 14 reads from a scene database memory 2,4, descriptions of objects such as towers, roads, rivers, hangars, etc., that are potentially visible in the stored three dimensional digital representation of the earth. The objects are read from the scene database and are rotated into display coordinates using the rotation matrix calculated in the Controller 12. The Geometry Processor 14 clips all edges which extend beyond the view window boundaries in object space. It mathematically projects the three-dimensional object data onto the two-dimensional display window. Object faces which extend beyond display window boundaries are clipped in two-dimensional image space. The two dimensional objects consist of points, lines, closed convex polygons, or combinations thereof. Each closed convex polygon is known as a face. Thus, each object processed is made up of individual faces, where each face is bounded by straight edges. Once the faces are computed from the three-dimensional objects, in the Geometry Processor 14, the data is passed to the Display Processor 16. In addition, the Geometry Processor 14 calculates, in known manner, which faces are in front or behind other faces and stores this information in a priority list. The priority list contains the order of all faces in the scene where the first face in the list is the highest priority face, and the last face in the list is the lowest priority face. Whenever two faces overlap on a display, the high priority face will be visible and the overlap portion of the low priority face will be obscured. After calculating the priority list, the Geometry Processor 14 calculates the display endpoints of the line segments that bound the two dimensional faces and calculates the coefficients of the line equations that describe the bounding edges. The Geometry Processor 14 calculates the endpoints of each edge and the slope of each edge that describe a bounded face. These data are then passed on to the Display Processor 16.

In FIG. 1, there is shown Display Processor 16 that is used to drive the video display 18. In some systems, a single Controller 12 and Geometry Processor 14 is used to drive more than one Display Processor. The Display Processor 16 represents the majority of processing and hardware in a real-time computer generation system and, for this reason, most of the effort to reduce the size of the hardware and processing time has been concentrated in the Display Processor area. The Display Processor is responsible for processing information to be displayed on video display 18. The Display Processor 16 has to resolve for each pixel in the video display 18 what the color of the pixel should be, given the many faces that can be present in a pixel, and those portions of faces that may be covered by other faces. After resolving the priority conflicts within a pixel, the area of each visible face within the pixel is multiplied by the color of the face, and the sum of all these weighted colors is output as a pixel color. The Display Processor 16 thus receives two-dimensional face descriptions from the Geometry Processor 14, along with the face color, and a face priority list, and uses this information to output the scene to color video display 18. Each color display in a system can be made up of 1,024 or more lines of video information and on each line there typically are 1,024 individual color dots or pixels (picture elements). Since there may be more than one million pixels in the display, and all of these need to be calculated in 1/60th of a second, the processing load in the Display Processor is very high. For each pixel the display may receive a 12 bit red data signal, a 12 bit green data signal, and a 12 bit blue data signal as part of intensity information that describes the color of the pixel.

Referring to FIG. 2, the eyes 20' of the observer are at a viewpoint VP and look at a sample face 30 polygon within the view window in object space 30'. Only the face 30 closest to viewer 20', along a view line 32, is seen; the visible face is determined by comparison of range distance R between view point VP and a face point Pf, using depth buffer techniques well known to the art (see, for example, the aforementioned U.S. Pat. No. 4,825,391 and the references cited therein). Thus, visible polygon 30 (here, a triangular face identified by its vertices Va, Vb and Vc) is that polygon having the minimum range R.sub.min along view line 32. The object space 30' is projected into a display window 34 in image space 34'; face polygon 30 is projected as display polygon 36, with respective vertices V1, V2 and V3 corresponding to vertices Va, Vb and Vc, respectively. The display window is often the raster of the display, with each pixel 38 scanned in sequential fashion along a horizontal line (in the J direction) from the left edge (J=J.sub.o) to the right edge (J=J.sub.max) of the raster/window, and for lines with increasing distance (in the I direction) down from the raster/window top edge (where I=I.sub.o) to the bottom edge (I=I.sub.max). Thus, the p-th line Lp is scanned from a first (left-hand) pixel Pl to a last (right-hand) pixel Pr. A pixel Pp is identified by the view line 32 passing through the window 34 plane, so that pixel lap includes an image point projecting, and corresponding, to polygon point Pf. The polygon 36 will, along line Lp, include pixels from a leftmost pixel Po, identified by the J.sub.L crossing at the left line location, to a rightmost pixel Pq, identified by the J.sub.R crossing at the right line location.

Expanding the portion of image space being considered, as in FIG. 2a, a row of the pixels 38 along the scan line 34" is sequentially scanned in the J direction, starting at leftmost pixel 38h; the next pixel 38i is then operated upon, and so forth, until a pixel 38l is reached on the left edge of the polygon for that line and partially covered by the polygon 36. This pixel is identified as a leftmost crossing J.sub.L of a polygon edge and the J line 34". Continuing along the line, through other pixels 38 completely covered by the polygon, a pixel 38r is reached on the right edge of the polygon for that line, and partially covered by the polygon 36; this pixel is identified as a rightmost crossing J.sub.R of a polygon edge. Further travel along the J line 34" eventually reaches the rightmost pixel 38v of that scan line. It will be seen that, without consideration of translucency and feedthrough of chroma from a more-distant polygon, the attributes of the pixels 38 completely covered by, and therefore totally within, the polygon 36 have exactly the polygon face attributes (color, intensity, translucency, etc.), while the pixels (e.g. pixels 38l and 38r) partially covered by the polygon 36 have the attributes of that particular polygon only for the pixel portion actually covered, so that the attributes for the remainder of the pixel must be obtained from other information and blended according to the various percentages of the pixel covered by each polygon/source of color information.

This may be understood by reference to FIG. 3a, wherein a first polygon 36a is ordered (as by any of the well-known depth-buffering processes) in front of another polygon 36b, as seen in image space. Polygon 36 has a plurality of vertices (e.g. four vertices V1, V2, V3 and V4 in FIG. 3b) connected by a like plurality of polygon edges 39 (e.g. as shown in FIG. 3b, edges 39a, 39b, 39c and 39d) which cross pixel boundaries at crossings 40. The image screen is formed of a rectangular array of pixels, arranged in vertical columns (e.g. columns . . . , P-2, P-1, P, P+1, P+2, . . . ) sequentially along horizontal lines (e.g. lines . . . , L-2, L-1, L, L+1, L+2, . . . ) with horizontal edges E at the lower demarkation of each line L of pixels with the next-higher-numbered (next-to-be-scanned) pixel line. Each pixel can thus be ordered by its rowline L and column P designation. It will be seen that some pixels, such as pixel (L,P), will be completely covered by only one polygon (polygon 36a) and thus have only the attributes of that polygon; other pixels have a sharing/blending of the attributes of plural polygons.

In accordance with one aspect of our invention, as shown in FIG. 3b, we prefer to determine color attributes by consideration of the entire pixel and do not need to process color information for a plurality of subportions of each pixel (or subpixels), even if the depth-buffering processing architecture (with or without use of span/subspan processing methodology) of the aforementioned U.S. Pat. No. 4,825,391 is used. It should be understood that each item of information processed in our method is a signal word of electronic digital data; while we may discuss these signals by shorthand designations (e.g. corners, edges, polygons, etc.), we nevertheless mean these terms to signify the data signals used for each of these respective geometrical concepts (e.g. "corner" signifies the data word specifying the two-dimensional pixel corner location, "edge" is the data signal set representing the line of the associated polygon edge, "polygon" means the digital data structure equivalent of a particular polygon, etc.). The end result of our process is to provide a final sequence of video signals (digital video, or analog video derived from digital) which can cause the color and intensity of the individual pixels of the video display means 18 to be illuminated and rendered visible to observer 20.

The polygons 36 are sampled at pixel intervals; here, the sample points are the four corners C of each pixel. For each pixel (L,P), a 4.times.4 array of corners (e.g. corners C11 through C14 on edge E-2, corners C21 through C24 on edge E-1, corners C31 through C34 on edge E, and corners C41 through C44 on edge E+1) may be used, defining a 3.times.3 array of pixels (8 adjacent pixels around the central pixel L,P then being considered); the pixel array thus includes pixels (L-1,P-1), (L-1,P) and (L-1,P+1) along line (L-1), pixels (L,P-1), (L,P) and (L,P+1) along line (L) and pixels (L+1,P-1), (L+1,P) and (L+1,P+1) along line (L+1). The color of the polygon 36" which is closest to the viewer that lies on a corner (sample) point Cij (where i is the line designator and j is the column designator for that associated pixel), is stored for each pixel of the display. The resulting color data signals are stored in a video memory which contains the color information of each pixel that makes up the display.

The color information at each corner sample point C in the video memory is computed by conventional means which are familiar to one skilled in the CIG arts. We only need to take color information from one corner of each pixel (e.g. the first encountered, or top-left, corner of each pixel in an I,J display); when data for all top-left corners Co for all adjacent pixels is available, the complete color information for any one particular pixel can be determined. The portion of each pixel represented by the color attribute of a corner can be determined through knowledge of where the polygon edge crossings 40 occur with respect to a predeterminately selected constellation of the line segments about the corner point Co; here, we use a 4-line segment "cross" constellation for the five constellation corners (the central corner Co and the four corner points associated with that central pixel corner Co). From a 12 o'clock position, clockwise about corner Co, these four constellation segments are: a top segment S.sub.T, between corner Co and a top corner C.sub.T immediately above corner Co and on the previous edge (E-2); a right segment S.sub.R, between corner Co and a right corner C.sub.T which is the immediate next corner along the scan edge (E-1) and to the right of corner Co; a bottom segment S.sub.B, between corner Co and a bottom corner C.sub.B immediately below corner Co and on the next edge (E); and a left segment S.sub.L, between corner Co and a left corner C.sub.L which is the immediately previous corner along the same edge (E-1). The distance D.sub.x, where x is T, R, B or L, from the pixel corner Co to the associated crossing 40 and the respective top, right, bottom or left segment, is determined by processes and means known to the art, and the distance D.sub.x data signals are stored in the video memory. In addition, a translucency flag bit (definable as clear=0 and opaque=1) for each corner sample point Co is added to the video memory.

Referring now to FIG. 3c, if the same polygon covers a pixel sample point Co, the edges of that polygon are considered for determining the location 40x of each of the vertical and horizontal edge crossing between the pixel sample point and the four adjacent sample constellation corners Cx. Thus, constellation edge crossings 40t, 40r, 40b and 40l are determined and the corresponding constellation distances D.sub.T, D.sub.R, D.sub.B and D.sub.L are all computed and stored in the video memory. However, if the edge crossing distance D.sub.x is greater than the distance between the corner sample points, the distance D.sub.x is clamped to the distance between sample points. The distance between adjacent constellation corners can be set to a normalized value of 1.0; the actual distances D.sub.x are then all normalized and have values between 0.0 and 1.0. As shown, the distance D.sub.T of an edge crossing 40t, from the central corner Co toward central-top corner C.sub.T, is less than 1.0 (the full corner-to-corner distance) and is stored as a data signal for the actual distance computed. The same is true of the distances D.sub.R and D.sub.L respectively between the central corner Co and the respective right and left crossings 40r and 40l, since each normalized distance is less than the constellation corner-to-corner distance. This is not the case for the bottom crossing 40b, which is below the adjacent corner C.sub.B and thus has a distance greater than one; the distance value is clamped to 1.0, indicative of the polygon in consideration extending over both corners Co and C.sub.B. That is, if the distance D.sub.x is equal to the distance between corner sample points, then the polygon on the central corner point Co is assumed to also cover the corresponding adjacent sample corner. The number of bits used in the data word for each distance D.sub.x is in the range of 3 to 5 bits, but may be varied for different systems. Each corner sample point C is thus the address of a separate location in the video memory, which location contains data specifying a color, a translucency flag, and associated top, left, right and bottom crossing distance data. Also if the polygon on the sample point is translucent, a translucency flag is set.

We presently prefer, since the screen distance ordinarily increases from left to right and from top to bottom, to assume that the sample constellation has a corner interval distance of 1.0 and that the polygon covers both adjacent sample points if the crossing distance is 1.0 for the right and bottom crossing, or if the crossing distance is 0.0 for the left and top crossings. Therefore, a simple truncation and clamping of the distance data words will yield distances which vary from 0.0 to 1.0 from left to right, and from top to bottom; if the top or left crossing is 0.0, the polygon covers the left or top adjacent corner point, and if the bottom or right crossing is 1.0, the polygon covers the bottom or right corner point. This is only one convenient implementation, and can be varied as required for a particular use. Various methods of computing the edge crossing distances are well-known and common practice in computer graphics and will be known to one skilled in the art.

Referring now to FIG. 4, one exemplary color intensity subassembly 16a is shown for processing input vertex data signals to obtain video output data signals for display to the viewer 20, using the procedures shown in the flow diagrams of FIGS. 5a-5e. A first input 16a-1 of the subassembly is coupled to a first input 42a of an edge interception calculator means 42, and receives display polygon vertex data signals in (I,J) coordinates from the rest of the display processor 16; the output 42b of the calculator means is the set of normalized edge crossing data words for the particular pixel then being processed. This pixel (Lp,Pp) is specified by the pixel column number Pp data at the means input 42c, from the subassembly input 16a-2, and the display line Lp number data at the means input 42d, from the subassembly input 16a-3.

The edge data signals appear at a first input 44a of a frame buffer (mass memory) means, having a storage location, of many bits depth, for each of the myriad pixels of the display; each location is uniquely specified by the rowline and pixel column data words at inputs 44c and 44d, respectively (i.e. by rowline J.sub.o .ltoreq.Lp.ltoreq.J.sub.max and column I.sub.o .ltoreq.Pp.ltoreq.I.sub.max. The frame buffer also receives polygon color data signals at an input 44e, coupled to subassembly interface 16a-4, and translucency data signals at an input 44f, coupled m subassembly interface 16a-5. The frame buffer input section 44a' stores all of the color/translucency, edge crossing and flags information for each pixel on a per-pixel basis. This data is also provided on a per-pixel basis to frame buffer output 44b; it should be understood that, while the present buffer means is shown as having only a single set of pixel-designating inputs 44c/44d, so that only the one pixel then being addressed will receive input data and supply data at output 44b, it is equally as well understood to provide plural sets of pixel-designating inputs to allow input data to be loaded into one (or more) pixel location while stored data is retrieved and output from one (or more) independently-specified different pixel location.

The frame buffer output 41b provides digital data signals for the corners and edges of the chosen anti-aliasing constellation (here of 12 edges, for 4 adjacent pixels about the central pixel (Lp,Pp) then being processed) to an input 46a of a post processor means 46, the rowline and pixel column data signals are provided to other inputs 46c and 46d. The edge registers are accessed by edge resolver 46-2 to determine the portion of the presently-processing pixel covered by color/translucency attributes of a face polygon; this information is then used by the color mixer 46-3 to set the final blended color of the present (Lp,Pp) pixel and pass that data from post-processor output 46b, as the subassembly output 16a-6 video output data signal (which may be displayed or further processed, as required).

The edge intercept calculator performs the process steps shown in the flow chart of FIG. 5a: the pixel rowline Lp and column Pp data signals are received in step 50 and the polygon 36 vertex data signals are received in step 51. In step 52, the beginning of a display line L loop, the calculator determines which display lines L, from the top line (where I=Io) to the bottom line (I=Imax), have the polygon present in at least part of one pixel; these line numbers L are temporarily recorded and the first of the line numbers LP is set. This line number is entered into step 53, where the left and right polygon edge-rowline intersections J.sub.L and J.sub.R are found for that line; these limits are also temporarily stored. Step 54 begins a nested pixel loop, considering each pixel JP along the line LP established in step 52, from the limits (left to right) found in step 53. Inside the nested loop is found steps 55, 56, 57 and 58, respectively acting for: finding, for the top-left corner Co of the pixel, the four crossings C.sub.x and the associated normalized four distances D.sub.x of that corner constellation; clamping the distance D.sub.x to a maximum 1 pixel value, and setting a "covered" flag, if the particular distance D.sub.x is greater than 1 pixel distance (step 55); operating on some aspect of the pixel data if the polygon is translucent (translucency considerations will be discussed in detail hereinbelow); computing the corner point Co color as a function of all related factors, such as polygon color, texture effects (color, modulation, and the like) and so forth (step 57); and then temporarily storing the relevant data signals in video memory (the frame buffer 44). Thereafter, step 59 is entered and the J loop determines: will the J value for a next-sequential pixel will exceed the righthand limit J.sub.R ? If not, further pixel processing on that Lp line can proceed; output 59a is used and step 60 is entered, to return the loop to step 54, with J=J+1. If the present pixel was at J.sub.R, the next pixel contains no part of the present polygon, and output 59b is exited so that the process moves to the next line L=(Lp+1). Step 61 is entered and the line loop determines if the next-sequential line will exceed the lower line limit L.sub.max for that polygon? If not, further pixel processing on that line can proceed; output 61a is used and step 62 is entered so that the line loop actually now returns to step 54, with L=L+1; the pixel loop for that new line will be traversed. If the just-completed line was at the bottom of the polygon, the next line contains no part of the present polygon, and output 61b is exited so that the process moves to the next polygon 36'. When the present polygon processing is finished, step 63 is entered and the polygon loop determines if all polygons in the present view window 34 have been considered? If other polygons remain to be processed, exit 63a is taken, the polygon designator is advanced at step 64 and the set of next-polygon vertices fetched (step 51). If no other polygons remain for consideration, further pixel processing in this system portion is not necessary for that display frame; output 61b is exited so that the process moves to the next image window frame of data signals and begins the edge intercept calculation process for the pixel data of that display frame.

TRANSLUCENCY

Each face polygon 36 has a certain, known degree of translucency. We normalize the translucency level so that the level can be denoted by a number between 0.0 (perfectly transparent) and 1.0 (completely opaque). Translucency is accomplished by disregarding or disabling particular pixel corner sample points, so that even though the polygon may lie on (i.e., cover) the sample corner point, the polygon characteristics data is not written into the video memory for that pixel corner; the edge crossings associated with the omitted corner are also not written into memory. By disabling sampling points depending on the amount of translucency, polygons visually behind the translucent polygon can be seen. The more translucent the polygon, the more sample points are disabled. This is analogous to poking holes in the translucent polygon to see what is behind. A pattern select code and translucency value are assigned to a polygon. Translucency value indicates how many sample points to disable, and the pattern select indicates which sample points to disable.

The disablement process may be understood by reference to FIG. 6a, where five different transparency levels T are shown, for each of the two levels of a pattern select (PS) bit. It will be seen that for different ranges of T levels, the translucency disablement pattern for the pattern select bit at a low binary level (PS=0) is complementary to the selected pattern with the pattern select bit at a high binary level (PS=1). While only five levels of translucency T are illustrated, more translucency levels are computable.

The number of T levels is achieved by modifying the edge crossings, as shown in FIGS. 6b-6e, as a function of translucency. The more translucent the face polygon, the less the area assigned to a sample point. This procedure increases or decreases the area of the polygon on each sample corner point: as seen in FIG. 6b, the translucency level T is sufficiently low (0<T<1/4) that only one pixel corner C.sub.a is part of the selected pattern, and the other corners C.sub.b, C.sub.c and C.sub.d corners of that same pixel are disabled and not considered; the left and right crossings are moved toward the sample point, so that distances D.sub.La and D.sub.Ra respectively become 1.0 and 0.0, while the modified bottom crossing distance D'.sub.Ba becomes (4*T*D.sub.Ba), where D.sub.Ba is the unmodified bottom crossing 40" distance to corner C.sub.a. Similarly, the top crossing 40' distance D.sub.Ta is modified to D'.sub.Ta =1-(4*T*(D-D.sub.Ta)), where D is the unit pixel edge segment distance. As the translucency level T increases, the edge crossings are moved away from the corner sample point, and increases the effective area of the face polygon in the pixel being considered.

FIG. 6c shows the case where 1/4.ltoreq.T<1/2: a pair of pixel corners are used (here, corners C.sub.a and C.sub.c) and a pair of corners (C.sub.b and C.sub.d) are disabled and not considered. For the top corner C.sub.a point, the left and right crossings remain moved toward the sample point, and distances D.sub.La and D.sub.Ra respectively remain 1.0 and 0.0; the top and bottom crossing distances D.sub.Ta and D.sub.Ba are not modified. For the bottom corner C.sub.c point, the top and bottom crossing distances D.sub.Tc and D.sub.Bc respectively become 1.0 and 0.0, while the modified right crossing distance D'.sub.Rc becomes (4*(T-1/4)*D.sub.Rc), where D.sub.Rc is the unmodified bottom crossing distance for corner C.sub.c. Similarly, the left crossing distance D.sub.Lc is modified to D'.sub.L =1-(4*(T-1/4)*(D-D.sub.Lc)).

FIG. 6d shows the case where 1/2.ltoreq.T<3/4: a trio of pixel corners are used (here, corners C.sub.a, C.sub.c and C.sub.d) and only one corner (C.sub.b) is disabled and not considered. The top corner C.sub.a point left and right crossing distances D.sub.La and D.sub.Ra respectively remain 1.0 and 0.0, and the top and bottom crossing distances D.sub.Ta and D.sub.Ba are not modified. The bottom corner C.sub.c point top and bottom crossing distances respectively remain 1.0 and 0.0, while the left and right crossings are not changed and remain D.sub.Lc and D.sub.Rc. The C.sub.d corner distances are modified, with the right and left crossing distances being clamped to the respective 1.0 and 0.0 values. The bottom crossing distance D'.sub.Bd becomes (4*(T-1/2)*D.sub.Bd), where D.sub.Bd is the unmodified bottom crossing distance. Similarly, the top crossing distance D.sub.Td is modified to D'.sub.Td =1-(4*(T-1/2)*(D-D.sub.Td)).

Lastly, FIG. 6d shows the case where 3/4.ltoreq.T<0.999: because use of all four corners implies T=1 opaqueness, only a trio of pixel corners are used (again, corners C.sub.a, C.sub.c and C.sub.d) with one corner (C.sub.b) disabled; checking enablement of only corner C.sub.b is contemplated in order to determine full opaqueness (T=1.0). The top corner C.sub.a point left and right crossing distances D.sub.La and D.sub.Ra respectively are modified to D'.sub.La =1(4*(T-3/4)*(D-D.sub.La)) and D'.sub.Ra =(4*(T-3/4)*(D-D.sub.Ra)): the top and bottom crossing distances D.sub.Ta and D.sub.Ba are not modified. The left bottom corner C.sub.c point top and bottom crossing distances respectively remain 1.0 and 0.0, while the left and right crossings are not modified and remain D.sub.Lc and D.sub.Rc. The bottom-right C.sub.d corner right and left crossing distances remain clamped to the respective 1.0 and 0.0 values, while the top and bottom crossing distance remain at their respective origin values D.sub.Td and D.sub.Bd, respectively.

The effect of the above-discussed procedure is to increase or decrease the polygon area affecting the sample corner point, as shown in FIG. 6f (for PS=0) and FIG. 6g (for PS=1). For PS=0, if the translucency T value is between 0 and 1/4, then the area of sample corner C.sub.a increases as T increases (greater opaqueness), as shown by arrow X.sub.a. If 1/4.ltoreq.T<1/2, then the area of sample corner C.sub.c increases as T increases, as shown by arrow X.sub.b and, if 1/2.ltoreq.T<3/4, sample corner C.sub.d area increases as T increases, as shown by arrow X.sub.c. The arrow X.sub.d for the increase in the sample corner C.sub.c increases in the clockwise direction, contra to the CCW increases for the other arrows, if T>3/4. The opposite changes obtain for PS=1, as shown in FIG. 6g. Each polygon portion covering a pixel may be randomly assigned a pattern-select configuration, which will facilitate derivation of total pixel color information based on the translucency, priority and color of all polygons impinging on the pixel.

POST-MEMORY PROCESSING

Having resolved corner color and translucency considerations prior to the frame buffer 44, a sequence of data signal modification steps 70-80 are carried out in the post processor-edge resolver process, flow charted in FIG. 5b. These steps can be carried out in time-independent or time-dependent (preferably, interleaved) manner with the edge crossing/corner data signal modification steps 50-65. Whatever pixel information is in the frame buffer will be used; thus, if the interception calculations become stalled or slowed, the previously-stored data signals will be used. The edge-resolution process commences at step 70, with the frame buffer 44 being accessed to obtain the pixel (Lp,Pp) corner C.sub.o constellation data signals, which are associated with the sixteen corners C11-C44 (see FIG. 5b'), positioned along four sequential edges (E+1) through (E-2). A set of twelve corner-to-corner edge segments S.sub.0 -S.sub.11 are set up in step 71; each generalized pixel edge segment S.sub.x (see FIG. 5b") extends between a pair of corners C.sub.v and C.sub.w and each corner has a crossing distance D.sub.V or D.sub.W associated therewith. In order to obtain the length l of each segment, decision step 72 is first entered and an initial determination is made as to whether both D.sub.V and D.sub.W cover segment S.sub.x. If so, then the normalized segment length l must be 0.5 (step 73); if not, step 74 determines if both distances D.sub.V and D.sub.W are less than the S.sub.x distance. If so, the segment length is the distance associated with the corner being considered (e.g., l=D.sub.V for corner C.sub.V), as set in step 75; if not, step 76 is entered and the translucency of both corners is checked. If only one corner crossing is translucent, step 77 makes the segment length l the associated distance and also sets the translucency flag, but if both crossings are translucent, step 78 sets the segment distance l to an average of the distances D.sub.V and D.sub.W. All of steps 73, 75, 77 and 78 exit to step 79, where the segment number S.sub.x (for 0.ltoreq.S.ltoreq.11) is checked to determine if further segments need to be processed for that pixel. If so, step 80 increments the segment number S and returns the process to step 71; if not, the segment information data signals are ready for transfer to the Color Mixer.

Referring also now to FIG. 7, the edge register and edge resolver portions 46-1 and 46-2 of post processor means 46, may, instead of a specially-programmed computational unit(s), use dedicated logic means receiving corner data input signals on an input bus 81, from the frame buffer. Three first-in-first-out data registers 82a-82c are sequentially connected, so that a temporally different one of four sequential edge data signal trains appears on each of busses 81a-81d. The data for corners on the lower edge E of the present pixel line L will be on bus 81b, while register means 82b has made available on bus 81c the stored immediately-previous line of corner data signals and so provides edge (E-1), and register means 82c has made available on bus 81d the stored data signals from edge (E-2) previous to the (E-1) edge. A subsequent edge (E+1) is then currently available on bus 81a; thus, it will be seen that each pixel P, on line L, is processed only after the data is stored and available for the next-subsequent edge (E+1), which requires availability of the next line (L+1). At any instant, the corner nodes C44, C34, C24 and C14 hold present information, which will (responsive to a next-cycle clock) be entered into a subsequent associated one of holding register means 84, such as: register means 84a has the corner C43 data at its output; register means 84b has the corner C33 data at its output; register means 84c has the corner C23 data at its output; and register means 84d has the corner C13 data at its output. Two subsequent sets of registers 85a-85d and 86a-86d hold other subsequent pixel data, to provide data signals respectively for the different respective corners C42, C32, C22, C12 and C41, C31, C21, C11. Coupled to the proper associated pair of corner data signal nodes is one of a dozen segment calculation means 88a-88l, each providing a calculated segment length l data signal at its associated output 88a'-88l'. Thus, the S.sub.0 segment length l.sub.0 ' data signal is provided by calculation means 88a connected between the C12 and C22 nodes; the S.sub.1 segment length l.sub.S1 data signal l.sub.1 ' is provided by calculation means 88b connected between the C13 and C23 nodes; the S.sub.2 segment length l.sub.S2 data signal l.sub.2 ' is provided by calculation means 88c connected between the C21 and C22 nodes; the S.sub.3 segment length l.sub.S3 data signal l.sub.3 ' is provided by calculation means 88d connected between the (222 and C23 nodes; and so forth, up to the S.sub.11 segment length l.sub.S11 data signal l.sub.11 ' which is provided by calculation means 88l connected between the C33 and C43 nodes. All twelve segment length data signals, for the pixel (Lp,Pp) presently being processed, are then sent to the Color Mixer means 46-3.

In order to display the proper color information for each pixel 36, the signal data for 16 (4.times.4) adjacent sample corners C.sub.11 -C.sub.44 (see FIG. 5c) is fetched from the video memory; the sample corner points surround the pixel (Lp,Pp) to be computed. The ultimate goal is to mix a set of four corner blend colors B, e.g. blend color B.sub.tl for the top left (tl) corner C.sub.tl, blend color B.sub.tr top right (tr) corner C.sub.tr, blend color B.sub.bl bottom left (bl) corner C.sub.bl, and blend color B.sub.br bottom right (br) corner C.sub.br, each of which is computed, from the respective corner C.sub.ij sampled colors C.sub.ij ', by:

Referring to FIG. 5c, 5d and 5e, the Color Mixer includes Small Polygon Filtering processing (FIG. 5d) followed by Color Computation processing (FIG. 5e).

SMALL POLYGON FILTER

While most face polygons 36 will be sufficiently large so as to cover a plurality of pixels 38, it is possible to have a polygon which will just cover a single pixel. It is also possible to have a polygon, at some level of detail, which is too small to totally cover one pixel. Polygons which are smaller than one pixel, or which have a dimension less than the corner sample point distance D intervals, will scintillate, because, at some positions, the polygon will lie on a sampled corner and be visible, while at other positions the polygon will He between sample corners and not be visible. Small polygons can be detected and filtered (removed or blurred) to reduce scintillation. To do this, each of the four corners C.sub.tl, C.sub.tr, C.sub.bl and C.sub.br of the present pixel 36 are considered independently. A blend value is computed based on the size of the polygon which covers that corner sample point. The blend color is blended with the color of the sample point. The smaller the polygon the more of the blend color is used instead of the sample point color. The segment crossing lengths l are used to compute the blend value for each corner. This may be done with a procedure which, using corner C.sub.tl as an example for step 90a, computes a blend value expressing the various distances. First, find vertical length lvert and horizontal distance lhorz (step 91); then determine first and second blend coefficients Blend.sub.-- 1 and Blend.sub.-- 2 (step 92), and take the minimum thereof (step 93) to get a Blend.sub.-- tl coefficient. Normalize by comparing the Blend.sub.-- tl coefficient to a value of 1.0 (step 94) and clamp, if necessary, to a maximum value of 1 (step 95). Step 96 does the four-corner color averaging described above, and then step 97 determines if any crossing distance l.sub.Sx, for x=0, 2, 3, 4, 5 or 10, i.e. on segments S.sub.0, S.sub.2, S.sub.3, S.sub.4, S.sub.5 or S.sub.10 (the segments which, if extend, would pass through corner C.sub.tl) are obtained from a translucent polygon. If so, the blend color value is ignored (step 98) and set to 0; if no translucent polygons are involved, step 99 finds the blended.sub.-- tl.sub.-- color B.sub.tl ', which becomes the final tb.sub.-- blend.sub.-- color value B.sub.tl. This process is repeated in step 90b to find the color for the other three sample points of the pixel, i.e. for the top right corner C.sub.tr, the bottom left corner C.sub.bl and the bottom right corner C.sub.br to find the respective final blend color values B.sub.tr, B.sub.bl and B.sub.br thereat.

Referring now to FIG. 5e, the final Color computation process of the color mixer 46-3 starts with step 92, in which the number of non-covered crossings of the four pixel sides (segments S.sub.3, S.sub.5, S.sub.6 and S.sub.8) are counted. The Edge Count number (which must be either zero or at least two) and translucency conditions are used in step 93. If there are 2 edge crossings and none of the four sample corners has a translucent polygon covering it (as determined by a check of the translucency flag) it is assumed that a single polygon edge crosses the present pixel; two areas (an area A1 of a first covering polygon and an area A2, of another covering polygon) need to be computed. This may be seen upon consideration of FIGS. 8a-8f, which show the six possible conditions for a 2-edge crossing situation: in FIG. 8a, edge 39 is near-vertical and so cuts segment S.sub.3 into two portions (a left portion with normalized length l.sub.3 and, since the total normalized length of any pixel segment is, identically, 1, a right portion with normalized length of (1- l.sub.3)); the bottom segment S.sub.8 is cut into two portions (a left portion with normalized length l.sub.8 and a right portion with normalized length (1- l.sub.8)-area A1=0.5(l.sub.3 + l.sub.8) and area A2=1-A1 (in all cases), while the pixel color CP is given by

In FIG. 8b, edge 39 is near-horizontal and cuts left segment S.sub.5 into two portions (a top portion with normalized length l.sub.5 and a bottom portion with normalized length (1- l.sub.5); the right segment S.sub.6 is cut into two portions (a top portion with normalized length l.sub.6 and a bottom portion with normalized length (1- l.sub.6)-area A1=0.5(l.sub.5 + l.sub.6), while the pixel color CP is

Similarly, in the case of FIG. 8c, the areas are A1=0.5(l.sub.5 * l.sub.3), with pixel color

In the case of FIG. 8d, A1=0.5(1- l.sub.5)* l.sub.8, with

In the case of FIG. 8e, A1=0.5(1- l.sub.3)* l.sub.6, with

Finally, for the case of FIG. 8f, A1=0.5((1- l.sub.8)*(1- l.sub.6), with

If there are not two edge crossings, or if the translucency flag bit is set at any of the four corner sampling points, then the pixel is treated as having four separate areas A1, A2, A3 and A4 and 4 crossings; an area-weighted computation step 95 must be used. This is shown graphically in FIG. 8g; the areas compute as: ##EQU1## The final mixed pixel Color CP data is thus:

The mixed color CP information for the pixel having been finally determined in either step 94 or 95, this pixel color data signal is output to the display, for presentation to viewer 20.

While one presently preferred embodiment of the apparatus and methods for determining pixel color content in a computer image generator has been described in detail herein, many variations and modifications will now become apparent to those skilled in the art. It is therefore our intent to be limited only by the scope of the appending claims and not by way of the specific instrumentalities and steps presented by way of explanation herein.