Author(s)
`
`Title
`
`Publisher
`
`Issue Date
`
`URL
`
`Smith, Douglas Bernard.; Streyle, Dale Gerard.
`
`An inexpensive real-time interactive three-dimensional flight simulation system
`
`1987
`
`http://hdl.handle.net/10945/22294
`
`This document was downloaded on May 22, 2015 at 14:41:01
`
`1
`
`MS 1014
`
`

`

`w...” . ”an .
`
`. n ...,m. ..
`
`.,
`
`2
`
`

`

`
`
`3
`
`

`

`DUDLEY KNOX LIBRARY
`NAVAL POSTGRADUATE SCHOOL
`
`MONTEREY, CALIFORNIA 93943-5002
`
`4
`
`

`

`
`
`5
`
`

`

`NAVAL POSTGRADUATE SCHOOL
`Monterey,Oalif0rnia
`
`
`
`THESIS
`
`AN INEXPENSIVE REAL—TIME
`
`INTERACTIVE THREE—DIMENSIONAL
`FLIGHT SIMULATION SYSTEM
`by
`
`Douglas Bernard Smith
`
`Dale Gerard Streyle
`
`June 1987
`
`
`
`Thesis Advisor:
`
`M. J. Zyda
`
`Approved for public release; distribution is unlimited.
`
`6
`
`

`

`
`
`7
`
`

`

`unclassified
`uflIIY CLAS IFI A I N
`E
`
`IHI
`
`PAL;
`
`I REPORT SECURITY CLASSIFICATION
`
`unclassified
`I SECURITV CLASSIFICATION AUTHORITY
`
`REPORT DOCUMENTATION PAGE
`Ib RESTRICTIVE MARKINGS
`
`3 DISTRIBUTION!AVAILABILITY OF REPORT
`
`
`I DECLASSIFICATIONIOOWNGRADING SCHEDULE
`
`PERFORMING ORGANIIATION REPORT NUMBERIS)
`
`Approved for public release;
`distribution is unlimited.
`S MONITORING ORGANIZATION REPORT NUMBERIS)
`
`
`
`NAME OF PERFORMING ORGANIZATION
`
`Ival Postgraduate School
`
`ADDRESS (00/, Sure. Jnd ZIPCOde}
`
`
`52
`
`
`Ionterey, California
`
`93943-5000
`
`NAME OF FUNDING/SPONSORING
`ORGANIZATION
`
`
`
`7) NAME 05 MONITORING ORGANIZATION
`6t) OFFICE SYMBOL
`
`
`(I! opphuble)
`
`Naval Postgraduate School
`
`
`
`7!: ADDRESSICIW. State, and IIPCode)
`
`
`93943-5000
`California
`Monterey,
`
`8b OFFICE SVMEOL
` 9 PROCUREMENT INSTRUMENT IDENTIFICATION NUMBER
`
`(I! aoplluble)
`
` ADDRESS (CII'y, “attend ZIPCon) IO SOURCE OF FUNDING NUMBERS
`
`WORK UNIT
`PROGRAM
`PROJECT
`TASK
`
`
`ELEMENT NO
`NO
`NO
`ACCESSION NO
`
`TITLE (Include Security Clamhunon)
`
`AN INEXPENSIVE REAL-TIME INTERACTIVE THREE-
`DIMENSIONAL FLIGHT SIMULATION SYSTEM
`
`
`
`
`
`pEnSONAL AUTHORIS)
`
`Smith, Douglas Bernard and Streyle, Dale Gerard
`
`I TYRE O‘ “EpfflTesj-S
`L'Ster 5
`SLPPLEMENTARY NOTATION
`
`1]!) T‘ME COVERED
`FROM
`
`118g? Ojafi’gill'
`
`(YeJI,MonTh Day)
`
`15
`
`DAZCIEB §OONT
`
`_‘ no
`
`COSATI CODES
`
`SUB‘GROUP
`
`ABSTRACT (Connnuo on reverse I! neruury and Idennfy by blotk number)
`
`I prototype flight simulator for the Fiber—Optically Guided Missile
`:FOG-M)
`is presented. This prototype demonstrates the practicability and
`Feasibility of using low-cost graphics hardware to produce acceptable
`Iimulation of flight over terrain generated from Defense Mapping Agency
`:DMA) digital elevation data.
`The flight simulator displays a dynamic,
`:hree—dimensional, out-the—window View of the terrain in real<time while I
`‘esponding to operator control
`inputs.
`The total system cost {software
`
`Ind hardware] of the simulator is an order of magnitude less than most
`Flight simulation systems in current use.
`
`
`
`
`
` D S‘R'SUTION/AVAILABILITY OF ABSTRACT
`
`
`C] DTIC USERS
`acNCLASSIFIED/UNL'MITED D SAME AS n97
`
`
`)i‘fg EESCPRNSIefl E IEOIVI%U);Aaa
`
`
`33 APR edmon my be used unhlexhauned
`FORM 1473,34 MAR
`Allomer edmom are 00501“!
`
`2I ABSTRACT SECURITY CLASSIFICATION
`
`220 TELEPHONE (Indudo Area Code) 22: OHILE SYMBOL
`
`“CUR,” CLMSWCAHON 3; was MG
`unc a551fiea
`
`
`
`l
`
`8
`
`8
`
`

`

