Line-of-Sight Attributes for a Generalized Application Program ...

JDMS, Vol. 1, Issue 1, April 2004 Page 43–57© 2004 The Society for Modeling and Simulation International

Line-of-Sight Attributes for a Generalized Application Program InterfaceMichael D. Proctor, Ph.D.University of Central FloridaOrlando, [email protected]

William J. Gerber, Ph.D.WJGerberConsultingOrlando, [email protected]

This research opens up for consideration the topic of a generalized simulation Applications Programming Interface. Discussion evolves around representation of one phenomenon essential to such an Interface, which is the widely used Line-of-Sight methodology. The research describes an initial set of line of sight (LOS) attributes necessary for a generalized Applications Programming Interface. Determination of LOS is necessary for entity-based simulation of Army land operations. Attributes necessary for the determination of LOS are identified along with alternative implementation techniques. Capabilities and limitations of the alternative techniques and algorithms are described.

Keywords: Line of sight, applications programing interface, algorithms, military operations

1. Overview and Purpose

A generalized Application Programming Interface (API) for simulation may overcome many inherent disadvantages of the current build-to-system-requirements paradigm by empowering simulation application programmers with the capability to rapidly compose a tailored simulation through ready access and understanding of validated fundamental algorithms [1]. A generalized simulation API should not be confused with existing APIs provided for operating environments like Microsoft Internet Server, DOS Protected Mode Interface, or other combinations of hardware and software environments. A given API provides “a set of routines, protocols, and tools for building software applications,” based on a given hardware and software environment [2]. Traditional operating system API tasks may include distribution of workload across a central processor and graphical processor, multiple processors, etc. In this paper, we are proposing a generalized API that, instead of focusing on optimization of programs based on a machine specific hardware and software combination, addresses representational challenges commonly faced

by simulation application programmers manipulating a synthetic environment. There are at least three representation-synthetic environment combination challenges created by the current build-to-system-requirements paradigm. One challenge is the proliferation of incompatible representation-synthetic environment combinations. Currently, each simulation development represents a non-selectable instantiation of specific supporting algorithms given a specific synthetic environment description that addresses operational requirements by a particular application proponent. As a consequence, each simulation development has its own simulation API. This stovepipe approach to simulation application development may have many local advantages but comes with major costs from a macro perspective, given the numerous separate yet overlapping simulation development efforts currently underway across the Department of Defense. When considered in the aggregate from a macro perspective, duplicative costs found in the conceptualization, design, coding, testing, verification, validation, operations, and support phases of the life cycle of each application drive up overall cost. Another challenge is the inflexibility of many representation-synthetic environment combinations to accommodate change and to be reused. Currently,

Volume 1, Number 1 44 JDMS

Proctor and Gerber

new operational system requirements often result in extensive and expensive modification of past simulation development efforts in order for them to accommodate changing requirements. Tight and expedite linkage of operational system requirements to simulation development, perhaps due to local program funding or time constraints, often results in simulation implementations that are narrowly and inflexibly developed to meet initial operational system requirements. These same cost- and time-effective, but narrow and inflexible, instantiations may in the long term create not only isolated and stand-alone solutions but also may limit their future reuse potential as well as drive up the long-term cost of revision. Another challenge is the risk of survival of developed representation-synthetic environment combinations. Currently, simulation development exclusively based on funding and justification of an operational system development is a lengthy and expensive process, often requiring years of development, verification, and validation in parallel with the operational system. Dependent ties between simulation developments and operational systems put the simulation development at risk to the uncertainties of funding and needs-assessment of the operational system. Cancellation of the related operational system may result in loss of the related simulation development effort. In summary, the current build-to-system- requirements paradigm has resulted in proliferation of incompatible representation-synthetic environment combinations that each require use of a customized simulation API in order to generate needed applications. A generalized simulation API addresses all three of these concerns. First, a generalized API, by its very nature supports multiple simulation development efforts across the DoD, thus reaping the benefits of both scale and scope. Further robust algorithms and/or amalgamations of multiple techniques in a common package would address diversity of requirements while simplifying and standardizing application development, enabling algorithm reuse, and reducing verification, validation, and support cost. Finally, a generalized API would enable operational system developers to access pass investments and protect those investments from the irregularities of operational system funding by distributing risk across numerous operational systems. Directing more of one’s efforts at developing a comprehensive set of algorithms that address fundamental phenomena is necessary to a generalized

API. Understanding of both phenomena and algorithms is essential to determining the feasibility of such a generalized approach. Determination of line of sight (LOS) is one such fundamental phenomenon. LOS is necessary to all simulations of Army land operations if those simulations represent, as individual computer-generated agents, discrete individuals and vehicles with sensor systems operating within a representation of the natural environment. In such simulations, a given LOS algorithm returns to a computer-generated agent a value. That value represents the physical visibility of a target (e.g., a person or vehicle) to the agent’s sensor (e.g., human eye, aided or unaided, or an electromagnetic device) based on both the sensor’s location and the target’s location. For the purposes of exploring the concept of a generalized simulation API, this research considers LOS algorithms abstractly as well as within the context of numerous implementations. This research may also be used as a reference for the simulation community that provides insight into the capabilities and limitations of various LOS algorithms for land-based military operations.

