Edited by Harry L. Reed, Jr.
Dedicated to the memory of James O'Bryon.
The vulnerability of a target to a given threat munition can be thought of as a synthesis of its vulnerabilities over the space of all given attack vectors and velocities. In order to extend the notion of vulnerability into the domain of survivability each individual vulnerability must be weighted by some measure of the probability that a munition will arrive on that attack vector, according to this formula:
V(target) = SIGMAi=1..n { V(pi) * w(pi) }
where
The task of evaluating the function V() can be broken into two parts. First, it is necessary to determine the geometry at the point where the threat munition impacts the target, and second, it is necessary to compute the response of the materials of both threat and target to their high-velocity collision. This chapter addresses only the geometric concerns; subsequent chapters will detail the modeling of the material response, and the process of synthesizing the individual shot results into an overall presentation that is meaningful to design engineers and program managers.
While it has long been understood that projectiles do not fly through the atmosphere in a straight line, their trajectories over short intervals (several meters or less) can be safely approximated by a straight line-segment. This approximation is particularly apt for tank ammunition, which is typically fired at low gun elevations and high velocities. Thus, the attack path pi can be safely described as a mathematical ray, or directed line, emmanating from a starting point P in three-space and proceeding along a given direction vector D. As long as the actual trajectory of the projectile and the matehmatical ray are coincident in the vicinity of the target, the approximation remains valid.
The ray may be expressed in parametric form, such that every point X on the ray has a one-to-one correspondence with some value of the scalar parameter t:
X = P + t * Dwhere X, P, and D are 3-tuples, and t is a scalar. t is thus a measure of the distance that the projectile has traveled along the ray.
Each component of the target, or region, may be considered to partition the shotline into intervals along the ray. The start of each interval occurs where the ray enters the component, and the interval ends where the ray exits the component. If two components adjoin one another, a second interval may immediately follow the first.
For each interval, at a minimum it is necessary to be able to provide the parametric distances corresponding to the entry and exit points, and the surface normal at both the entry and exit points. From those values it is possible to compute the line-of-sight thickness through the component, the 3-space coordinates of the entry and exit points, and the obliquity angle of the shot. These are essential inputs into the penetration equations.
When a penetrator passes through an armor plate, it's trajectory is usually deflected somewhat off it's initial course. For the most accurate results, it is necessary to generate a new shotline each time one layer of armor is perforated.
Traditional vulnerability analysis required the study of selected shotlines through a target using entirely manual methods. Most commonly, the analyst would work with full-size blueprints, drawing each shotline on the blueprints, passing in and out through the components of the entire target. Often a given shotline could pass through more than one page of blueprints, necessitating painstaking alignment of the blueprints.
After the shotline had been drawn, the list of components that the shotline encountered was recorded, including measurements of the line-of-sight thickness through each component, as well as the angle at which the shotline entered the component, This angle is expressed as two numbers, the rotation around the surface normal, and the fallback angle off the surface normal.
This process was actually much more difficult that it sounds because only rarely would a shotline of interest lie in one of the planes that the blueprints were drawn in. Even with three orthogonal views, the task of calculating the line-of-sight thicknesses and distances traveled involved a great deal of tedious trigonometry. Calculating the angles was even more tedious, as it was often difficult to estimate the surface normal at the point where the shotline intersected each component, simply by examining the drawings.
Frustrated by the difficulty of attempting to understand the inherrently three-dimensional nature of these shots, some analysts resorted to other techniques. To give but one example, in the early days of the then XM1 (now M1 Abrahms) tank, Gil Bowers turned to his woodshop and constructed a scale model of a portion of the XM1 turret so that he would have a three-dimensional environment in which to understand the shotlines, and hence make a determination as to the potential vulnerabilities of this prototype design.
Because the task of computing the intersection of shotlines with the target involved primarily the computation of distances and angles, it was immediately apparent that this was a problem well suited for an electronic digital computer. However, computerizing the production of shotlines imposed a new burden: the need for an explicit, complete, and fully three dimensional description of the target geometry -- and in computer-readable form! The preparation of such a target description was a daunting task in itself, for several reasons.
First, it was necessary to devise a representation of three dimensional shapes which were easy for the human to specify and visualize, a good specification of the shape of the target geometry, and were efficient for the computer to intersect with shotlines.
Second, for each target it was necessary for some human being to read and interpret the often woefully incomplete specification of the target's shape and create an exact and consistent three-dimensional computer representation of that shape. This human became known as a target describer. In the best case, the target describer would have an actual full-scale vehicle to measure, but that luxury has been very rare. More often the target describer has been provided with a set of engineering drawings or blueprints and some accompanying machine-shop instructions. As any machinist will tell you, there is a very high level of both art and skill required to take an engineering drawing and convert it into a process that results in a manufacturable item; the resulting item as manufactured is often somewhat different than the part described by the drawing. Target describers have had to develop a similar set of skills, to allow them to understand and specify the three-dimensional shapes that the blueprints hint at. In the worst case, a target describer might be presented with a few crude sketches and/or some blurry reconaissance photographs; in this case there is no hope of an "accurate" target description -- the target describer has to call upon their personal understanding of the design of military vehicles and "make up" enough information to create a consistent three-dimensional model.
As you might imagine, developing a representation of three-dimensional shapes suitable for the task of automatic shotline intersection was the more tractable part of the problem. In the years from 1958 to 1967, employees of BRL and AMSAA devised a geometric technique that involved the combination of certain simple primitive solid volumes using the boolean operations of union, difference, and intersection. This technique was implemented as a working FORTRAN program by The Mathematical Applications Group, Inc. of ??? New York (MAGI); the program was dubbed the "MAGIC code". In 1967 the Joint Technical Coordinating Group for Munitions Effectiveness (JTCG/ME) issued a three volume report documenting the use and operation of the MAGIC code. At the time a version of the MAGIC code was available for two of the worlds largest supercomputers: the CDC 6600 and the BRLESC.
Given the specification of a planar grid of regularly spaced cells, and a shot direction, the MAGIC code would write an output tape containing the list of components hit by the ray departing each cell heading in the specified shot direction. These tapes were dubbed shotline files; as each one took a substantial amount of computer time to generate, they were re-used and shared as much as possible. Durring this time period, there were no graphical tools available with which to view either the input or the outputs of these calculations -- both input and output were spot-checked by careful manual inspection.
After some years of experience had been gained, a second generation of the MAGIC code was developed. The new program was dubbed GIFT: Geometric Information From Targets. It was designed to be upwards compatible from the original MAGIC code, while incorporating an additional variety of primitive geometric shapes, a bounding volume algorithm which yeilded substantially faster runtimes than with the MAGIC code, and perhaps most importantly, a capability for graphical output. By comparing the information from the first hit-point of each cell in the shotline file, GIFT was able to detect differences, and produce Calcomp pen-plotter drawing commands to delimit those differences. The result was a stair-step raster approximation to the profile edges of the target, drawn in ink on the pen-plotter.
The significance of this capability can not be under-emphasised; for the first time it was possible for humans to inspect the target geometry visually, rather than pouring over inch-thick stacks of numbers printed on lineprinter paper. Even still, it was an expensive and time-consuming operation to generate such a plot. In order to get a reasonable-looking drawing it was necessary to use not 4-inch cell spacing, as was typical for vulnerability analysis of the day, but 2-inch cell spacing or finer. This required several hours of supercomputer time to generate each view. Furthermore, the raster-style drawing commands given to the pen-plotter calling for innumerable very short length lines to be drawn were not of a form that made efficient use of of the pen-plotter; the resulting plots took a long time for the plotter to draw, and were the source of frequent mechanical breakdowns of the plotter.
MAGIC and GIFT were very successful programs. By automating the process of shotline file generation, they permitted vulnerability analysts to consider many more possible shots than with the earlier manual methods. At the same time, by eliminating the "bottleneck" in the shotline generating process, they created a new bottleneck: creating the target descriptions. Target describing required great powers of visual imagination as well as a facility with trigonometry and patience for a great deal of math. It really was a new field of endeavor, which most V/L analysts were poorly-trained to engage in. Even assisted by special "helper programs" written for the Wang computer, creating a target description was a long and arduous task, requiring a man-year or more of time. While having the computerized target description permitted vastly more shotlines to be considered compared to the manual method, it really did nothing to speed up the delivery of V/L analysis results. Diverting years of trained analysts time into target describing decreased the amount of time analysts had to do their jobs, ironically hastening the computerization of the analysis function just as the shotlining function had been computerized earlier.
In late 1979, Earl Weaver was frustrated by the difficulty of visualizing the complex shapes involved in the target description for the prototype XM1 tank design, and was tantalized by the promise of truely interactive three-dimensional graphics demonstrated on the Vector General 3DI calligraphic video displays purchased by Mort Hirschberg and brought into real-time operation on the PDP-11/70 based UNIX system by Mike Muuss. Employing the strategem of a bet, Weaver bet Muuss that Muuss couldn't spin a three-dimensional drawing of the XM1 geometry on the Vector General display. With the guilbility of youth, Muuss rose to the challenge; producing a static display in one day, and a fully three-dimensional rotating display in a second day. This remarkable accomplishment drew lots of attention, leading many to ask whether interactive graphical editing of the geometry would be possible. Muuss and Weaver teamed up to extend the viewing program into a geometry editor, which in the terse naming style promoted by UNIX they dubbed GED (GEometry Editor); the demonstrated GED and the ".g" geometry database at the BRL Spring Technical Conference early in 1980.
It took three years for the prototype GED to mature into a program rich enough and stable enough to be useful for production tasks, and for sufficient computer infrastructure to be purchased and assembled to support the near-continuous use of the graphics display hardware that production tasks required. Dr. Paul Deitz lead a vigorous effort to obtain the necessary hardware, purchasing another PDP-11/70 system and an Ikonas framebuffer, to supplement the Vector General calligraphic display.
The arrival of the Ikonas framebuffer spawned the development of an entirely different set of software libraries and utility programs than GED and it's solid geometry database; these new programs operated on pixel data, allowing color shaded images to manipulated and displayed on the framebuffer.
With GED in production status, the pressure on target describing started to ease, allowing some targets to be modeled in less than one tenth the time required by the manual method. It also allowed the modelers the luxury of including more geometric detail than had previously been possible. With more and more target descriptions being turned out, and at increasingly high levels of resolution, the bottleneck shifted to visualizing and validating the models. Calcomp pen-plots were being produced in record numbers, but it wasn't sufficient. Gary Kuehl modified GIFT to produce a "pretty picture" file which assigned colors to each cell based upon the region-ID that was hit, and he wrote a corresponding program for UNIX that would display the "pretty picture" file on the Ikonas framebuffer. This instantly propelled BRL into the realm of ray-traced rendering.
The GIFT "pretty picture" capability created an enormous demand for color shaded images. Paul Deitz wanted to improve the quality of the images by adding additional optical effects, including shadows, reflection, transmission through glass, and refraction. Because of the intrinsically batch nature of GIFT, there was no way for the physics-of-light code to steer the shotline directions of GIFT. A new approach was called for.
In 1983 Mike Muuss set out to create both a shotline-based optical simulation, or lighting model, and a set of subroutines capable of providing shotlines on demand. He dubbed the resulting program RT, for "ray tracer". His early success prompted Gary Moss to build an even more elaborate lighting model called LGT. At first Moss just linked his program with a set of compiled modules from Muuss' directory, but it quickly became apparant that the shotlines-on-demand capability was of wide applicability. Muuss designed a more general interface, and moved all the ray-tracing and geometry support off into a standalone library called LIBRT, the library for ray-tracing targets. The idea of shotlines-on-demand took hold, and the hallways were full of discussions about how easy it would be now to simulate main penetrator deflection and track spall clouds through the target.
By 1984 a rather substantial body of software for the UNIX system had been collected, spanning a number of rather different areas in computer-aided geometric modeling and image processing: GED, the geometry editor, LIBRT, the shotline-on-demand library, RT and LGT, physical simulations of optical effects, LIBFB, the library for operating framebuffer hardware, and dozens of image processing and framebuffer utilities.
In order to be able to share all this software with others, Muuss bundled it all together into one coherent tree of source code, placed it all under revision control using RCS, and dubbed the resulting package "BRL-CAD". The first BRL-CAD tapes were written in 1984 to support benchmarking for the competitive procurement which eventually resulted in the purchase of 10 MIPS Gould super-minicomputers. By 1985 BRL-CAD tapes were being sent outside BRL to other agencies.
At the core of BRL-CAD is the ".g" file, the geometry database
which contains target descriptions. Utilizing the shotlines-on-demand
feature of LIBRT, BRL-CAD supports a wide variety of physics-based
analysis codes, including neutron transport, optical simulation,
and projectile path prediction.
At present, BRL-CAD supports 22 distinctly different types of primitive solids. The simplest is the ellipsoid, which is defined as a point at the center (termed "V"), and three perpendicular vectors (A, B, and C) which together specify the eccentricity and orientation of the ellipsoid. The sphere is a special case of the ellipsoid. The most complex primitive type is an n-Manifold Geometry solid with trimmed-NURBS surfaces.
Here is a colorful example of several of the simpler shapes, perched
on a mirrored surface.
(Um, no, that's a different image!!)
The most important thing to know about the primitive solids is that each and every one of them is, by definition, a solid: an enclosed volume with a distinct inside and outside. This provides an important conceptual distinction between CSG solid modeling, and the more common boundary-surface modeling (such as is used in AutoCAD and similar packages).
The primitive solids are combined together to form more complex shapes, using the boolean operations of union, difference (subtraction), and intersection. This allows very complex shapes to be built up in a very natural and intuitive way, with the subtraction operation corresponding to material removal processes (milling, drilling, etc.), and with the union operation corresponding to material bonding processes (glueing, welding, etc.)
When a boolean combination of primitive solids has been formed which represents a single part or component comprised of homogeneous material, it is given a special marker, and is termed a region.