`Approved for public release; distribution is unlimited.
`
`An Inexpensive Real—Time
`
`Interactive Three—Dimensional
`
`Flight Simulation System
`
`by
`
`Douglas Bernard [Smith
`Captain, United States Marine Corps
`
`B. 3., Duke University, 1981
`
`and
`
`Dale Gerard Streyle
`
`Lieutenant, United States Coast Guard
`
`B. 8., United States Coast Guard Academy, 1980
`
`Submitted in partial fulfillment of the
`
`requirements for the degree of
`
`MASTER OF SCIENCE IN COMPUTER SCIENCE
`
`from the
`
`NAVAL POSTGRADUATE SCHOOL
`
`"\
`
`June 1987
`
`l
`
`_
`
`9
`
`

`

`ABSTRACT:
`
`A prototype flight simulator for the Fiber-Optically Guided Missile (FOG-M)
`
`is presented. This prototype demonstrates the practicability and feasibility of
`
`using low-cost graphics hardware to produce acceptable simulation of flight over
`
`terrain generated from Defense Mapping Agency (DMA) digital elevation data.
`
`The flight simulator displays a dynamic, three-dimensional, out-the-window view
`
`of the terrain in real-time while responding to operator control inputs. The total
`
`system cost (software and hardware) of the simulator is an order of magnitude
`
`less than most flight simulation systems in current use.
`
`10
`
`10
`
`

`

`TABLE OF CONTENTS
`
`INTROD UCTION .....................................................................
`
`A. FOG-M ..
`
`1. Background .....................................................................
`
`2. Description ......................................................................
`
`B. ASPECTS OF FLIGHT SIMULATION ..............................
`
`I. Realism ...........................................................................
`
`2. Frame Update Speed ......................................................
`
`c. ORGANIZATION ...............................................................
`
`II.
`
`COMPUTER SYSTEM .............................................................
`
`A. HARDWARE AND SYSTEM OVERVIEW .......................
`
`B. SOFTWARE .......................................................................
`
`III.
`
`DIGITAL ELAVATION TERRAIN DATA ..............................
`
`A.
`
`INTRODUCTION ...............................................................
`
`B. COVERAGE .......................................................................
`
`C. STRUCTURE .....................................................................
`
`D. LOCATION .........................................................................
`
`TWO-DIMENSIONAL TERRAIN MAP PORTRAYAL ..........
`
`A. COLORS
`
`IO
`
`10
`
`10
`
`ll
`
`12
`
`13
`
`14
`
`15
`
`16
`
`16
`
`18
`
`20
`
`20
`
`20
`
`22
`
`25
`
`25
`
`11
`
`11
`
`

`

`B. DRAWING ..........................................................................
`
`C. WRITEMASKS ...................................................................
`
`1. Color Table .....................................................................
`
`2. Bitplanes .........................................................................
`
`3. Writemask Example .......................................................
`
`4. Writemasks in FOG-M ...................................................
`
`V.
`
`THREE-DIMENSIONAL TERRAIN CONSTRUCTION ..........
`
`A. REPRESENTATION DECISIONS .....................................
`
`1. Polygons versus Patches .................................................
`
`2. Resolution .......................................................................
`
`3. Elevation Scaling
`
`.........................................................
`
`4. Shading and Texturing ...................................................
`
`a. Elevation Based Shading ...........................................
`
`b. Lambert’s Cosine Law Shading .................................
`
`c. Gouraud Shading ......................................................
`
`(1. Adding Texture ........................................................
`
`B.
`
`INTERNAL DATA STRUCTURES ....................................
`
`VI.
`
`FLIGHT SIMULATION ............................................................
`
`A. OVERVIEW ........................................................................
`
`B. UPDATING THE MISSILE’S POSITION ..........................
`
`28
`
`29
`
`29
`
`29
`
`30
`
`32
`
`34
`
`34
`
`34
`
`36
`
`36
`
`38
`
`38
`
`39
`
`41
`
`43
`
`44
`
`46
`
`46
`
`46
`
`12
`
`12
`
`

`

