III. HIGH QUALITY/HIGH SPEED 
RENDERING 
GTRI initially developed perspective scene 
rendering in the mid 1970's. Since that 
time development has occurred both in 
computing and graphics hardware , but also 
in the software implementation of perspective 
view algorithms. Whereas, most of the 
perspective generation techniques were 
implemented in somewhat system specific 
Fortran code in the 70's and early 80's, 
today's trend is toward C and C+ + versions 
of rendering algorithms that can be directly 
implemented on almost any Unix 
workstation. There are many aspects of 
rendering that must be considered when 
designing or implementing a system. One 
must determine the necessary quality of a 
perspective image that is required by an 
application. Next, one must determine how 
fast that rendering process needs to happen to 
adequately support the application. Usually, 
the higher the quality of the rendered scene, 
the longer the time is for rendering. For a 
number of years, Georgia Tech has made the 
distinction that it would rather produce 
higher quality rendering than faster rendering 
of lower quality images. With today’s 
technology, that distinction may not have to 
be made. 
Flight simulation companies, until recently, 
have always relied on high speed specially 
designed hardware to achieve real time rates. 
When a scene was to be rendered, a multi- 
processing or parallel environment was used 
to render terrain and natural and manmade 
objects. Before the use of high speed 
random access memory (RAM) and video 
RAM, a display list of polygons and vectors 
was used to sort which things within the 
terrain and objects should be placed in front 
of others. Since this sorting and the display 
of the result had to be accomplished in 
1/30th of a second, only limited resolution 
databases and object descriptions were 
allowed. In all except the very high end 
simulators (6 to 10 million dollars), the real 
time simulation looked cartoonish and was 
116 
not totally effective in training. A person 
training on the system often would get 
distracted by graphical artifacts instead of 
concentrating on the content of the image 
presented. The larger simulation systems 
used a large number of specialized 
processors, and the computing engines, 
themselves, sometimes occupied whole 
rooms. 
The advent of cheaper RAM and video 
RAM caused most manufacturers to 
switch to a more effective rendering 
technique using a depth buffer approach 
instead of sorting polygons and vectors by 
distance and then displaying the results. 
The depth buffer replaced the sorting 
function of the rendering. The depth 
buffer was memory associated with every 
image picture element (pixel) that held the 
distance between the viewer and that point 
on the terrain. Individual terrain 
polygons could be then rendered in a 
brute force manner using the depth buffer 
to automatically provide the sorting. As 
each polygon from the terrain or object 
was considered, the world coordinates of 
each vertex of the polygon was 
geometrically transformed into the output 
image space and an interpolation process 
was used to fill in the color values within 
the output image based on the distance in 
the depth buffer for that image pixel. By 
the late 1980's, the depth buffer approach 
was being used even in the most 
expensive simulation systems. To achieve 
the necessary update rates, parallel 
processing and multi-processing hardware 
were still used with the depth buffer 
common to all rendering processes. 
Texture mapping was used in many of the 
simulation systems to provide artificial 
detail in areas of the terrain that were of 
little interest. ^ Generic, mathematical 
textures were developed for tree canopy, 
grass, brick buildings, etc. where a 
regular function could add detail to a 
terrain polygon. Much expertise was 
required in a simulation design to 
determine which parts of a database 
needed 
could ; 
Techni 
were 
polygo 
given 
comple 
polygo 
while 
adequa 
polygo 
this te 
represe 
compu 
high re 
manma 
Norma 
given 
second 
terrain 
the obj 
may n 
tradeof 
always 
In the 
trend 
generic 
determ 
image 
used. 
project 
mather 
determ 
Instead 
transfo 
transfo 
popula 
especie 
portray 
urban | 
environ 
to desc 
to see 
rectang 
digitize 
be maj 
simulat 
photo 1 
polygo