2. Background and Definitions

LOS is part of the larger topic commonly referred to as Target Acquisition and Recognition. As such, LOS supports rather than addresses the totality of the Target Acquisition and Recognition topic. Target Acquisition and Recognition also includes but is not limited to additional phenomena such as search patterns of individual sensing agents, discerning targets through atmospheric effects, or discriminating friend from foe. Even without the other Target Acquisition and Recognition complexities, LOS is not a trivial process. Complexity arises in developing and implementing algorithms that are valid and appropriate computer models of the infinite depth that exists in the natural environment. Additionally, the LOS algorithm can be used for creating a two-dimensional visual depiction for a simulation user of what areas may be seen from a given point. LOS algorithm variations range from a simple, single ray measured from point to point considering only terrain obstructions with a true or false return value [3], to complex, multiple ray implementations considering intervening physical obstructions in addition to the terrain, such as vehicles, buildings, or trees having various opacities, and three-dimensional,

Volume 1, Number 1 JDMS 45

Line-of-Sight Attributes for a Generalized Application Program Interface

spatially oriented entities of interest with a return value indicating what fraction of the entity of interest is potentially visible depending on the nature of the sensor [4,5,6]. Synthetic representation of entities of interest, referred herein as targets, also impacts on determination of LOS. Target representation varies from a simple one-dimensional (1D) object having height but no width, to a complex three-dimensional (3D) object represented as a two-dimensional (2D) silhouette with an apparent width and height as seen from the sensor. The 1D representation is useful for quick calculations of blockage by terrain, but provides a very simplistic representation. The 3D complex object target, represented in 2D, provides for a more detailed assessment of the portion of the target that is blocked by multiple objects. However, 3D representation requires much more computation and, hence, takes longer to perform. A complex target also may be represented as a projection on a 2D raster, oriented perpendicularly to the LOS so that blockages of specific portions of the target can be represented more easily. Individual raster bits that correspond to portions of the target that are blocked are set to indicate the blockage. The raster then serves as a memory of what portion is cumulatively blocked as each potential blockage is considered in turn [4,5,6]. The Underlying Time Advance Architecture of the simulation is also a consideration, particularly in terms of computation demand. For entity-based simulations considered in this research, time advance is typically by a fixed time step. Operation of the simulations and, hence algorithms, can proceed in real-time (generally at a 15 or 30 Hz rate), at faster than real-time, or at a rate of as fast as possible [4,5,6].

2.1 Terrain Database Types

Since terrain obstruction is shared by all of the LOS algorithms, a description of the terrain database is appropriate. Prevalent terrain surface representations can be described as being of one of three types: A“grid” network—a regularly spaced grid of locations, at each of which an elevation value is defined; a “Triangulated Irregular Network” or “TIN,”—an irregularly spaced set of locations defining the three vertices of each of the adjacent triangular polygons with an elevation value defined for each of the three two-dimensional (x, y) vertex points; or a combination of both. Grid or TIN terrain representations may be composed of

two-dimensional polygons, but may alternatively be composed of multi-dimensional objects like voxels. We concentrate our discussion on the consequences of the surface aspects of the representation. For a grid network, the spacing of the grid in the x (east) and y (north) directions determines the horizontal resolution of the database, e.g., 1.0, 10.0, or 125.0 meters. For both grid and TIN databases, the minimum step sizes for the elevation data in the z (up) direction is the elevation resolution, e.g., 0.1, 1.0 or 10.0 meters. Each of the locations at which an elevation value is defined is called an “elevation post,” or simply a “post.” Higher database resolutions provide greater fidelity of representing LOS across the terrain skin, but increase the computational load in rough proportion to the increased resolution. Studies using a grid representation have found an 87% increase in computation time for a doubling of resolution. Determination of the level of fidelity necessary for a particular application will vary with the needs of the application. Besides additional references discussed below, numerous other discussions of terrain fidelity needs exist [7,8,9]. It is beyond the scope of this research to discuss the numerous fidelity-application pairings, but rather the intent of this research is discussion of a generic simulation API with the ability to support the range of fidelities. The compact terrain database (CTDB) military terrain standard will be described here for terminology reference. In the CTDB, a “patch” is the smallest terrain size for which a complete description is stored as a self-contained unit. It is usually a 500-meter by 500-meter section of the terrain database. The CTDB can use a combination of grid and TIN patches or either exclusively. Most older CTDB databases are grid. Representations of micro-terrain, which are finer resolution descriptions on the terrain surface, are usually depicted in the TIN format as features that overlay the grid database. However, some newer databases are completely represented as TIN data. Another military terrain database standard is the Model Reference Terrain Database (MRTDB). The MRTDB uses only patches that are grid. [4,5,6].

2.2 Grid Network

A patch is a grid that typically has four posts per side, but often has one to five posts per side. For a grid portion of the CTDB, a patch would typically contain 16 elevation posts in a four-by-four grid of regularly spaced posts at 125-meter intervals (See Figure 1).


Proctor and Gerber

