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