`1. Case 1 - Operator Control ...............................................
`
`2. Case 2 - Locked Onto a Target .......................................
`
`C. DETERMINING THE LINE OF SIGHT ............................
`
`D. DISPLAYING THE SCENE ...............................................
`
`1. Viewing Transformations ................................................
`
`2. Determining Which Polygons to Draw ...........................
`
`47
`
`48
`
`50
`
`52
`
`52
`
`58
`
`3. Hidden Surface Removal .................................................
`
`60
`
`E. SIMULATOR PERFORMANCE ........................................
`
`VII.
`
`TARGET INTEGRATION .......................................................
`
`A. GENERAL ..........................................................................
`
`B. TARGET CREATION ........................................................
`
`1. The System Matrix .........................................................
`
`2. Target Transformations ..................................................
`
`C. ANIMATION ......................................................................
`
`D. DISPLAY ............................................................................
`
`VIII.
`
`CULTURAL FEATURE INTEGRATION ................................
`
`A. EXTERNAL DATA FILE FORMAT ..................................
`
`B. CONSTRUCTION OF THE ROAD POLYGONS ...............
`
`C.
`
`INTERNAL ROAD-POLYGON STORAGE .......................
`
`IX.
`
`FOG-M SIMULATOR USER’S GUIDE ....................................
`
`71
`
`71
`
`72
`
`72
`
`74
`
`75
`
`76
`
`82
`
`83
`
`87
`
`89
`
`13
`
`13
`
`

`

`A. OVERVIEW ........................................................................
`
`B. STARTING THE SIMULATION ........................................
`
`C. PRELAUNCH CONTROLS ................................................
`
`1. The Prelaunch Display ...................................................
`
`2. Selecting the Launch Position .........................................
`
`3. Selecting the Target Position ..........................................
`
`4. Launching the Missile .....................................................
`
`D.
`
`IN-FLIGHT CONTROLS ....................................................
`
`1. The In-Flight Display .....................................................
`
`2. Controlling the Camera ..................................................
`
`3. Controlling the Missile Flight
`
`.........................................
`
`89
`
`89
`
`91
`
`91
`
`95
`
`95
`
`96
`
`96
`
`96
`
`99
`
`99
`
`4. Designating and Rejecting Targets .................................
`
`101
`
`X.
`
`CONCLUSIONS AND RECOMMENDATIONS .......................
`
`103
`
`A. LIMITATIONS ....................................................................
`
`103
`
`B. FUTURE RESEARCH AREAS ..........................................
`
`C. SUMMARY AND CONCLUSIONS .....................................
`
`104
`
`APPENDIX A — MODULE DESCRIPTIONS ......................................
`
`106
`
`APPENDIX B - SOURCE LISTINGS .................................................
`
`128
`
`LIST OF REFERENCES .....................................................................
`
`INITIAL DISTRIBUTION LIST ..........................................................
`
`233
`
`235
`
`14
`
`14
`
`

`