Each of its posts is located in the northwest corner of its defined grid square and uses diagonals running from NW to SE (typically) or SW to NE, to create two triangular surface polygons. The top row of posts within the patch would be along the northern border of the patch and the leftmost column of posts would be along the western border of the patch. The posts defining the elevations on the southern and eastern borders of the patch are stored in the adjacent patches on those sides. For grid terrain, data about the features (buildings, roads, trees, micro-terrain, etc.) are stored as a “feature list” by the patch [5,6].

2.3 Triangulated Irregular Network

For a TIN portion of the CTDB, up to 25 triangular polygons may be defined within the patch with posts describing the vertices of each triangle such that the polygons completely cover the surface of the patch. Each post has an elevation associated with it. No information on the features are stored with the posts or

polygons. For TIN terrain, data about the features are stored for each patch as “terrain elements”[5,6].

2.4 Combined Grid and TIN

Within some databases, both grid and TIN formats may coexist. The TIN format may be necessary for some portions of the database where depicting details of terrain with high fluctuations in elevation may require a finer resolution than is necessary for the remaining terrain.

3. LOS Terrain Blockage Algorithms

An LOS algorithm determines whether the terrain at any point blocks any of the one or more rays that are projected from the sensor to the target. LOS blockage is determined by stepping through various locations along the three-dimensional ray between the sensor and the target and by comparing the elevation of the ray with the terrain elevation at those locations. If the terrain is higher than the ray at any location, that ray is considered blocked and no more steps along the ray are taken. Alternatively, slopes from the sensor to the terrain at evaluated points can be compared with the slope from the sensor to the target to determine blockage. Differences between simulation algorithms for terrain obstruction arise based both on how the elevations at points not coincident with elevation posts are determined and on how the location points to be evaluated are determined [10].

Posts in each gridded patch are labeled from west to east in each row starting at the southernmost row and then proceeding northward sequentially by each row in turn.

The post spacing shown here is 125-meter resolution.

Figure 1. Grid network patch [6]

Figure 2. Triangular irregular network patch [6]



3.1 Terrain Elevation Determination at a Point

“Interpolation” and “nearest post” are the two generic methods for determining elevations at locations that are not coincident with an elevation post, the usual case.

3.1.1 Interpolation

For interpolation, a two-post interpolation is used if the location is on a line between two adjacent posts in grid terrain or on a line between two locations defining the edge of a triangular polygon on TIN terrain. A four-post interpolation is used in grid terrain when the surface is not depicted by triangular polygons and the location lies in the grid square between four elevation posts. Figure 3 shows an example of how to perform a four-post interpolation. In the case of a triangular polygon, representation of the surface, whether the posts are grid or TIN, the elevation of a location is determined by the surface elevation of the enclosing triangular polygon at the x, y coordinate location (Figure 4).

3.1.2 Nearest Post

For nearest-post elevation determinations, the elevation is assumed to be identical to the elevation of the nearest post. The surface representation for nearest-

post method can be thought of as level squares with sides the same size as the horizontal resolution, with each square centered on the enclosed elevation post, and with each square’s elevation value the same as that of the enclosed elevation post (Figure 5).

3.2 Determination of Blockage along an LOS

3.2.1 Ray Reduction Using Interpolation

Not all points along a line of sight are considered in an LOS determination. The reason for this is that to check all definable points would be computationally impracticable. Secondly, from a terrain elevation perspective, not all points are of interest since a few points can represent most points along a line of sight. A number of techniques are available to reduce the actual line-of-sight ray to a ray represented by a smaller set of points. Figure 6 illustrates some of the differing approaches. In the left-most example (OTB), each 2D intersection of the line from the sensor to the target with the 2D projection of the edges of the triangles traversed by that line are evaluated. For the purpose of LOS blockage determination, the elevation of the edges effectively represents all the points in the entire triangle or grid and thus reduces the points that are required to make up the ray. In the DYNTACS algorithm, originated in the 1970s and still available through the Combined Arms and Support Task Evaluation Model

Figure 3. Four-post interpolation within a grid square

Two two-post interpolations between paired posts on opposite sides of grid square:

Zia = Zaa + (Zba–Zaa)*(Xi–Xa)/(Xb–Xa)Zib = Zab + (Zbb–Zab)*(Xi–Xa)/(Xb–Xa)

Single two-post interpolation between the two previously interpolated points:

Zii = Zia + (Zib–Zia)*(Yi–Ya)/(Yb–Ya)

Four-Post Interpolation Procedure


Proctor and Gerber

(CASTFOREM) simulation, each 2D intersection of the line from the sensor to the target and the lines between adjacent elevation posts (both North-South and East-West) are evaluated. In Janus 4.0+, the line between the sensor and the target is divided into step sizes and evaluated at each step along the line. The Janus 4.0+ approach does not guarantee that all possible elevation obstructions along the LOS are accounted for, but it does provide fewer points for evaluation and therefore a faster calculation, which frees up processor cycles for other activities. For the Janus 4.0+ approach the step size is determined as follows:

