In article <1992Aug6.172329.8196@ncar.ucar.edu>, bill@virga.rap.ucar.edu (Bill Myers) writes:
|> At SIGGraph '92, I got the impression that alpha blending and anti-aliasing
|> are handled differently in the Reality Engine than the VGX. In particular,
|> I think I understood that alpha blended polygons do not have to be
|> rendered back to front in order to be rendered 'correctly' on the Reality
|> Engine. Can anyone sufficiently familiar with the Reality Engine comment?
|> If so, are you at liberty to give a brief explanation as to how this is
|> done? Thanks.
|>
|> Bill Myers
|> bill@virga.rap.ucar.edu
You cannot really lump Alpha Blending and Anti-Aliasing into one class of operations here. RealityEngine does indeed perform anti-aliasing differently from the VGX/VGXT class of machines. On the VGX/VGXT, anti-aliasing was performed on the fly as vectors, points and polygons were rendered, impacting multiple pixels downstream in the frame buffer for each pixel being rendered. This allowed the VGX/VGXT to smooth out the points and edges using a weighting function around the primary pixel.
On RealityEngine, anti-aliasing is performed farther downstream in the graphics pipeline. When the system determines the coverage of a pixel by a vector point or polygon, it does so by checking the coverage for each of a number of sub-samples within that pixel. There is sufficient memory in the RealityEngine frame buffer to support up to 16 sub-samples per pixel, including a sub-sampled Z value to insure that false edges created through z-buffering are properly anti-aliased.
Just like the VGX/VGXT, the RealityEngine maintains positional accuracy of vertices down to an 8x8 subpixel grid, or 64 subpixels/pixel. On the VGX, this is used to determine how to weight the rendering of multiple pixels for each pixel drawn to perform anti-aliasing. On RealityEngine, however, from 0-16 of those subpixel locations are designated as sample points. The system then determines not the coverage of the pixel, but of each of the multiple sub-pixel sample points.
The number of covered sub-samples determines the rendering weight of the primitive (point, vector, poly) being rendered (i.e. if 6 of 8 samples are covered, the pixel would be blended with 75% of the color of the primitive). There is virtually no performance impact when performing this type of anti-aliaing on the RealityEngine, while the older style anti-aliasing resulted in a 2-to-1 performance hit on a VGX/VGXT machine.
Alpha Blending is much the same on RealityEngine as for the VGX/VGXT except that computations are performed at a sub-pixel rather than a pixel level. Sorting still helps.