`ACKNOWLEDGEMENTS
`
`The authors wish to express their gratitude to a number of people who
`
`supported this study. To our advisor, Dr. Michael Zyda, who provided us with
`
`the knowledge and insight necessary to complete the project, and then stepped
`
`back, allowing us the freedom to learn through exploration.
`
`To the following people who provided programs and subroutines which were
`
`incorporated into the project:
`
`- MAJ Ron Ross, USA,
`make—databasc—c routines.
`
`for
`
`the original versions of
`
`the
`
`prclaunch &
`
`- LCDR Mike Oliver, USN, for enhancements to the tank image.
`
`- Dr. Michael Zyda for the original version of the gammaramp routine.
`
`- CAPT Gary W. Taylor, USMC,
`routine.
`
`for the original version of the lightorient
`
`-= LCDR James Manley, USN, for the netV networking routines.
`
`The authors would also like to note that the order of the names on the cover
`
`is alphabetic, and has no other significance.
`
`LT Streyle would like to personally thank his wife, Robin, for the tremendous
`
`amount of patience and support provided during all phases of the project. By
`
`taking care of the myriad of details involved in running a home with two children
`
`and shuffling her and the family’s schedule around the times I absolutely had to
`
`work, she provided me the time necessary to fully pursue the project.
`
`I would
`
`also like to thank my lovely daughter Sarah and son Timothy, who both let me
`
`know when I had worked enough to “earn” another trip to the park to play.
`
`15
`
`15
`
`

`

`CAPT Smith would like to thank his wife, Becky, and son, Timothy, for the
`
`generous amounts of time and pleasures foregone in their support of this work.
`
`Thanks also to my friend and co-author, who made this and many other projects
`
`much easier and more enjoyable than they would otherwise have been.
`
`16
`
`16
`
`

`

`I.
`
`INTRODUCTION
`
`Flight simulation has been an important computer graphics application,
`
`embracing a range of systems from a $32.00 program for a personal computer
`
`[Ref. 1]
`
`to special purpose machines costing millions of dollars [Ref. 2]. The
`
`capabilities of these systems are spread across a range nearly as wide as their
`
`costs, with great variances in speed (frames displayed per second).
`
`realism,
`
`flexibility, and area of
`
`flight. We present here a system that
`
`is
`
`relatively
`
`inexpensive. yet still fast enough to present a real-time three-dimensional view of
`
`digitized terrain. We built
`
`this system on a commercially available, high-
`
`performance graphics workstation, the Silicon Graphics, Incorporated IRIS-2400
`
`Turbo. The IRIS system was selected because of its local availability and its
`
`performance capabilities. The flight simulator presented here does not use the
`
`natural color and shape of individual terrain elements (in order to achieve real—
`
`time performance), but it
`
`is sufficiently realistic to provide the feeling of flight
`
`and allow identification of the displayed terrain and targets.
`
`A.
`
`FOG—M
`
`1. Background
`
`The project presented here was built
`
`in response to the United States
`
`Army Combat Developments Experimentation Center’s need to simulate the
`
`10
`
`17
`
`17
`
`

`

`operation of the Fiber-Optically Guided Missile (FOG-M) [Ref 3], but this missile
`
`is also being considered for use by the United States Marine Corps [Ref 4].
`
`Simulation is necessary in order to test and evaluate the tactics, doctrine and
`
`training requirements associated with the missile without the expense and danger
`
`of actual firings during simulated combat field trials. The FOG—M is a generic
`
`family of remotely-piloted, video-guided munitions, but for the purpose of this
`
`prototype simulator,
`
`the weapons are all
`
`logically equivalent, and the entire
`
`family is referred to as “the missile.’
`
`In order to avoid security constraints, the
`
`3
`
`parameters and operational characteristics used in this work were not taken from
`
`exact FOG-M specifications. The parameters and technical specifications are all
`
`estimates, based on reasonableness and consistency with general, unclassified
`
`descriptions of the FOG-M.
`
`2. Description
`
`The actual FOG-M missile is six inches in diameter, five and one-half feet
`
`high, weighs eighty-three pounds, and costs about $20,000 [Ref 4].
`
`It has a video
`
`camera mounted in its nose, which transmits a black-and-white picture back to
`
`the operator’s console (which consists of a television screen, a computer, and a
`
`joystick) over the fiber—optic link. (The simulator display offers the user the choice
`
`of either color or black-and-White; color is the default for the simulator despite the
`
`operator view of the missile being black-and—white. The color compensates for
`
`some of
`
`the
`
`loss
`
`in realism and identifiability inherent
`
`in a polygonal
`
`representation of natural objects). Before launch, in normal operation, the missile
`
`11
`
`18
`
`18
`
`

`