• First, calculate the x and y differences from the sensor to the target. • Second, select the largest distance. • Third, divide that distance by the elevation post spacing. • Fourth, round to the nearest integer. • Finally, divide the sensor to target line into that many parts for the step size.

3.2.2 Ray Reduction Using Nearest Post

For elevations determined using a nearest-post algorithm, techniques for point selection during LOS ray reduction also vary. The Bresenham LOS algorithm, used in Janus 3.x simulations, is a modification of a fast, efficient algorithm used to determine which pixels light up on a computer screen to depict a straight line. This algorithm uses integer arithmetic for reducing the time for computation. Figure 7 shows an example of selected posts using the Bresenham algorithm. The Army Airland Battle Environment (ALBE) algorithm, used in the CASTFOREM simulation, steps along the LOS in equal step sizes using a step size based on the azimuth from the sensor to the target. The step size ensures that no post is examined twice and that no squares between the sensor and the target are skipped. Although the ALBE LOS algorithm is fast, it is not necessarily reciprocal when calculated from each end (i.e., the posts selected could be different if

Figure 4. Elevation by interpolation for triangular polygons

Figure 5. Elevation by nearest point



Figure 6. Examples of LOS evaluation points for selected algorithms

Figure 7. Example of LOS evaluation points for the Bresenham algorithm

calculated from the target end than from the sensor end). The ALBE algorithm solves that problem by forcing the target and sensor to stay on elevation posts and only calculating from the sensor end.

3.2.3 Comparison of Algorithms

The more evaluation points selected, the more accurate the LOS calculation, but the greater the amount of computation required. Additionally, interpolation, while continuous, takes more computation than nearest-post methods because it uses floating point arithmetic versus the ability to use integer arithmetic with nearest-post methods. Studies of relative computation times conducted with the following five LOS algorithms [11], arranged from fewest to most evaluation points, showed:

Algorithm Name Post Method Relative Computation Time Evaluation Points Bresenham Nearest Post 1.00 Fewest ALBE Nearest Post 1.33 Very few Janus Interpolation 3.09 More DYNTACS Interpolation 4.80 Much more ModSAF Interpolation 5.02 Most


Proctor and Gerber

OTB, DISAF, and CCTT all use interpolation and the same method as ModSAF for determining evaluation points.

4. LOS Feature Blockage Determination

Features that could affect LOS include, for example, buildings, above-ground pipelines, non-penetrable structures, individual trees, bushes, tree lines, tree canopies, micro-terrain, and cut and fill. The level of detail that is considered for each feature can also vary between simulations. Features are typically processed after the basic terrain at the end of each patch is traversed by the LOS ray [4,5,6].

4.1 Buildings/Structures

A building or structure for obstructing LOS could be represented as a center point with a radius to define a bounding volume or as a rectangular solid with length, width, height, orientation, and center point. In more detailed simulations, the building might be represented by sequential locations at each of the corners of the building with an associated elevation for the roofline at each location. Buildings and structures are generally considered as opaque, completely blocking LOS for optical sensors as well as thermal sensors. Some exceptions to this rule exist, especially where building representations have windows and doors that are transparent.

4.2 Trees/Vegetation

Traditionally trees and vegetation are represented in at least three different manners: as individual trees, tree lines, and tree canopies. There are also some newer techniques for trees and vegetation being developed to support simulation of dismounted infantry.

4.2.1 Individual Trees

Some simulations consider individual trees. Individual trees may be represented by opaque cylinders in the simple case, or by more detailed descriptions including a trunk thickness, height of the lower branches (unobstructed below them), height of the tree, width of the foliage, and an opacity factor for visibility through the leaves above the lower branches. In each of these

cases, a center point would be defined for each tree. For cumulative LOS visibility along a ray through multiple trees, the opacity factor for each tree is multiplied by the proportion of visibility along the LOS up to that tree. A lower threshold is sometimes used such that the visibility is considered blocked when it becomes less than the threshold value.

4.2.2 Tree Lines

Tree lines are used in some simulations to reduce the data storage requirements for trees as well as to replicate existing features, such as tree lines along roads or canals. They can be represented in various ways, including being anchored by an individual tree representation at one or both ends of the tree line. The tree line can be represented as a sequence of locations with a height above ground for the tops and an opacity factor that could range all the way to complete blockage. Some tree lines may also represent tree trunks at intervals and a lower level for the leaves and branches, allowing unobstructed visibility below the tree tops (except for the trunks). Others may treat the tree line as if it were a drape from the tree line tops all the way to the ground. The cumulative visibility through multiple tree lines considers the multiplicative visibility decrease through each successive tree line along the LOS ray.

4.2.3 Tree Canopies

Tree canopies are used to represent a large grouping of trees or a forest. The boundary of a tree canopy is defined by a sequence of locations that form a complete, closed polygon in two dimensions horizontally. How the visibility through the canopy is computed depends on the simulation. The edges of the canopy may be treated as an implied tree line with an opacity factor. Because of variations in viewpoints, terrain surface, and target locations, a ray might penetrate one side of a canopy, two sides of a canopy, or even one side and the top of a canopy. How those cases are handled may vary from one simulation to another. Some may consider complete LOS obstruction at the canopy edge while others may permit complete visibility into the edge of the canopy for a short, fixed distance with an exponential decrease of visibility based on range into the tree canopy.



