Computer graphics processing and selective visual display system – Computer graphics display memory system – Plural storage devices
Reexamination Certificate
2000-12-06
2004-10-05
Bella, Matthew C. (Department: 2676)
Computer graphics processing and selective visual display system
Computer graphics display memory system
Plural storage devices
C345S544000
Reexamination Certificate
active
06801205
ABSTRACT:
TECHNICAL FIELD
The present invention relates generally to computer graphics and virtual image generation. More particularly, the present invention relates to a method for reducing transport delay in a synchronous graphics image generator for real-time simulators.
BACKGROUND ART
For many years image generators have been a key component of simulation devices used to train operators such as airline pilots. The value of the training experience is highly dependent on the realism of the simulation. One aspect of simulation devices that has received much attention over the years is transport delay, or latency. Transport delay is defined as the time for a stimulus, such as the pilot moving the control stick, until the last pixel on the screen has been drawn
24
, as shown in FIG.
1
.
Many training simulators have a house sync
20
that is used to synchronize all of the simulation hardware. Each time the vehicle host computer receives a house sync pulse, it will sample the current position of the controls and switches and compute the behavior of the vehicle. Upon completion, the updated positional information will be sent to the image generators so the display image can be updated. The time it takes to actually sample the controls and switches and then send this information to the image generator is the host delay
22
. The image generator also has a field sync
26
which times and regulates the image generator functions.
One important area of delay is the delay of the image generator. The image generator's portion of this delay is defined as the time from when the image generator receives a position update from the host computer until the last pixel is drawn on a visual display which represents the new position
28
. Note that the field sync pulses have the same period as the house sync, but they are not necessarily aligned.
Two aspects of transport delay are critical to training. The first aspect is determinism, or repeatable delay. The second important aspect is the length of the transport delay. If the transport delay does not remain constant, or if the delay is too long, the operator will often be overcome with simulator sickness.
There are two basic architectures in use today for simulation visual systems. One architecture provides a shorter transport delay than the other, but it is substantially more expensive and less deterministic than the other approach. Typical workstation visual systems consist of the major processes, as shown in
FIG. 2A. A
simulator host computer sends an eye position update to the image generator. The visual system has a real-time controller which receives this update and computes the transformation matrices and other parameters necessary to render an image from the new current position
10
. Those transformation matrices are then applied to all of the potentially visible primitives (polygons, lines, dots, etc.) in the simulation database
12
. Once transformed into screen space, the primitives are loaded into the FIFO queue
13
. Then the primitives can be rendered
14
into a pixel frame buffer memory
15
, and displayed on the pilot's view screen
16
.
This first basic architecture is a standard three-dimensional (3D) graphics computer or a workstation system which can be used to perform these operations. With such an architecture, the visual system's transport delay is illustrated in FIG.
3
. The vertical arrows
30
a,
30
b,
30
c
represent the transfer of positional information from the host computer to the image generator. The dark shaded boxes represent the flow of one field of data through the graphics pipeline. The box indicates the amount of time allocated for each process, while the shaded portion indicates when the process is active. Usually the process will complete before the allocated time is up, as indicated by the sloped right edge of the shaded portion. If the process takes longer than the available time, the system will be in an overload condition. The lighter shaded boxes show how adjacent fields are processed back to back.
The simulation host computer sends positional update information
30
a
-
30
c
to the image generator once each display field. The real-time controller then computes the matrices and other At information needed to display the scene
32
. The real-time calculations begin as soon as the system receives input from the host (the black down arrow
30
a
). The real-time controller computes the eye position matrices, computes the position and orientation of moving models, updates embedded system behaviors, and then begins processing the database. This computation usually takes about ½ of a field time. The amount of time needed for this computation is dependent on the database, the current eye position, and the number of complex auxiliary functions and behaviors.
The geometry processing then begins on the primitives in the scene
34
. As each primitive is transformed, it is handed to the rendering hardware
36
. Specifically, the geometry processing begins storing processed polygons in its output FIFO queue as quickly as possible. Once the FIFOs contain data, the rendering engine can begin processing those primitives. As pixels are produced by the rendering engine, they are stored in a double buffered pixel memory while the previous field's data is being sent to the display for screen refresh. One full field time is allocated for this process, but it is important to complete both processes before the end of the field time or the system will be in an overload condition. Once the new image has been completed and written into one side of a double buffered pixel frame buffer, the buffer will be ready to toggle, or swap, at the next field sync pulse. After toggling, the new image is presented to the display device
38
. Thus, the total transport delay for the visual system is 2.5 fields. As mentioned, standard image generator transport delay is measured from the input of host data (the down arrow
30
a
) to the display of the very last pixel on the screen (the right edge of the darkened display box
38
).
Unfortunately, this approach has drawbacks that make it difficult to maintain deterministic behavior. Primitives cannot be rendered until after the geometric transformation operations are performed. The time required to find primitives and transform them is highly dependent on the database structure and the current position within the database. The time required to render primitives is directly related to their size on the screen. It seldom occurs that the geometry and rendering processes require the same amount of time, so one process usually ends up waiting for the other. This means that either the geometry engine or the rendering engine will sit idle during some portion of the field which reduces the efficiency of the system. Specifically, the FIFO between the geometry process and the rendering process cannot always guarantee optimum performance. If the rendering engine receives many small polygons, the FIFO may be drained faster than the geometry process can generate new polygons. This can cause the rendering process to be starved, and waste valuable rendering time. On the other hand, the rendering process may run too slowly on very large polygons, causing the FIFOs to fill up and the geometry process to stall. Furthermore, this loss of efficiency will often cause the system to overload since the entire job cannot be completed on time. The interactions between the geometry process and rendering process make load management more difficult since it is difficult to isolate which process is causing the overload condition. As a result, many systems need more geometry and rendering hardware than was originally expected, which increases the cost of the overall system. This non-deterministic characteristic makes this architecture less than an optimum choice for simulation applications. The efficiency of this system can be improved by using very large FIFOs and delaying the rendering operation until the FIFOs are sufficiently filled by the geometry operations to prevent the rendering process from r
Gardiner Harold Dee
Hadfield Steve O.
Bella Matthew C.
Evans & Sutherland Computer Corporation
Singh Dalip K.
Thorpe North & Western LLP
LandOfFree
Method for reducing transport delay in a synchronous image... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Method for reducing transport delay in a synchronous image..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method for reducing transport delay in a synchronous image... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3289779