.NH 1
BRL's Solid Modeling Editor MGED:  A Case Study
.PP
There are a significant number of solid modeling systems,
each developed for different purposes by different groups.
In this paper, details of the design of BRL's solid modeling system
.[
BRL MGED
.]
will be presented.
This presentation both documents some of the specific capabilities
of the BRL system, and also serves as a good case study of
the features and functionality that should be present in every solid
modeling system.
Most features are comparable to those found in commercial systems.
.NH 2
Philosophy
.PP
The role of CAD models at BRL differs somewhat from
that of CAD models being built in the automobile and aerospace industries,
resulting in some different design choices
being made in the BRL CAD software.
Because BRL's main use for these models is to conduct detailed
performance and survivability analyses of large complex vehicles,
it is required that the model of an entire vehicle be completely contained
in a single database, suitable for interrogation by the application codes.
This places especially heavy demands on the database software.
At the same time, a somewhat more modest level of detail is required
for these analysis codes than if direct NC machining was the primary goal.
.PP
At BRL, there are only a small number of primary designers responsible
for the design of a vehicle, and for the construction of the corresponding
solid model.  Together they decide upon and construct the
overall structure of the model,
then they perform the work of building substructures in parallel,
constantly combining intermediate results into the full model database.
Because of the need to produce rapid prototypes (often creating a full design
within a few weeks), there is no time for a separate integration stage;
subsystem integration must be an ongoing part of the design process.
.PP
Once an initial vehicle design is completed, there is usually the
need for exploring many alternatives.  Typically, between 3 and 12
variations of each design need to be produced, analyzed, and optimized
before recommendations for the final design can be made.
Also, there is a constantly changing definition of performance;
based on new developments it may be necessary to rapidly re-evaluate
all the designs of the past several years for trouble spots.
.PP
The user interface is designed to be powerful and ``expert friendly'' rather
than foolproof for a novice to use, much like UNIX.
However, it only takes about two days for new users to start doing useful
design work with MGED.
True proficiency comes with a few months practice.
.PP
Finally, it is vitally important that the software offer the same capabilities
and user interface across a wide variety of display and processor hardware.
Government procurement regulations make single-vendor solutions difficult.
The best way to combat this is with highly portable software.
.NH 2
Displays Supported
.PP
It is important for a CAD system to have a certain degree of independence
from any single display device in order to provide longevity of the
software and freedom from a single equipment supplier.
The MGED editor supports serial use of multiple displays by way of
an object-oriented programmatic
interface between the editor proper and the display-specific code.
All display-specific code for each type of hardware is thus isolated
in a separate \fIdisplay manager\fR module.
High performance of the display manager was an important design goal.
Existing graphics libraries
were considered, but no well established standard existed with the necessary
performance and 3-dimensional constructs.
By having the display manager modules incorporated as a direct part of
the MGED editor, the high rates of display update necessary to deliver
true interactive response are possible, even when using CPUs of modest power.
.PP
An arbitrary number of
display managers may be included in a copy of MGED, allowing the user
to rapidly and conveniently move his editing session from display to display.
This is useful for switching between several displays, each of
which may have unique benefits:  one might have color capability,
and another might have depth cueing.
The ``release'' command closes out MGED's use of the current
display, and does an implicit attach to the ``null'' display manager.
This can be useful to allow another user to briefly examine an image
on the same display hardware without having to lose the state of
the MGED editing session.  The ``attach'' command is used to
attach to a new display via it's appropriate display manager routines.
If another display is already attached, it is released first.
The null display manager also allows the MGED editor to be run from a normal
alphanumeric terminal with no graphic display at all.  This can be useful
when the only tasks at hand involve viewing or changing
database structures, or entering or adjusting geometry parameters
in numerical form.
.PP
Creation of a new display manager module in the ``\fBC\fR'' language
.[
the C programming language
.]
generally takes an experienced
programmer from one to three days.
The uniform interface to the display manager provides two levels
of interactive support.
The first level of display support includes
the Tektronix 4014, 4016, and compatible displays,
including the Teletype 5620 bit-mapped displays.
However, while storage-tube style display devices allow MGED to
deliver the correct functionality, they lack the
rate of screen refresh needed for productive interaction.
The second level of support, including real-time interaction,
is provided by
the Vector General 3300 displays,
the Megatek 7250 and 7255 displays,
the Raster Technologies Model One/180 display,
the Evans and Sutherland PS300 displays
with either serial, parallel, or Ethernet attachment,
and the Silicon Graphics IRIS 2400 workstation family.
.NH 2
Portability
.PP
Today, the half-life of computer technology is
approximately two to three years.
To realize proper longevity of the modeling software, it needs to be written
in a portable language to allow the software to be moved readily from
processor to processor without requiring the modeling software or users
to change.
Then, when it is desirable to
take advantage of the constantly increasing 
processor capabilities and similarly increasing memory capacity by replacing
the installed hardware base, there are a minimum of ancillary costs.
Also, it may be desirable to connect together processors from a variety
of vendors, with the workload judiciously allocated to
the types of hardware that best support the requirements of each particular
application program.
This distribution of processing when coupled with the fact that
users are spread out over multiple locations makes networking a vital
ingredient as well.
.PP
BRL's strategy for achieving this high level of portability was to target
all the software for the UNIX operating system,
.[
Ritchie Thompson time-sharing system
.]
with all the software written in the ``\fBC\fR''
programming language.
.[
the C programming language
.]
All communications software is based upon the TCP/IP protocol suite
developed by DARPA
.[
Feinler ddn protocol handbook
.]
and now formally designated MIL-STD-1777 and MIL-STD-1778.
The CAD software is currently running on all UNIX machines at BRL,
under several versions of the UNIX operating system, including
Berkeley 4.3 BSD UNIX, Berkeley 4.2 BSD UNIX, and AT&T System V UNIX.
In addition, there has been a limited subset of the software
ported to the Digital Equipment Corporation VAX/VMS operating system,
using the VMS C compiler.
.PP
The list of manufacturers and models of CPUs that support the UNIX
operating system
.[
Deitz modern tools system engineering
.]
is much too lengthy to include here.  However, BRL
has experience using this software on
DEC VAX 11/750, 11/780, 11/785 processors,
Gould PN6000 and PN9000 processors,
Alliant FX/8 processors (including systems with 8 CPUs),
Silicon Graphics IRIS 2400, 2400 Turbo, and 3030 workstations,
and the ill-fated Denelcor HEP H-1000 parallel supercomputer.
.KF
.PS
scale=300
box invis ht 570 wid 400 with .sw at 0,0
"\f1\s14\&Display\d1\f1\s0" at 100,30
line -> from 150,104 to 100,42 
"\f1\s14\&Display\dN\f1\s0" at 300,30
line -> from 250,104 to 300,42
"\f1\s18\&...\f1\s0" at 200,67
"\f1\s14\&Display Managers 1..N\f1\s0" at 200,135
box ht 52 wid 300 with .nw at 50,160
spline -> from 280,307\
to 317,299\
to 380,252\
to 384,160\
to 350,135
"\f1\s14\&Geometry Routines\f1\s0" at 200,204
box ht 44 wid 280 with .nw at 60,224
spline -> from 120,305\
to 40,280\
to 5,260\
to 5,230\
to 60,200
"\f1\s18\&MGED\f1\s0" at 200,305
box ht 65 wid 160 with .nw at 120,340
"\f1\s14\&Database\ \ Interface\f1\s0" at 200,401
line -> from 200,465 to 200,341 
"\f1\s18\&Database\f1\s0" at 200,500
line  from 100,535 to 300,535
line  from 100,465 to 300,465
ellipse ht 70 wid 18 at 100,500
ellipse ht 70 wid 18 at 300,500
.PE
.ce 1
\fBFigure 2.1 \(em Object-Oriented Design\fR
.KE
.NH 2
Object-Oriented Design
.PP
The central editor code has four sets of object-oriented interfaces
to various subsystems, including database access, geometry processing,
display management, and command parser/human interface,
as depicted in figure 2.1.
In each case, a common interface has been defined for the set of
functions that implement the overall function;
multiple instances of these function sets exist when a multiplicity
of support exists.
The routines in each instance of a function set are completely independent
of all the routines in other functions sets, making it easy to add new
instances of the function set.  A new type of primitive geometry,
a new display manager, a new database interface, or a new command
processor can each be added simply by writing all the routines
to implement a new function set.
This approach greatly simplifies software maintenance, and allows
different groups to have responsibility for the
creation and enhancement of features within each of the function sets.
.KF
.PS
scale=300
box invis ht 390 wid 605 with .sw at 0,0
line  from 477,100 to 526,70
line  from 359,100 to 415,70
line  from 335,100 to 303,70 
line  from 234,100 to 274,70
line  from 198,100 to 165,70 
line  from 95,100 to 149,70
line  from 95,100 to 58,70
line  from 132,169 to 84,150
line  from 167,169 to 217,150
line  from 276,172 to 217,150 
line  from 289,172 to 344,150 
line  from 415,172 to 464,150 
line  from 370,252 to 415,223
line  from 346,252 to 308,223 
line  from 247,252 to 289,223 
line  from 210,252 to 171,223 
ellipse ht 62 wid 116 at 547,35
ellipse ht 62 wid 116 at 423,35
ellipse ht 62 wid 116 at 303,35
ellipse ht 62 wid 116 at 180,35
ellipse ht 62 wid 116 at 58,35
box ht 50 wid 96 with .nw at 429,150
box ht 50 wid 96 with .nw at 169,150 
box ht 50 wid 96 with .nw at 296,150 
box ht 50 wid 96 with .nw at 36,150
box ht 50 wid 96 with .nw at 367,220 
box ht 50 wid 96 with .nw at 241,220
box ht 50 wid 96 with .nw at 108,220
box ht 50 wid 96 with .nw at 310,305 
box ht 50 wid 96 with .nw at 174,305
.PE
.ce 1
\fBFigure 2.2 \(em Hierarchy\fR
.KE
.NH 2
Directed Acyclic Graph and Database Details
.PP
The database is stored as a single,
binary, direct-access
UNIX file for efficiency and cohesion,
with fixed length records called database \fIgranules\fR.
Each object occupies one or more granules of storage.
The user sees and manipulates the directed acyclic graphs
like UNIX paths (e.g., car/chassis/door),
but in a global namespace.
There can be many independent or semi-independent
directed acyclic graphs within the same database,
each defining different models, as depicted in figure 2.2.
The figure also makes heavy use of the \fIinstancing\fR capability.
As mentioned earlier, the
\fIleaves\fR of the graph are the primitive solids.
.PP
Commands exist to import sub-trees from other databases and libraries,
and to export sub-trees to other databases.
Also, converters exist to dump databases in printable form for
non-binary interchange.
Within the database,
all points are stored as floating point numbers, in millimeters.
However, it is important to note that the 
user edits in his choice of arbitrary working units.
.NH 2
Interaction Forms
.PP
Textual and numeric interaction with the MGED editor is the most
precise editing paradigm because it allows exact
manipulation of known configurations.
This works well when the user is designing the model
from an existing drawing, or when all dimensions are known (or are computable)
in advance.
.PP
The use of a
tablet or mouse, knob-box or dial-box, buttons, and a joystick
are all simultaneously supported by MGED for analog inputs.
Direct graphic interaction via a ``point-push-pull'' editing paradigm
tends to be better for
prototyping, developing arbitrary geometry, and fitting
together poorly specified configurations.
Having both types of interaction capability available at all times
allows the user to select the style of interaction that best
meets his immediate requirements.
.NH 2
The Faceplate
.PP
When the MGED program has a display device attached, it
displays a border around the region of the screen being used
along with some ancillary status information.  Together, this
information is termed the editor ``faceplate''.
In the upper left corner of the display is a small enclosed area
which is used to display the current editor state;
this is discussed further in the Editor States section, below.
.PP
Underneath the state display is a zone in which three ``pop-up'' menus
may appear.  The top menu is termed the ``button menu'' as it
contains menu items which duplicate many of the functions assigned to
the button box.  Having these frequently used
functions available on a pop-up menu
can greatly decrease the number of times that the user needs to remove
his hand from the pointing device (either mouse or tablet puck)
to reach for the buttons.
An example of the faceplate and first level menu is shown in plate 2.1.
The second menu is used primarily for the various editing states,
at which time it contains all the editing operations which are generic
across all objects (scaling, rotation, and translation).
The third menu contains selections for object-specific editing operations.
The choices on these menus are detailed below.
It is important to note that while some display hardware that MGED runs on
has inherent support for pop-up menus included, MGED does not
presently take advantage of that support, preferring to depend
on the portable menu system within MGED instead.
It is not clear whether the slight increase in functionality that might
accrue from using display-specific menu capabilities would offset the
slight nuisance of a non-uniform user interface.
.PP
Running across the entire bottom of the faceplate is a thin rectangular
display area which holds two lines of text.
The first line always contains a numeric display of the model-space
coordinates of the center of the view and the current size of
the viewing cube, both in the currently selected editing units.
The first line also contains the current rotation rates.
The second line has several uses, depending on editor mode.
Normally it displays the formal name of the database that is being
edited, but in various editing states this second line will instead
contain certain path selection information.
When the angle/distance cursor function is activated, the second
line will be used to display the current settings of the cursor.
.PP
It is important to mention that while the database records all
positions in terms of millimeters, all numeric interaction between
the user and the editor are in terms of user-selected display units.
The user may select from millimeters, centimeters, meters, inches, and
feet, and the currently active display units are noted in the first
display line.
.PP
The concept of the ``viewing cube'' is an important one.
Objects drawn on the screen are clipped in X, Y, and Z, to the size
indicated on the first status line.
This feature allows extraneous wireframes which are positioned within view
in X and Y, but quite far away in the Z direction to not be seen,
keeping the display free from irrelevant objects when zooming in
very close to a particular part of the model.
.NH 2
Changing the View
.PP
At any time in an editing session, the user may add one or more
subtrees to the active model space.  If the viewing cube is
suitably positioned, the newly added subtrees are drawn on the display.
(The ``reset'' function can always be activated to get the entire active
model space into view).
The normal mode of operation is for users to work with wireframe
displays of the unevaluated primitive solids.  These wireframes can be
created from the database very rapidly.
.PP
On demand, the user can request the calculation of
approximate boundary wireframes that account for
all of the boolean operations specified along the arcs of the
directed acyclic graph in the database.
This is a somewhat time consuming process, so it is not used
by default, but it is quite reasonable to use whenever the
design has reached a plateau.
Note that these boundary wireframes are not stored in the database,
and are generally used as a visualization aid for the designer.
Plate 2.2 shows an engine connecting rod.
On the left side is the wireframe of the unevaluated primitives
that the part is modeled with, and on the right side is the approximate
boundary wireframe that results from evaluating the boolean expressions.
.PP
Also, at any time the user can cause any part of the active model space
to be dropped from view.
This is most useful when joining two complicated subsystems
together;  the first would be called up into the active model space,
manipulated until ready, and then the second subsystem would also be
called up as well.  When any necessary adjustments had been made
(perhaps to eliminate overlaps or to change positioning tolerances),
one of the subassemblies could be dropped from view,
and editing could proceed.
.PP
The position, size, and orientation of the viewing cube can be
arbitrarily changed during an editing session.
The simplest way to change the view is by selecting one of nine
built in preset views, which can be accomplished by a simple keyboard
command, or by way of a button press or first level menu selection.
The user is given the ability to execute a ``save view'' button/menu
function that attaches the current view to a ``restore view'' button/menu
function.
The rate of rotation around each of the X, Y, and Z axes
can be selected by knob, joystick, or keyboard command.
Because the rotation is specified as a rate, the view
will continue to rotate about the view center until the rotation
rate is returned to zero.
Similarly, the zoom rate (in or out) can be set by keyboard
command or by rotating a control dial.
Also, displays with three or more mouse buttons have binary (2x) zoom
functions assigned to two of the buttons.
Finally, it is possible to set a slew rate to translate the view
center along X and/or Y in the current viewing space, selectable
either by keyboard command or control dial.
In VIEW state, the main mouse button translates the
view center;  the button is defined to cause the indicated point to become
the center of the view.
.PP
This assignment of zoom and slew functions to the mouse buttons tends to
make wandering around in a large model very straightforward.
The user uses the binary zoom-out button to get an overall view, then
moves the new area for inspection to the center of the view and uses
the binary zoom-in button to obtain a ``close up'' view.
Plate 2.3 show such a close up view of the engine connecting rod.
Notice how the wireframe is clipped in the Z viewing direction
to fit within the viewing cube.
.NH 2
Model Navigation
.PP
In order to assist the user in creating and manipulating a complicated
hierarchical model structure, there is a whole family of editor commands
for examining and searching the database.
In addition, on all keyboard commands, UNIX-style regular-expression
pattern matching, such as ``*axle*'' or ``wheel[abcd]'', can be used.
The simplest editor command (``t'') prints a table of contents, or directory,
of the node names used in the model.  If no parameters are specified,
all names in the model are printed,
otherwise only those specified are printed.
The names of solids are printed unadorned, while the names of combination
(non-terminal) nodes are printed with a slash (``/'') appended to them.
.PP
If the user is interested in obtaining detailed information about the
contents of a node, the list (``l'') command will provide it.
For combination (non-terminal) nodes, the information about all departing
arcs is printed, including the names of the nodes referenced, the boolean
expressions being used, and an indication of any translations and rotations
being applied.
For leaf nodes, the primitive solid-specific ``describe yourself''
function is invoked, which provides a formatted display of the parameters
of that solid.
.PP
The ``tops'' command is used to find the names of all nodes which are
not referenced by any non-terminal nodes;  such nodes are either
unattached leaf nodes, or tree tops.
To help visualize the tree structure of the database,
the ``tree'' command exists to
print an approximate representation of the database subtree below the
named nodes.
The ``find'' command can be used to find the names of all non-terminal
nodes which reference the indicated node name(s).  This can be very helpful
when trying to decide how to modify an existing model.
A related command (``paths'') finds the full tree path specifications
which contain a specified graph fragment, such as ``car/axle/wheel''.
In addition to these commands, several more commands exist
to support specialized types of searching through the model database.
.KF
.PS
scale=250
box invis ht 290 wid 380 with .sw at 0,0
"\f1\s18\&Viewing\f1\s0" at 170,281
line -> from 121,267 to 45,215
"\f1\s16\&Obj EDIT\f1\s0" at 45,58
line -> from 45,167 to 45,133 
"\f1\s16\&Obj Path\f1\s0" at 45,118
line -> from 45,104 to 45,77 
"\f1\s16\&Obj Pick\f1\s0" at 45,186
line -> from 102,122 to 145,230 dotted
line -> from 97,192 to 143,230 dotted
spline -> from 40,27\
to 40,17\
to 54,0\
to 112,0\
to 150,29\
to 159,231
line -> from 320,177 to 320,147 
"\f1\s16\&Solid Pick\f1\s0" at 320,192
line -> from 256,204 to 210,230 dotted
line -> from 222,275 to 320,215 
"\f1\s16\&Solid EDIT\f1\s0" at 320,126
spline -> from 320,111\
to 320,90\
to 310,60\
to 290,40\
to 200,40\
to 180,230
.PE
.ce 1
\fBFigure 2.3 \(em Editor State Transitions\fR
.KE
.NH 2
Editor States
.PP
The MGED editor operates in one of six states, with a state transition
diagram as shown in figure 2.3.
Either of the two PICK states can be entered by button press,
menu selection, or keyboard command.  The selection of the desired
object can be made either by using \fIilluminate mode\fR, or by
keyboard entry of the name of the object.
.PP
Illuminate mode is arranged such that if there are $n$ objects visible on
the screen, then the screen is divided into $n$ vertical bands.
By moving the cursor (via mouse or tablet) up and down through these bands,
the user will cause each solid in turn to be highlighted on the screen,
with the solid's name displayed in the faceplate.
The center mouse button is pressed when the desired solid is located, causing
a transition to the next state (Object Path, or Solid Edit).
.PP
Illuminate mode offers significant advantages over more conventional pointing
methods when the desired object lies in a densely populated region of the
screen.  In such cases, pointing methods have a high chance of making an
incorrect selection.
However, in sparsely populated regions of the screen, a pointing paradigm
would be more convenient, and future versions of MGED will support this.
.NH 2
Add Primitive
.PP
Another family of commands exists to allow the user to
add more actual solids (leaf nodes) to the model database.
To obtain a precise duplicate of an existing solid (presumably to be
changed by a subsequent editing command), the copy (``cp'') command
can be used.  It is important to note that the copy operation is
different from creating an \fIinstance\fR of an existing solid;
there are occasions to use both operations.
If the precise configuration of the solid desired is not important, the
``make'' command can be used to create a stock prototype solid of the
desired type with the given name, which can then be edited to suit.
The ``mirror'' command makes a
duplicate of an existing solid reflected about
one of the coordinate axes.
.PP
If the actual numeric parameters of a solid are known, then the ``in''
command can be used.  In addition to prompting for the descriptions of
the full generic primitive solids, this command also accepts
abbreviated input formats.  For example, a wedge or an RPP can be entered
with a minimum of parameters, even though a database ARB8 is created.
Similarly, the parameters for a right circular cylinder can be given,
resulting in a truncated general cone (TGC) being stored.
This is not a very sophisticated way to build solids, but it receives
a surprising amount of use.
.PP
A number of commands also exist to create new solids with some
higher level description.  For example, the ``inside'' command
creates a new solid inside an existing solid, separated from the
existing solid by specified tolerances.  This is quite useful for
creating hollow objects such as fuel tanks.
It is possible to create a piece of metal plate with a specified
azimuthal orientation and fallback angle, or to create an ARB8 (plate)
by specifying three points and a thickness, or to create an ARB8
given one point, an azimuthal orientation, and a fallback angle.
.NH 2
Edit Primitive
.PP
There are two classes of editing operations that can be performed on
leaf nodes, the primitive solids.
The first class of operations are generic operations which can be applied to
any type of solid, and the second class of operations are those operations
which are specific to a particular type of solid.
Generic operations which can be applied to all primitive solids are all
those transformations that can be specified by a 4-by-4 homogeneous
transformation matrix;  each type of transformation can be performed
through several types of user direction.
Primitives can be rotated around the center of the viewing cube;
this rotation can be specified in degrees via keyboard command, or can
be controlled by the rotation of a set of control dials or the motions of
a three-axis joystick.
Translation of a primitive can be specified in terms of a precise new location
via keyboard command, or by adjustment of a set of control dials.
The primitive can also be moved to a designated position by pointing and
clicking with the mouse or tablet.
Uniform and single-axis (affine) scaling of a primitive can be controlled
by a numeric scale factor via keyboard command, or through repeated
analog scaling by pointing and clicking with the mouse or tablet.
.PP
Finally, the numeric parameters which define the actual primitive solid
can be edited using the user's choice of UNIX text editor (specified by
the EDITOR environment variable).
The ``tedit'' command
forms a printed representation of the solid's numeric parameters in a
temporary file and forks a sub-process to allow the user to edit that file.
When the text editor exits, MGED regains control, parses the file back into
the internal representation of the primitive, and remains in the SOLID EDIT
state to allow further modifications.
.PP
Each primitive solid also has a variety of editing operations available that
are specific to the definition of that solid.  Many of these operations are
detailed below, but all fall into one of two classes.
First, simple scalar parameters such as a radius can be entered numerically
via a single parameter keyboard command (``p''),
or they can be adjusted in analog
form by pointing and clicking with the mouse or tablet.
Secondly, defining vectors can be made to pass through a specified point,
or changed to terminate at a given point.  The particular point can be
specified by entering three parameters to the ``p'' command,
or by pointing and clicking with the mouse or tablet to ``drag'' the vector.
.NH 2
Ellipsoid Parameter Edit
.PP
Refer to figure 1.4 for an example of the parameters that control
the ellipsoid.
Most interesting transformations on an ellipsoid can be accomplished
by changing it's orientation in space using the generic operations
such as rotation and translation.
The shape (eccentricity) of the ellipsoid is controlled by varying
the relative lengths of the A, B, and C vectors;  these modifications
are controlled by this solid-specific menu:
.TS
center box;
l.
ELLIPSOID MENU
=
Scale A
_
Scale B
_
Scale C
_
Scale A,B,C
.TE
.NH 2
Truncated General Cone Parameter Edit
.LP
Refer to figure 1.5 for an example of the parameters that control
the truncated general cone.
It is possible to change the length of the H, A, B, C, or D
vectors, resulting in a change in height or eccentricity of the
end plates.  The overall size of the A,B or C,D end plates can
be adjusted, or the size of both can be changed together, leaving
only the H vector constant.
The H vector can be rotated in space, either with the end plates
remaining in the same plane, or with the end plates reorienting to be
perpendicular to the H vector as it changes.
These functions are selected from this menu:
.TS
center box;
l.
TGC MENU
=
scale H
_
scale A
_
scale B
_
scale c
_
scale d
_
scale A,B
_
scale C,D
_
scale A,B,C,D
_
rotate H
_
rotate A $times$ B
_
move end H (rot)
_
move end H
.TE
.NH 2
Torus Parameter Edit
.PP
Refer to figure 1.6 for an example of the parameters that control
the torus.
While the internal representation of the torus allows for elliptical
cross-sections and an elliptical overall shape, those sorts of tori
are rarely needed, and this editing menu only permits changing the
two radii of a torus with circular cross-section
and circular overall shape.
.TS
center box;
l.
TORUS MENU
=
scale r1
_
scale r2
.TE
.NH 2
ARB8 Parameter Edit
.PP
Refer to figure 1.8 for examples of an ARB4 and ARB8.
ARBs are defined by their vertices, but the placements of the vertices
are not entirely free, as each face must be planar.
When an ARB is being edited, the user must specify which
\fIedge\fR is to be moved.  Then the user specifies a point in space
through which the line containing the edge must pass;  this is done
either by numerically specifying the parameters with the ``p'' command,
or by pointing and clicking with the mouse or tablet.
When editing an ARB with 8 distinct vertices, here is the
solid-specific menu that the user would see:
.TS
center box;
l.
ARB8 MENU
=
move edge 12
_
move edge 23
_
move edge 34
_
move edge 14
_
move edge 15
_
move edge 26
_
move edge 56
_
move edge 67
_
move edge 78
_
move edge 58
_
move edge 37
_
move edge 48
.TE
.PP
Plate 2.4 shows the wireframe of a box modeled as an ARB8,
just after entering SOLID EDIT state but before any editing
has taken place.
Plate 2.5 shows the solid after edge ``1-4'' has been moved to
a new location.
.PP
As the number of distinct vertices in the ARB decreases, the number of
menu choices decreases as well, with more and more edge motion choices
turning into point motion choices.
Consider the ARB4 as an example of this;  an example of one is provided
in figure 1.7.
When editing an ARB with only 4 distinct vertices, here is the
solid-specific menu that the user would see:
.TS
center box;
l.
ARB4 MENU
=
move edge 12
_
move edge 23
_
move edge 13
_
move edge 14
_
move edge 24
_
move edge 34
_
move point 4
.TE
.PP
There are several keyboard commands that apply only to ARB solids which are
being edited in SOLID EDIT state.
Once such command is ``mirface'', which replaces a designated
face of the ARB with a copy of an original face mirrored about
the indicated axis.
Another such command is ``extrude'', which projects a designated face
a given amount in the indicated direction.
.NH 2
Creating Non-Terminal Nodes
.PP
Non-terminal nodes in the directed acyclic graph stored in the database
are also called \fIcombinations\fR.
It is possible to extend the definition of a non-terminal node by
adding an instance of an existing node to the non-terminal node
with an associated boolean
operation of union;  this is done by the ``i''
(instance) command.  To start with, such an instance has an identity
matrix stored in the arc;  the user needs to separately edit the
arc to move the instance to some other location.
If the non-terminal node being extended does not exist, it is created first.
.PP
The instance command provides the simplest way to create a reference to
a another node.  Instances of a whole list of nodes can be added to a
non-terminal node by way of the group ``g'' command.
If instances of a list of nodes with non-union boolean operations
is to be added to a non-terminal node, the region ``r'' command
accepts a list of (operation, name) pairs, where the single lower case
character ``u'' indicates union, ``\(em'' indicates subtraction, and
``+'' indicates intersection.  The first operation specified
is not significant.  An example of this command might be:
.ce 1
r non-terminal u node1 \(em node2 + node3
For historical reasons,
there is no explicit grouping possible, occasionally forcing
the user to create intermediate non-terminal nodes to allow the
realization of the desired boolean formula.
It is also important to note that for the same reasons
there is an \fIimplicit\fR grouping between union terms, ie
.ce 1
u n1 \(em n2 + n3 u n4 \(em n5
is evaluated as
.ce 1
(n1 \(em n2 + n3) union (n4 \(em n5)
rather than
.ce 1
((((n1 \(em n2) + n3) union n4) \(em n5)
.PP
MGED contains a few high-level operations implemented as built-in
commands;  the most interesting one of these makes an articulated
track for a vehicle given the locations of the drive, idler, and road
wheels.
It is straightforward to create similar domain-specific built-in
capabilities as desired, merely by adding another function to the
command processor.
.NH 2
Edit Non-Terminal
.PP
Before being able to enter the OBJECT EDIT state
(i.e. edit non-terminal),
it is necessary to pass through two intermediate states
in which the full path of an object to be edited is specified,
and the location of one arc along that path is designated for editing.
It is possible to create a transformation matrix to be applied
above the root of the tree, affecting everything in the path,
or to apply the matrix between any pair of nodes.
For example, if the full path /car/chassis/door is specified,
the matrix could be applied above the node ``car'', between
``car/chassis'', or between ``chassis/door''.
.PP
The transformation matrix to be applied at the
designated location can be created by the concatenation of
operations, each specified through several types of user direction.
Trees can be rotated around the center of the viewing cube;
this rotation can be specified in degrees via keyboard command, or can
be controlled by the rotation of a set of control dials or motions on
a three-axis joystick.
Translation of trees can be specified in terms of a precise new location
via keyboard command, or by adjusting a set of control dials.
Tree translation can also be accomplished by pointing and
clicking with the mouse or tablet.
Uniform and single-axis (affine) scaling of a tree can be controlled
by a numeric scale factor via keyboard command, or by way of repeated
analog scaling by pointing and clicking with the mouse or tablet.
.NH 2
Miscellany
.PP
MGED has a substantial number of commands which defy easy categorization;
some of these commands will be described in this section.
The ``analyze'' command is used to obtain a simple analysis
about a single primitive object, including the
plane equations, surface area, azimuth and fallback angles of each face,
plus the lengths of each edge and the volume of the enclosed space,
both in terms of cubic user units, and also in terms of fluid capacity.
.PP
Given that the current view is of the evaluated boundaries of the
solids, one can obtain a reasonable estimate of the presented area
of the components from the current viewing direction by using
the ``area'' command.
.PP
It is possible to view, specify, and text-edit
information pertaining to the material type and color of various
parts of the model tree.  This is an interim capability
intended to provide enough material properties information for
current rendering and analysis purposes until the design of a
full material properties database can be finalized.
.PP
In addition to a variety of usual database manipulation
and status commands, there are commands to
compare the current database for name overlap (conflicts)
with another database, as well as commands to import and export
subtrees to/from the current database.
If name conflicts between the two databases
do exist, there are commands to rename an individual node without
changing any of the references to it (``mv''), or to rename
a node and change all the references to it (``mvall'').
Another command which is useful for preparing to move subtrees between
databases is the ``push'' command,
which adjusts the transformation matrices from the indicated point
down to the leaves of the directed acyclic graph, leaving the higher
level arcs with identity matrices.
.NH 2
Output Features
.PP
The ``plot'' command can store an exact image of the current
(non-faceplate) display on the screen, either using the
System V standard 2-D monochrome UNIX-Plot (\fIplot(4)\fR) format,
or the BRL 3-D color extended-UNIX-Plot format.
These plots can be sent to a disk file,
or ``piped'' directly to a filter process.
This can be useful for making hard copies of the current MGED view
for showing to others,
using a local pen plotter or laser printer.
.PP
An important capability even beyond the ability to generate an
evaluated boundary wireframe is the ability of MGED to initiate a
quick ray-trace rendering of the current view on any nearby framebuffer!
This is implemented by using the MGED ``rt'' command to fork off
an instance of the RT program, and sending the RT program
a description of the current view
with any user-specified options.
This allows the designer to
use the power of MGED to select the desired view, and then to
quickly verify the geometry and light source placement.
A 50 by 50 pixel rendering of the current view can usually be done
in less than a minute (on a DEC VAX-780 class processor), and allows
for general verification before the designer uses the ``saveview''
command to submit a batch job for a high resolution ray-trace of
the same view.
.NH 2
Animation
.PP
The MGED editor includes a number of features which are useful
for developing animation tools and scripts.
The full description of the current viewing transformation and eye position
can be saved in a file,
and such a previously saved view can be read back at any time,
immediately changing the editor's view.
In addition, the current viewing transformation and eye position can be
appended to a file containing a collection of keyframes.
Most importantly, a file full of keyframe information, either raw keyframe
positions or smoothly interpolated keyframe sequences, can 
by ``played'' in real time using MGED,
providing a powerful and fast animation preview capability.
.PP
As a separate animation capability intended
for developing demonstrations and instructional material relating to the
use of the MGED editor,
all user interactions with the editor can be recorded in a file,
along with an indication of the time elapsed between user actions.
This file can be  adjusted using a normal text editor to remove any errors,
or to eliminate dead time where the user stopped to think.
Once created, this session script can be replayed through the editor
at any time, either to provide a smooth ``canned'' demonstration
before a live audience, or to create a film or videotape.
.NH 2
Model Building Philosophy
.PP
The power of a full directed acyclic graph structure for representing
the organization of the database gives a designer a great deal of
flexibility in structuring a model.
In order to prevent chaos, most designers at BRL choose to
design the overall structure of their model in a top-down manner,
selecting meaningful names for the major structures and sub-structures
within the model.
Actual construction of the details of the 
model generally proceeds in a bottom-up
manner, where each sub-system is fabricated from component primitives.
.PP
The first sub-systems to be constructed are the chassis and skin of the
vehicle, after which a set of analyses are run to validate the geometry,
checking for unintentional gaps in the skin or for solids which overlap.
The second stage of model construction is to build the features of the
main compartments of the vehicle.  If necessary for the analysis
codes that will be used, the different types of air compartments within
the model also need to be described.
The final stage of model construction is to build the internal
objects to the desired level of detail.
This might include modeling engines, transmissions, radios
people, seats, etc.
In this stage of modeling, the experienced designer will draw heavily on the
parts-bin of model components and on pieces extracted from earlier
models, modifying those existing structures to meet his particular
requirements.
.PP
Throughout the model building process it is important for the model builder
to choose part names carefully, as the MGED database currently has a
global name space, with individual node names limited to 16 characters.
In addition, BRL has defined conventions for naming the elements in the
top three levels of database structure so that people will be able to
easily navigate within models prepared at
different times and by different designers,
facilitating the integration of design changes into old models with
a minimum of difficulty.