`is given a general direction to a target and the altitude of the highest point within
`
`its
`
`range. The simulator allows values
`
`in excess of FOG-M operational
`
`capabilities for speed, range, and altitude above ground level
`
`(AGL), but the
`
`default values of two hundred knots, ten kilometers, and one thousand meters are
`
`characteristic of this type of missile. As soon as the. missile is in position, it begins
`
`transmitting video images. When launched,
`
`the missile rises to approximately
`
`two hundred feet above the highest terrain point, and then levels of? in horizontal
`
`flight
`
`in the targeted direction. The operator controls the pan and tilt angle of
`
`the camera with the joystick, and can dial in changes to the heading and altitude
`
`of the missile. The operator also has the capability to zoom the camera’s field of
`
`view from eight degrees to fifty-five degrees, and to designate (“lock-on” to) a
`
`target for automatic homing by the missile.
`
`B. ASPECTS OF FLIGHT SIMULATION
`
`There are many aSpects to flight simulation. Modern commercial simulators
`
`provide sophisticated mock-ups of cockpits and controls and highly detailed out
`
`the window views. By mounting the simulator on a moving platform, a true sense
`
`of the physical feelings of acceleration and roll can be achieved. These systems
`
`also cost millions of dollars.
`
`One of the first decisions that must be made when designing a flight simulator
`
`is, “For what purpose will the simulator be used?” The answer to this question
`
`drives most of the design decisions that have to be made. Since the purpose of
`
`12
`
`19
`
`19
`
`

`

`this project is to provide a simulation of the FOG-M missile as viewed from its
`
`operator’s console,
`
`it
`
`is felt
`
`that
`
`the most important items to model are the
`
`simulated video display of the terrain and the actual operator controls. The
`
`terrain should appear realistic enough that its major features are recognizable to a
`
`person familiar with the area. The controls
`
`should allow for
`
`the same
`
`functionality as the actual console. The simulator must, of course, also provide a
`
`feeling that the missile is in motion over the terrain. The effectiveness of the
`
`feeling of motion provided by a flight simulator can be largely measured by two
`
`criteria: the realism of the displayed scene and the update rate of the display.
`
`1. Realism
`
`Many factors contribute to the perceived realism of a displayed natural
`
`scene. Early attempts to quantitatively measure realism consisted of counting the
`
`number of “edges” or lines that a scene contained. This later gave way to
`
`counting the number of “faces” or polygons in a scene. Since each polygon was
`
`colored in a single shade, it was felt that each polygon represented a single “bit”
`
`of information in the scene. Therefore, the more polygons the scene contained,
`
`the more “realistic” it was felt to be [Ref 5:pp. 27-28].
`
`The latest advances in computer graphics have also made this measure of
`
`effectiveness obsolete. With the introduction of sySEems that are able to fill
`
`polygons with textured patterns, a single polygon can now contain thousands of
`
`“bits” of information. As a result, a scene drawn with a few textured polygons
`
`can appear more realistic than one with an order of magnitude more untextured
`
`13
`
`20
`
`20
`
`

`

`ones. Early textures consisted of superimposing things such as mathematical
`
`noise functions or stripes on the polygons. More recent advances have allowed the
`
`texture to be derived from digital photographs of a similar scene. For example,
`
`polygons representing a part of terrain covering by meadow could be filled with a
`
`digital texture derived from an aerial photograph of a meadow [Ref. 5: p. 28].
`
`Since most currently available graphics workstations do not support the
`
`use of texture filled polygons, the use of texture was deemed to be outside the
`
`scope of
`
`the current project. Rather,
`
`the project’s work concentrated on
`
`determining how realistically a scene could be rendered in real-time incorporating
`
`only the use of lighting and shading models along with terrain hidden-surface
`
`algorithms. These topics are covered in more detail in Chapter V.
`
`2. Frame Update Speed
`
`Another important aspect of a flight simulator’s performance is the speed
`
`at which it is capable of displaying successive frames in a scene. The faster the
`
`update rate, the more continuous the motion appears. As a reference, standard
`
`motion picture film is projected at a rate of twenty—four frames per second.
`
`Although the IRIS workstation is capable of displaying up to sixty frames per
`
`second, the amount of computation that must be done between successive frames
`
`in the simulation has limited the update rate to an average of three frames per
`
`second. While this presents a less than smooth motion, it is felt to be adequate
`
`for the purposes of the prototype.
`
`14
`
`21
`
`21
`
`

`