4.2.4 Recent Techniques

Some recent studies by TRAC-WSMR [10,12] concerning visibility through vegetation for dismounted infantry have developed empirical equations for LOS reduction based on range through vegetation. The equation is of the form:

f = e-R/b,

where f is the visible fraction of the target, R is the range through the vegetation, and b is the slope of the decay. The slope of visibility decay, b, is a constant dependant on the particular vegetative sub-biome (combination of climate and vegetation) and the stance of the sensing infantryman and target infantryman, which is in a defensive posture or in an offensive posture. The stances considered were prone or crouching for the observer and prone or kneeling for the target. To apply this algorithm to vegetative areas, including tree canopies, the visibility decay constant, b, would have to be stored in a lookup table with entries for each set of offense/defense postures and observer/target stances. To date, the values have been developed only for infantry in the stances described. Of note, one simulation uses an aggregated tree object that allows representation of multiple trees relative to each other and then replication of that object multiple times without having to duplicate the storage space for the trees in the replicated patch [4]. Use of aggregated tree objects to represent the equivalent of a tree canopy could possibly result in visibility outcomes similar to that using the empirical formula above, but with much more computation.

4.3 Micro-terrain and Cut and Fill

Micro-terrain includes such items as earthen berms, mounds, or small hills, while cut and fill includes such items as ditches, man-made cuts through terrain for roads, and the fill below elevated roadways that may traverse a cut location. Micro-terrain and cut and fill features are represented synthetically as TIN portions of the database that are handled as features that overlay the basic terrain and provide a more detailed description of the terrain. While micro-terrain features can be processed after the terrain skin in a patch is processed, since it is entirely above the basic terrain database, cut and fill features must be considered before the basic terrain is used in LOS calculations, as potential blockages in the basic terrain skin may be removed by the cut and fill features. Both micro-terrain and cut and fill features allow for blockages at a finer detail level than is enabled in the regular portion of the terrain skin database.

5. Curved Earth Correction (Sagitta)

For the observer to target ranges that are short (up to about 2 to 3 kilometers), the earth’s curvature is not a factor that needs to be considered. However, for longer ranges, the fact that the LOS occurs on an irregular surface linked to an oblate spheroid must be taken into account. The early Romans knew the need for this correction. It was referred to as sagitta or arrow. Figure 8 illustrates why the correction is needed. The height change (∆H) at a range (R) from the observer is the correction that needs to be made. At the target,

Figure 8. Earth curvature corrections [3]

Δ

Δ Δ


Proctor and Gerber

and at each point along the LOS ray, the height of the target, and of each terrain point considered respectively, is reduced by the locally computed value of ∆H. The value of theta (θ) is the angular distance across the earth’s surface from the sensor to the point under consideration while R

e is the radius of the earth,

approximately 6,356,766 meters. The correction for visual LOS is given by the equation:

∆H = R * cscθ– Re ≈ R2 / (2 * R

e).

This approximation is good to 1 part in 10,000 out to 40 kilometers. Atmospheric anomalies might require an additional correction. For the apparent earth curvature for the Radar LOS, the value for R

e is replaced by

(4/3)* Re. Some simulations correct for earth curvature

while others assume a “flat earth” terrain for simplicity of calculations [3].

6. LOS Blockage Determination Due to Vehicles on the Terrain

As with some features, not all simulations consider obstruction of LOS to a target by other entities, such as friendly vehicles or humans. For those that do, representations vary for the fidelity of vehicles or humans. In the case of vehicles, some use a simple rectangle with fixed width and height for each type of vehicle. For vehicles with turrets, the turret may be represented separately as a second rectangle. The rectangle is also assumed to be oriented so that it is facing the observer regardless of the vehicle’s actual orientation. The height may be used directly, which assumes that the blocking vehicle is being looked at as if it were at the same level as the observer. The orientation may be used to calculate the aspect angle between the forward direction of the vehicle and the

Figure 9. Some approaches to the representation of vehicles for LOS blockage



direction to the observer. Others go into more detail with consideration of the vehicle orientation to develop a silhouette for the vehicle as seen from the observer’s location. That silhouette can be represented by one or more rectangles, each with an associated height and width, or even by a raster of an array of points to represent the area blocked by the vehicle in greater detail (Figure 9) [4,5,6].

7. Visibility of Targets

Targets, such as vehicles, are typically represented in the same way other vehicles may be used to determine blockage. Targets are typically rectangular solids (e.g., ground vehicles), ellipsoidal solids (e.g., air vehicles), or for those vehicles with turrets, a rectangular solid for the hull and a rectangular solid for the turret. The height and width of the target vehicle is proportionately reduced to reflect its apparent size at the distance along the LOS. The apparent visibility is summed across the target until a minimum visibility threshold is reached, at which time the target is considered obscured. An example of the computing of the visible area for an aircraft target is shown in Figure 10 [13].

8. Visibility Reduction Due to Atmospheric and Lighting Conditions and Airborne Particles

Initial target visibility calculations typically do not take into account rain, fog, haze, tactical smoke, or time of day. Representation of lighting and

atmospheric phenomenology is beyond the scope of this article though some brief remarks are provided here. Accounting for atmospheric obscurants that are in the LOS path is often used to flag individual sensor models after the visibility calculation. Approaches to representing these phenomenology range from degradation formulas to lookup tables to separate servers with more fundamental algorithms. Lookup tables, contrast levels, or simple degradation formulas are often included in simulation code to determine the level of detection of a target’s radiant energy. For example, when determining the target detection level in one simulation, smoke types that lie within an LOS ray are considered based on the combination of sensor type and smoke type after the visibility calculation.

9. Summary

Attributes can be used to discriminate between the algorithms, reveal common traits, or identify capabilities or limitations of algorithms. Each summary table below identifies aspects and algorithms pertinent to LOS, as well as detailed descriptions for three popular simulation instantiations (parts of other simulations were identified in the text above but not in the tables below). As each simulation has its own instantiations for each feature, this structure is modular in that it allows adding columns for other simulations and extra rows for additional attributes, all without needing to change the previous work completed on the matrix. As an example, atmospheric representations may be added as rows to Table 1 (see following page).

Figure 10. Visible area for an aircraft target [13]

θ

θ

θ

θ

½

½

½

½


Proctor and Gerber

Attribute OTBv1.0/DISAFv9.4 CCTTv8.4

Time Advance (Continuous with fixed time steps or event-based)

Fixed Time Step:- Real-Time (15, 30 Hz)- Faster than Real-Time-As Fast As Possible

Fixed Time Step:- Real-Time- Faster than Real-Time

Terrain Database Compact Terrain Database (CTDB) Model Reference Terrain Database (MRTDB)

Terrain Skin Resoultion DTED 1-5 (100, 30, 10, 5, 1 M) Down to 1 M

Terrain Skin Representation

Continuous surface- Grid: Resolution spaced grid squares with diagonal facet between 2 posts (usually NW-SE or sometimes SW-NE) and with post in NW corner- TIN: irregular, triangular polygons- Combined: Grid and TIN

Continuous surface- Grid: Resoultion spaced grid squares with diagonal facet between 2 posts (usually SW-NE or sometimes NW-SE) and with post in SW corner

Posts per Patch Grid: 1, 4, 9, 16, 25 (usually 16)TIN: 1-25

Grid: 16

Patches per Page 64 16

Table 1. Underlying simulation and environmental architecture


Elevation Determination (Nearest Post/Interpolation)

Interpolation between posts (grid) of enclosing two sides and diagonal or between posts of enclosing triangular polygon’s surface (TIN)

Interpolation between posts (grid) of enclosing two sides and diagonal

Target Representation 2D projection of 3D rectangular solid along 3D LOS with size proportionally reduced at locations of each potential blockage. Projection based on one of three methods: (1) 2d rectangle, using target’s characteristic dimensions of width and height; (2) 2D rectangle found by rotating target in three dimensions and using the distance between the highest and lowest vertex as the apparent height, and the distance between the left- and right- most vertices as the apparent width; (3) a raster using the exact outline that would be seen as described in (2).

2D projection of 3D rectangular solid along 3D LOS with size proportionally reduced at locations of each potential blockage. Projection based on target’s characteristic dimensions of length, width, and height and aspect angle of target heading relative to LOS. Projected width is target length and width combined using aspect angle (i.e., as if target is viewed from same level). Target’s turret, if any, is considered separately.

LOS Ray(s) projection Two 3D LOS rays start from sensor 3D location. One extends to bottom center of the target and the other to the top center of the target. A raster of pixels may be used to store accumulated target blockages for the equivalent of a number of LOS rays equal to the number of pixels.

Two 3D LOS rays start from sensor 3D location. One extends to bottom center of the target and the other to the top center of the target. A raster of 32x32 pixels is used to store accumulated target blockages for the equivalent of 1,024 LOS rays.

LOS Ray Reduction 2D locations selected are each intersection of 2D LOS ray, from its start to end, with a grid square diagonal, with one of the two facets next to the grid square’s post, or with the edge of a triangular irregular polygon.

2D locations selected are each intersection of 2D LOS ray, from its start to end, with a grid square diagonal or with one of the two facets next to the grid square’s post.

LOS Blockage Determination

Each blockage (vehicle, terrain skin, or feature) is handled separately and cumulatively. Target is considered completely blocked when visibility decreases below a minimum visibility value. Processing stops when target is completely blocked or no potential blockage remans.

Each blockage (vehicle, terrain skin, or feature) is handled separately and cumulatively. Target is considered completely blocked when visibility decreases below a minimum visibility value. Processing stops when target is completely blocked or no potential blockage remains.

Table 2. Fidelity of the LOS process



Attribute OTBv1.0/ DISAFv9.4 OTBv1.0/ DISAFv9.4

Micro-terrain

Represented as quadrilateral and triangular polygon surfaces.

Represented by an anchor point, a central vertex with height, and a variable number of vertices with height, each connected to the central vertex. The surface is represented as a series of triangular polygons formed by the central vertex and each pair of sequential vertices, the last one wrapping to the first.