`C. ORGANIZATION
`
`The above sections of
`
`this chapter have provided background on flight
`
`simulation in general, and the missile whose flight is specifically being simulated.
`
`Chapter II provides an overview of the hardware used in running the simulation.
`
`The structure and content of the Defense Mapping Agency (DMA) Digital
`
`Terrain Elevation Data [DTED) are discussed in Chapter
`
`III. Chapter
`
`IV
`
`discusses the motivation behind and creation of the two-dimensional contour map
`
`displays. Chapter V covers the storage and use of the DMA DTED to produce a
`
`lighted and shaded three-dimensional polygonal terrain display. The mathematics
`
`and process involved in simulating flight over the terrain are detailed in Chapter
`
`VI. Chapter VII discusses the creation, insertion, animation, and designation of
`
`targets. Chapter VIII covers the creation and drawing of cultural features.
`
`Chapter IX contains a user’s guide for operation of the FOG-M simulator.
`
`Chapter X concludes with a discussion of limitations, future extensions and
`
`research topics, and summarizes the research conducted. Narrative descriptions of
`
`the modules and listings of the program source code for each of the modules are
`
`included as Appendices A and B respectively.
`
`15
`
`22
`
`22
`
`

`

`II. COMPUTER SYSTEM
`
`As discussed in Chapter I, flight simulators are nothing new. The significance
`
`of this work lies in the speed with which it was developed,
`
`the display rate
`
`achieved, and the realism and fidelity of the display in comparison to the cost of
`
`the system that supports it. This project was technically feasible only because of
`
`the capabilities and high performance of the IRIS (Integrated Raster Imaging
`
`System) Turbo 2400 Graphics Workstation, manufactured by Silicon Graphics,
`
`Incorporated. Others have also used the IRIS as a base on which to build flight
`
`simulators [Ref. 6]. This low-cost ($50,000 to $100,00) three—dimensional display
`
`system is summarized in Figure 2.1 and is discussed more fully below.
`
`A. HARDWARE AND SYSTEM OVERVIEW
`
`The IRIS has a conventional Von Neumann type computer architecture but
`
`adds custom-built special purpose VLSI circuits and a pipelined design to provide
`
`the graphics functions that are implemented in software on other comparably-
`
`priced workstations. Conceptually, there three pipelined components in the IRIS
`
`hardware:
`
`the applications/ graphics processor.
`
`the Geometry Pipeline. and the
`
`raster subsystem [Ref
`
`72p.
`
`1-1]. The applications/graphics processor
`
`is a
`
`conventional Motorola MC68020 processor running at 16.7 MHz. This processor
`
`runs the applications program(s) within a UNIX System V operating system.
`
`16
`
`23
`
`23
`
`

`

`ETHERNET to Vax and other IRIS
`
`
`
`32 bit 16.7 MHz Motorola MCSSOZO CPU
`
`6 Megabytes of CPU Memory
`
`32 1024x788 bitplanes of Display Memory
`
`Hardware matrix multiplier & floating point accelerator
`
`Hardware Gouraud shading, depth cueing & backface polygon removal
`
`12 pipelined custom VLSI Geometry EnginesTM
`16-bit Z-buffer for Hidden Surface Elimination
`
`2 72 Megabyte Winchester Disk Drives
`
`60 Hz non—interlaced 19" RGB high resolution monitor
`
`83 key up—down encoded keyboard
`
`3 button mouse
`
`32—button and 8—dial valuator boxes
`
`Unix System V
`
`Ethernet to VAX’S
`
`IRIS Graphics Library
`
`Features of the IRIS Turbo 2400 Graphics Workstation
`
`Figure 2.1
`
`17
`
`24
`
`24
`
`

`

`Applications either issue graphics commands in immediate mode,
`
`in which case
`
`they are sent through the Geometry Pipeline immediately as individual graphics
`
`primitives, or compile graphics commands into graphical objects,
`
`in which case
`
`they are sent through the Geometry Pipeline as a single geometric entity when
`
`explicitly called at some later point in time.
`
`The Geometry Pipeline takes commands
`
`in terms of
`
`the user’s world
`
`coordinates, performs specified matrix transformations on them using the matrix
`
`multiplier and floating point accelerator built into the hardware, and then clips
`
`and scales
`
`the transformed coordinates into screen coordinates. The raster
`
`subsystem takes the screen coordinates output by the Geometry Pipeline and
`
`updates the bitplanes
`
`(display memory)
`
`to contain the lines, polygons, or
`
`characters specified by the input coordinates. The raster subsystem also performs
`
`polygon fill, shading, depth—cueing, and hidden surface removal. A conventional
`
`video controller uses the values in the bitplanes and the color table to produce an
`
`image on the monitor.
`
`B. SOFTWARE
`
`The C programming language is native to UNIX and is the language used for
`
`all of the IRIS system software. The IRIS Graphics Library. which provides both
`
`high- and low—level graphics and utility commands, can be called in C,
`
`FORTRAN, Pascal, or LISP. However, due to the built—in bias of UNIX and the
`
`IRIS, plus the local pool of knowledge,
`
`the C programming language was the
`
`18
`
`25
`
`25
`
`