Cut and fill This is represented by micro-terrain. Represented by an even number of sequential vertices with the first and last forming one end of the cut and the middle two forming the other end. The surface is represented by triangular polygons formed by connecting vertices across from each other and by one diagonal starting from each vertex on the first side prior to the other end.

Vehicle Apparent shape, as seen perpendicular to the LOS, may be represented in one of three ways. The simplest is as a rectangle with the vehicle’s width and height. The second is by projecting the eight vertices of the vehicle, represented as a rectangular solid with length, width, and height and oriented in three dimensions, onto a plane perpendicular to the LOS and using the distance between the highest and lowest vertex as the apparent height and the distance between the left- and right-most vertices as the apparent width. The third is by creating a raster reflecting the exact outline that would be seen as described above. Any of these three methods may be used on the target vehicle or the blocking vehicle.

Represented as 2D rectangle oriented perpendicularly to LOS with apparent width and height based on target’s characteristic dimensions of length, width, and height and aspect angle of heading relative to LOS. Apparent height is vehicle height and apparent width is vehicle length and width combined using aspect angle (i.e., as if vehicle is viewed from same level). Vehicle’s turret, if any, is considered separately.

Building or structure

Includes buildings, rock drops, and multi-elevation structures (MES). MES has categories of building, cave, tunnel, bridge, other, and unknown. Simple buildings are represented by a model with roofline vertices (generally four, as offsets from an anchor point) and a pointer to the next model for a more damaged state. Each MES structure has a rotation matrix from the anchor point with both roof line and floor line vertices and a pointer to a list of templates for the enclosures and apertures. The first enclosure contains all the other enclosures and each has a list of its own apertures. Apertures can be open and transparent, or closed and opaque, as well as be doors or windows, indicated by bottom at floor line or not. They connect between two enclosures. LOS can occur through open and transparent apertures only.

Represented by an anchor point, building model with orientation, and series of wall vertices with roofline heights. Each wall is checked sequentially for blockage and blockage is rasterized if partially blocked.

Bridge span Represented as a structure (See Building or structure above.)

Represented as a horizontal polygon and handled as if blocking the target from above (i.e., raster width is target width and raster height is target length). Blockage is complete if three or four corners are obscured, rasterized if one or two.

Relocatableobject

Dragon’s teeth, represented as a linear series of 3D vertices with width, and include steel hedgehog, steel tetrahedron, concrete block, and concrete tetrahedron.

Includes log cribs, dragon’s teeth, abatis, rock drops (covered and uncovered), building rubble, infantry fighting positions, covered machine gun bunkers, machine gun prepared positions, overhead covered infantry positions, and turret and hull defilades for armored vehicles, fighting vehicles, mortar carriers, and tanks. Represented as a series of vertices with heights and handled as walls.

Water surface

Represented as a water polygon, it allows clear intervisibility both above and below water surface but completely blocks LOS through the surface.

Represented as a water polygon, it allows clear intervisibility both above or below water surface but completely blocks LOS through the surface.

Table 3. Additional blockage types and opacity representation


Proctor and Gerber

10. Considerations from the Perspective of a Generic Simulation API

Our research supports the concept of a generic simulation API. The key advantage of the grouping above is that it relates similar attributes with corresponding algorithm choices so that they may be selected as appropriate to the application. Some of the existing code implementing LOS algorithms is terrain database specific. This includes both the terrain skin and features. Therefore, the terrain database may limit selection and use of algorithms. For illustration purposes only, in a Windows-like motif implementation of a generic API, inappropriate algorithms due to database limitations may be presented as gray to the user, indicating the non-availability of the technique for the particular database. On the other hand, a more open strategy could be employed with resolution levels. As an example, in the tables above, both the CTDB and the MRTDB databases allow for and adjust to the selection of various terrain skin resolutions. Given a high-resolution database, one may not wish to

use a low-resolution ray reduction technique, yet that algorithm would still be available to the application programmer as situations might arise that justify the approach. Selection of algorithms also may be based on implementation concerns. As an example, rasters provide the most detailed representation of overlapping blockages, but of course require the most computational resources. Other algorithms may be more appropriate for a particular implementation as they can provide faster, more simple calculations using only a single LOS ray. A comprehensive set of LOS algorithms is fundamental to such an API and is therefore an appropriate topic to begin a dialogue on the feasibility of a generalized API. Identification of a generalized API requires an understanding of LOS methodologies and the necessary and sufficient conditions to support their successful implementation. Though a generic API does not currently exist to implement the range of options presented in this research, theoretically, numerous approaches to LOS calculation exist, offering a wide choice of algorithms to the application programmer attempting to compose


Individual Tree Represented by a 3D location for the top of the tree and a tree model. The tree model includes a height (foliage height from top of tree to lowest branches), trunk radius, foliage radius, and opacity of the foliage.

Represented by a 3D location for the top of the tree and a tree model. The tree model includes a height (foliage height from top of tree to lowest branches), trunk radius, foliage radius, and opacity of the foliage.