`

`pro forma choice for programming all parts of the FOG—M simulator. The IRIS
`
`User’s Guide [Ref 7] breaks the Graphics Library commands into the following
`
`twelve categories:
`
`- Global State commands initialize, the hardware and control global variables,
`and are used mostly in FOG-M’s init_iris routine.
`
`- Drawing Primitives are used throughout FOG-M. They create points, lines,
`
`polygons, circles, arcs, and text strings.
`
`- Coordinate Transformations specify mappings within and between user-
`defined world coordinates and screen coordinates. These are used to move
`
`targets and to simulate flight.
`
`- Drawing Attribute commands specify textures and fonts. Although texture
`
`would greatly improve the appearance of the terrain,
`
`the IRIS provided
`
`textures are applied in the screen coordinate system, so they do not scale or
`
`tilt to conform to the terrain, and produce a very artificial result.
`
`— Display Mode and Color commands determine how the bitplanes are used
`
`and what colors appear on the screen. These include the commands that set
`
`double—buffering, establish writemasks, and define the color table.
`
`- Input/Output commands initialize and read the dials and mouse.
`
`- Object Creation and Editing commands
`
`allow manipulation of complex
`
`displays as a single entity. They are used in all FOG-M displays.
`
`- Picking and Selecting commands are not used in FOG-M.
`
`- Geometry Pipeline Feedback commands are not used in FOG-M.
`
`- Curve and Surface commands draw complex curves and smooth surfaces.
`
`Experiments with these produced more realistic terrain images, but not even
`
`close to real-time, making flight animation impossible.
`
`- Shading and Depth—cueing commands provide Gouraud shading of polygons
`
`and intensities that vary with distance from the viewer.
`
`- Teztport commands define an area of the screen for text. They are not used
`in FOG—M.
`
`Also available on the system, and used by FOG—M, are the math library with
`
`sine, cosine, arctangent, hypotenuse, and exponentiation functions, and routines
`
`that access the system clock in order to determine elapsed time.
`
`19
`
`26
`
`26
`
`

`

`III. DIGITAL ELEVATION TERRAIN DATA
`
`A.
`
`INTRODUCTION
`
`Unlike other flight simulation systems, which may rely on manual creation of
`
`the terrain [Ref. 8], the source data for the terrain in the FOG-M simulation is a
`
`Defense Mapping Agency (DMA) digital terrain elevation database (DTED) for
`
`Fort Hunter—Liggett. California. The database is not Level 1 DTED, but rather a
`
`DMA special product produced about 1980 at a higher resolution than normal
`
`Level 1 DTED [Ref. 9]. Level 1 DMA data contains elevation points spaced at
`
`three arc-second intervals, or approximately every one hundred meters. The Fort
`
`Hunter—Liggett special data contains points at twelve and one-half meter spacing,
`
`which is eight times the resolution of Level 1 data.
`
`B. COVERAGE
`
`The area covered by the database is thirty-six kilometers wide and thirty-five
`
`kilometers high, with 6400 data points per square kilometer. This area includes
`
`most of Fort Hunter-Liggett plus some surrounding land, and is bounded by
`
`latitudes 36° 05' 00" I’to the north) and 35° 50' 00” (south) and longitudes
`
`1210 04' 30” (east) and 1210 20’ 30” (west). In terms of Universal Transverse
`
`Mercator
`
`(UTM) coordinates,
`
`the area has easting (X) of
`
`IOSFQ41000 t0
`
`108FQ77000 and northing (Y) of 108FQ60000 to IOSFQQSOOO. The database
`
`20
`
`27
`
`27
`
`

`

`appears to be based on DMA forty foot interval contour map products, because
`
`peaks tend to have flattened tops. This was confirmed both by a comparison of -
`
`surveyed instrumentation sites on or near peaks with their digital terrain values
`
`[Ref. 10: pp. 1-2], and by a Bezier surface patch image of the data created locally.
`
`C. STRUCTURE
`
`The data is stored in an unformatted sequential file that is organized as a
`
`stream of integers. Each integer [sixteen bits) represents both the vegetation code
`
`and bald terrain elevation in feet at one sampling point, as illustrated in Figure
`
`3.1 below.
`
`Veg. Code
`
`Bald Terrain Elevation
`
`bitzl514131211109876543210
`
`Figure 3.1 DTED Data Encoding
`
`The thirteen low-order (rightmost) bits contain the elevation, allowing a range
`
`from zero to 8191 feet. although the highest point in the database is 3744 feet.
`
`The three high-order (leftmost) bits specify one of eight vegetation codes, which
`
`are given in Table 3.1 below. Vegetation codes are only available for points
`
`within the boundaries of Fort Hunter—Liggett proper. The file is written one
`
`21
`
`28
`
`28
`
`

`

`TABLE 3.1 DTED VEGETATION CODES
`
`Description
`
`Less than one meter
`
`One to four meters
`
`Four to eight meters
`
`Eight to twelve meters
`
`Unused
`
`Twelve to twenty meters
`
`Greater than twenty meters
`No data available
`
`square kilometer at a time, beginning with the lower left one kilometer grid square
`
`(41,60), proceeding up the column to the upper left grid square (41,94), then
`
`doing the next column from bottom to top (42,60 to 42,94) and so on; the upper
`
`right one kilometer grid square (76,94) is the last one written. Within each one
`
`kilometer grid square, the individual data points are written in the same pattern,
`
`beginning with the lower left, doing each column from bottom to top, and doing
`
`the columns from left to right. This file layout is summarized in Figure 3.2. The
`
`position in the file of the elevation for a point expressed in five digit local UTM X
`
`and Y coordinates is found as shown in Equation 3.1.
`
`position = 35 * (integer(X/1000) — 41) + (z'nteger(Y/1000) — '59)
`
`(3.1)
`
`D. LOCATION
`
`The complete DTED file occupies 16,128,000 bytes of storage. Due to a local
`
`shortage of available disk space, this file must permanently reside on the UNIX
`
`VAX 11/785 system rather than on the IRIS system. The FOG-M simulator
`
`22
`
`29
`
`29
`
`

`

`23erug.1F
`
`tu0yaLel.1FDETD
`
`23
`
`30
`
`30
`
`

`

`presently operates on a ten kilometer square extract
`
`from this database. A
`
`program on the VAX called make—database—e aIIOWS interactive specification
`
`of the area and resolution desired. and produces an extract. This extract is sent
`
`over the Ethernet to the IRIS to serve as the input for a FOG-M run. However, if
`
`the data is sent directly, it is received with each pair of bytes swapped, so another
`
`program, swapdma, is run on the VAX before transmittal. This program swaps
`
`the low- and high-order bytes of each integer so that
`
`the swapping during
`
`transmission is cancelled.
`
`24
`
`31
`
`31
`
`

`

`IV. TWO-DIMENSIONAL TERRAIN MAP PORTRAYAL
`
`The two-dimensional representation of the terrain was begun as the first
`
`graphics portion of the system, in order to gain familiarity with the IRIS graphics
`
`workstation and the Defense Mapping Agency (DMA) digital terrain elevation
`
`data (DTED). Contour maps are the traditional approach to two-dimensional
`
`terrain portrayal, and thus were the basis for the two-dimensional images of the
`
`terrain generated here (Figure 4.1]. Although these two-dimensional images are
`
`not true contour maps, they are still referred to as such in this study because of
`
`their close relation and common origin. The algorithms for determining and
`
`drawing the forty foot contour lines found on a normal contour map seemed non-
`
`trivial, so a simpler alternative was chosen. Each elevation datum is represented
`
`by a
`
`tile, with the implicit X and Z (easting and northing,
`
`respectively)
`
`coordinates of the elevation datum being the center of the tile.
`
`A. COLORS
`
`The color of a tile is determined by its vegetation code, and its intensity (or
`
`shading) by its elevation. The intent was to use green for tiles with vegetation
`
`and brown for tiles without vegetation. However, the DTED vegetation codes
`
`lump together both “no vegetation” and “vegetation less than one mete