Aggregated Trees Provides a grouping of trees that can be referenced without having to store the data again for each tree each time it is used in an aggregate. Each tree of the aggregate is used individually when calculating LOS.

Provides a grouping of trees that can be referenced without having to store the data again for each tree each time it is used in an aggregate. Each tree of the aggregate is used individually when calculating LOS.

Tree Line Represented by a series of 2D vertices with elevation of the treetop at each vertex; two flags indicating whether a tree is at one, both, or neither end; trunk radius, foliage width, foliage height (from top to lowest branches), and fullness (opacity).

None

Tree Canopy Represented by an aggregate polygon with edges defined by 3D vertices and flag indicating if edge is edge of canopy polygon. A tree line is assumed below the canopy edges. A target completely behind both assumed treeline and canopy top is completely obscured.

None

Concertina wire, wire road block, fence, minefield fence

Represented as a linear series of 3D vertices with fullness (opacity).

None

Obscurants (may be limited to another table)

Smoke, fog, and rain are considered for detection level of the target, but only after the LOS visibility has been calculated.

Rain, fog, haze, tactical smoke, and time of day are considered for detection level of the target, but only after the LOS visibility has been calculated.

Table 4. Features with transparency



a simulation. Further, this research indicates that much of the phenomenology related to LOS is shared by existing simulation instantiations, which supports the notion that common algorithms can be shared across simulations, thereby reducing duplicative simulation development effort. With reuse in mind, clearly the challenge for LOS algorithmic development is the balance between it and evolving database fidelity requirements. More importantly and at a greater scale a generic API built on fundamental phenomenology and a wide range of algorithms could empower application programmers with the power to compose valid simulations rapidly. Inherent to this process would also be the reduction in current duplication of development efforts and an increase in the expectation for longer term reuse. A generic API also offers the hope of bridging the knowledge gap on the part of simulation builders on techniques used in other parts of the simulation community. With a better understanding of the underlying algorithms, differences in analysis results also may be more traceable and thereby better understood.

11. References

[1] Lunceford, D. 2002. Personal communication.[2] Webopedia. 2004. http://www.webopedia.com/TERMA/A/API.html.[3] Youngren, Mark A. (Ed.). 1994. Military Operations Research

Analyst’s Handbook, Volume I: Terrain, Unit Movement, and Environment. Military Operations Research Society (MORS).

[4] Close Combat Tactical Trainer (CCTT), Version 8.4. 2003. Source Code.

[5] Dismounted Infantry Semi-Automated Forces (DISAF), Version 9.4. 2002. Source Code.

[6] OneSAF Testbed Baseline (OTB), Version 1.0. 2001. Source Code.[7] Hoffman, Michael. 1976. Report on TETAM Intervisibility Data. In

AORS XV Proceedings, Vol. 2, TRADOC.[8] Lind, Judith H., Ronald A. Erickson. 1991. Planning for the

Acquisition of Land Targets NWC TM 7081. China Lake, CA: Naval Weapons Center.

[9] Proctor, M.D., G. Paulo. 1996. Modeling in Support of Operational Testing. In Mathematical and Computer Modelling, Vol. 23, Number ½, 9-14.

[10] Champion, D.C., L.A. Fatale, P.F. Krause. 1999. Effects of Vegetation on Line-of-Sight (LOS) for Dismounted Infantry Operations. White Sands Missle Range, NM: U.S. Army TRADOC Analysis Center, TRAC-WSMR-TR-99-001(R).

[11] Champion, D.C., K.G. Pankratz, L.A. Fatale. 1995. The Effects of Different Line-of-Sight Algorithms and Terrain Elevation Representations on Combat Simulations. White Sands Missile Range, NM: NMTRADOC Analysis Center, TRAC-WSMR-TR-95-032(R).

[12] Champion, D.C., L.A. Fatale, P.F. Krause, H.B. Puffenberger. 2002. The Prediction of Line-of-Sight (LOS) in Vegetation Using Remote Sources. White Sands Missile Range, NM: U.S. Army TRADOC Analysis Center, TRAC-WSMR-TR-02-001(R).

[13] Elliot-Bird, P., K. Steiner, J. Carlineo, B. Clay, J. Matthews, R. Norman, J. Thomas, P. Topper. 2000. The Compendium of Close Combat Tactical Trainer Algorithms, Data, Data Structures, and Generic System Mappings. Aberdeen Proving Grounds, MD:U.S. Army Materiel Systems Analysis Activity, AMSAA Close Combat Analysis Division Special Publication SP-97.

[14] Software Design Document (SDD) and Interface Design Document (IDD) for the Computer Generated Forces (CGF) Computer Software Configuration Item of the Close Combat Tactical Trainer (CCTT), LORAL/Army CCTT IDT, Revision C, 20 December 1999.

[15] Department of the Army Field Manual FM 3-0 (formerly FM 100-5), Operations, June 14, 2001.

[16] Richardson, R. 2003. Personal communication on the Joint Virtual Battlespace (JVB).

Line-of-Sight Attributes for a Generalized Application Program ...

Documents

Transcript of Line-of-Sight Attributes for a Generalized Application Program ...