## "Fossies" - the Fresh Open Source Software Archive

As a special service "Fossies" has tried to format the requested source page into HTML format using (guessed) TeX and LaTeX source code syntax highlighting (style: standard) with prefixed line numbers. Alternatively you can here view or download the uninterpreted source code file.

    1 \title{\bf{\huge{
2 DRAFT *** DRAFT *** DRAFT \\
3 Users Manual for \\
5 MGED
6 }}}
7 \author{
8 Keith A. Applin \\
9 Michael J. Muuss \\
10 Robert J. Reschly \\
11 {\em US Army Ballistic Research Laboratory} \\
12 {\em Aberdeen Proving Ground, MD} \\
13 \and
14 Alan Collier \\
15 {\em US Army Foreign Science and Technology Center} \\
16 {\em Charlottesville, VA} \\
17 \and
18 Mike Gigante \\
19 Ian Overend \\
20 {\em The Royal Melbourne Institute of Technology} \\
21 {\em Australia}
22 }
23
24 \date{6-October-1988}
25
26 \maketitle
27
28 \tableofcontents
29 \listoffigures
30
31 % ---------------------------------------------------------------------------
32
33 \chapter{INTRODUCTION}
34
35 Computer graphics is one of the fastest growing fields
36 in the computer industry.
37 Computer graphics has applications in many diverse areas, from electronic
38 games to medicine; from cartoons to the space industry.  Just
39 what is interactive computer graphics and why is it so versatile?
40 Human visual perception is quite keen and communicating with a
41 computer is generally faster and easier
42 with images, rather than with
43 numbers. Furthermore, by
44 having the computer continuously updating a display,
45 the display itself becomes the communications medium.
46 The user converses with the computer through the display using
47 devices such as light pens,
48 mice, data tablets, buttons, and
49 knobs.  The response of the computer is immediately reflected
50 on the display,
51 providing a fast communication channel between person and machine.
52 This technology is called interactive computer graphics.
53
54 As the Army's lead laboratory for vulnerability technology, the
55 Ballistic Research Laboratory (BRL) constantly performs
56 analyses for a wide variety of military systems.
57 Three dimensional computer models of the
58 physical characteristics of these systems
59 are vital to these studies.
60 Since the mid-1960's, BRL has used a solid modeling technique
61 called Combinatorial Solid Geometry (CSG or COMGEOM)
62 for representing these models.
63 The COMGEOM technique uses
64 Boolean logic operations to combine basic geometric
65 shapes or primitives to produce complex three-dimensional objects.
66 The COMGEOM geometric models are processed by
67 the Geometric Information
70 and LIBRT
71 \cite{solid-models}
72 for use in follow-on engineering analysis.
73
74 Geometric models are large collections
75 of numerical data which have traditionally
76 been created and edited manually, and analyzed in a batch environment.
77 The production and modification of geometric models has been a slow,
78 labor-intensive
79 process.
80 In 1980, BRL initiated an effort to improve the response
81 time of the geometric modeling process by applying interactive
82 computer graphics techniques.
83 As a result of this work, BRL
84 developed the Multi-device Graphics EDitor (MGED),
85 an interactive editor for solid models
86 based on the COMGEOM technique.
87 Using MGED, a designer can build, view, and modify model descriptions
88 interactively by manipulating the graphical representation,
89 receiving immediate visual feedback on a graphics display.
90 MGED replaces the manual method for the production
91 and modification of geometric models.
92
93 Before MGED was built,
94 existing packages were evaluated with respect to
95 their utility for the geometric modeling process.
96 Quite an exhaustive search of commercially available systems
97 was conducted and none were found which met
98 the BRL requirements.
99 A study was initiated to examine the feasibility of producing
100 the required capability in-house;
101 a preliminary version of MGED which
102 quite convincingly demonstrated the
103 feasibility of such an undertaking \cite{interactive-construction}.
104 It was then decided to develop MGED into a full production code.
105 Production MGED code has been used since January 1982 to
106 build models interactively at BRL.
107
108 This report is intended to serve as  a user manual
109 for the MGED program.
110 The process of viewing and editing a description using MGED
111 is covered in detail.  The internal data structure is also covered, as
112 it is an important part in the overall design.
113 All the commands will be discussed and a command summary table presented.
114 Also, a section will be devoted to the hardware interfaces for each
115 major class of workstations which MGED supports.
116
117 \section{Philosophy}
118
119 The role of CAD models at BRL differs somewhat from
120 that of CAD models being built in the automobile and aerospace industries,
121 resulting in some different design choices
123 Because BRL's main use for these models is to conduct detailed
124 performance and survivability analyses of large complex vehicles,
125 it is required that the model of an entire vehicle be completely contained
126 in a single database suitable for interrogation by the application codes.
127 This places especially heavy demands on the database software.
128 At the same time, these analysis codes require less detail
129 than would be required if NC machining were the primary goal.
130
131 At BRL, there are only a small number of primary designers responsible
132 for the design of a vehicle, and for the construction of the corresponding
133 solid model.  Together they decide upon and construct the
134 overall structure of the model,
135 then they perform the work of building substructures in parallel,
136 constantly combining intermediate results into the full model database.
137 Because of the need to produce rapid prototypes (often creating a full design
138 within a few weeks), there is no time for a separate integration stage;
139 subsystem integration must be an ongoing part of the design process.
140
141 Once an initial vehicle design is completed, there is usually the
142 need for exploring many alternatives.  Typically, between three and twelve
143 variations of each design need to be produced, analyzed, and optimized
144 before recommendations for the final design can be made.
145 Also, there is a constantly changing definition of performance;
146 new developments may necessitate rapidly re-evaluating
147 all the designs of the past several years for trouble spots.
148
149 The user interface is designed to be powerful and expert friendly'' rather
150 than foolproof for a novice to use.
151 However, it only takes about two days for new users to start doing useful
152 design work with MGED.
153 True proficiency comes with a few months practice.
154
155 Finally, it is vitally important that the software offer the same capabilities
156 and user interface across a wide variety of display and processor hardware.
157 Government procurement regulations make single-vendor solutions difficult.
158 The best way to combat this is with highly portable software.
159
160 \section{Displays Supported}
161
162 It is important for a CAD system to have a certain degree of independence
163 from any single display device in order to provide longevity of the
164 software and freedom from a single equipment supplier.
165 The MGED editor supports serial use of multiple displays by way of
166 an object-oriented programmatic
167 interface between the editor proper and the display-specific code.
168 All display-specific code for each type of hardware is isolated
169 in a separate {\em display manager} module.
170 High performance of the display manager was an important design goal.
171 Existing graphics libraries
172 were considered, but no well established standard existed with the necessary
173 performance and 3-dimensional constructs.
174 By having the display manager modules incorporated as a direct part of
175 the MGED editor, the high rates of display update necessary to deliver
176 true interactive response are possible, even when using CPUs of modest power.
177
178 An arbitrary number of
179 display managers may be included in a copy of MGED, allowing the user
180 to rapidly and conveniently move his editing session from display to display.
181 This is useful for switching between several displays, each of
182 which may have unique benefits:  one might have color capability,
183 and another might have depth cueing.
184 The {\bf release} command closes out MGED's use of the current
185 display, and does an implicit attach to the null'' display manager.
186 This can be useful to allow another user to briefly examine an image
187 on the same display hardware without having to lose the state of
188 the MGED editing session.  The {\bf attach} command is used to
189 attach to a new display via its appropriate display manager routines.
190 If another display is already attached, it is released first.
191 The null display manager also allows the MGED editor to be run from a normal
192 alphanumeric terminal with no graphic display at all.  This can be useful
193 when the only tasks at hand involve viewing or changing
194 database structures, or entering or adjusting geometry parameters
195 in numerical form.
196
197 Creation of a new display manager module in the {\bf C}'' language
198 \cite{c-prog-lang}
199 generally takes an experienced
200 programmer from one to three days.
201 The uniform interface to the display manager provides two levels
202 of interactive support.
203 The first level of display support includes
204 the Tektronix 4014, 4016, and compatible displays,
205 including the Teletype 5620 bit-mapped displays.
206 However, while storage-tube style display devices allow MGED to
207 deliver the correct functionality, they lack the
208 rate of screen refresh needed for productive interaction.
209 The second level of support, including real-time interaction,
210 is provided by
211 the Vector General 3300 displays,
212 the Megatek 7250 and 7255 displays,
213 the Raster Technologies Model One/180 display,
214 the Evans and Sutherland PS300 displays
215 with either serial, parallel, or Ethernet attachment,
216 the Sun workstations,
217 and the Silicon Graphics IRIS workstation family.
218
219 \section{Portability}
220
221 Today, the half-life of computer technology is
222 approximately two to three years.
223 To realize proper longevity of the modeling software, it needs to be written
224 in a portable language to allow the software to be moved readily from
225 processor to processor without requiring the modeling software or users
226 to change.
227 Then, when it is desirable to
228 take advantage of the constantly increasing
229 processor capabilities and similarly increasing memory capacity by replacing
230 the installed hardware base, there are a minimum of ancillary costs.
231 Also, it may be desirable to connect together processors from a variety
232 of vendors, with the workload judiciously allocated to
233 the types of hardware that best support the requirements of each particular
234 application program.
235 This distribution of processing when coupled with the fact that
236 users are spread out over multiple locations makes networking a vital
237 ingredient as well.
238
239 BRL's strategy for achieving this high level of portability was to target
240 all the software for the UNIX operating system,
241 \cite{unix-ts-sys},
242 with all the software written in the {\bf C}''
243 programming language \cite{c-prog-lang}.
244 The entire BRL-CAD Package, including the MGED editor
245 is currently running on all UNIX machines at BRL,
246 under several versions of the UNIX operating system, including
247 Berkeley 4.3 BSD UNIX, Berkeley 4.2 BSD UNIX, and AT\&T System V UNIX.
248
249 The list of manufacturers and models of CPUs that support the UNIX
250 operating system \cite{modern-tools-hi-res}
251 is much too lengthy to include here.  However, BRL
252 has experience using this software on
253 DEC VAX 11/750, 11/780, 11/785 processors,
254 Gould PN6000 and PN9000 processors,
255 Alliant FX/8 and FX/80 processors (including systems with eight CPUs),
256 Silicon Graphics IRIS 2400, 2400 Turbo, 3030, 4-D, and 4-D/GT workstations,
257 the Cray X-MP, the Cray-2,
258 and the ill-fated Denelcor HEP H-1000 parallel supercomputer.
259
260 \section{Object-Oriented Design}
261
262 The central editor code has four sets of object-oriented interfaces
263 to various subsystems, including database access, geometry processing,
264 display management, and command parser/human interface.
265 In each case, a common interface has been defined for the set of
266 functions that implement the subsystem;
267 multiple instances of these function sets can exist.
268 The routines in each instance of a subsystem are completely independent
269 of all the routines in other functions sets, making it easy to add new
270 instances of the subsystem.  A new type of primitive geometry,
271 a new display manager, a new database interface, or a new command
272 processor can each be added simply by writing all the routines
273 to implement a new subsystem.
274 This approach greatly simplifies software maintenance, and allows
275 different groups to have responsibility for the
276 creation and enhancement of features within each of the subsystems.
277
278 \chapter{THE COMBINATORIAL GEOMETRY METHODOLOGY}
279
280 \section{Background}
281
282 Since the MGED system is presently based on the COMGEOM solid modeling
283 technique, a brief overview of the COMGEOM technique is required
284 to effectively use MGED.
285 For more detailed information on the COMGEOM technique see
287
288 \begin{figure}[tb]
289 \begin{tabular}{l l}
290 Symbol & Name \\
291 \\
292 ARS & Arbitrary Triangular Surfaced Polyhedron \\
293 ARB & Arbitrary Convex Polyhedron \\
294 ELLG    & General Ellipsoid \\
295 POLY    & Polygonal Faceted Solid \\
296 SPL & Non-Uniform Rational B-Spline (NURB) \\
297 TGC & Truncated General Cone \\
298 TOR & Torus \\
299 HALF    & Half Space (Plane)
300 \end{tabular}
301 \caption{Basic Solid Types \label{list-of-basic-solids} }
302 \end{figure}
303 \begin{figure}[tb]
304 \begin{tabular}{l l}
305 Symbol & Name \\
306 \\
307 RPP & Rectangular Parallelepiped \\
308 BOX & Box \\
309 RAW & Right Angle Wedge \\
310 SPH & Sphere \\
311 RCC & Right Circular Cylinder \\
312 REC & Right Elliptical Cylinder \\
313 TRC & Truncated Right Cylinder \\
314 TEC & Truncated Elliptical Cylinder \\
315 \end{tabular}
316 \caption{Special-Case Solid Types \label{list-of-special-case-solids} }
317 \end{figure}
318 The COMGEOM technique utilizes two basic entities - a solid and a region.
319 A solid is defined as one of fifteen basic geometric shapes or
320 primitives.  Figure \ref{list-of-basic-solids} lists the
321 basic solid types, and Figure \ref{list-of-special-case-solids}
322 lists special cases of the basic solid types for which support exists.
323 The individual parameters of each solid define the solid's
324 location, size, and orientation.  A region is a combination of
325 one or more solids and is defined as the volume occupied
326 by the resulting combination of solids.
327 Solids are combined into regions using any of three logic
328 operations: union (OR), intersection (+), or difference (-).
329 The union of two solids is defined as the volume in either
330 of the solids.
331 The difference of two solids is defined as the volume of the first
332 solid minus the volume of the second solid.
333 The intersection of two solids is defined as the volume
334 common to both solids.
335 %%% XXX Figure 1 presents a graphical representation of these operations.
336
337 Any number of solids may be combined to produce a region.
338 As far as the COMGEOM technique is concerned, only a region can
339 represent an actual component of the model.
340 Regions are homogeneous;  they are composed of a single material.
341 Each region represents a single object in the model;
342 the solids are only building blocks which are combined to
343 define the {\em shape} of the regions.
344 Since regions represent the components of the model, they
345 are further identified by code numbers.
346 These code numbers either identify the region as
347 a model component (nonzero item code)
348 or as air (nonzero air code).
349 Any volume not defined as a region is assumed to be universal air'' and
350 is given an air code of 01''.
351 If it is necessary to distinguish between universal 01'' air and any
352 other kind of air, then that volume must be defined as a region
353 and given an air code other than 01''.
354 Normally, regions cannot occupy the same volume (overlap),
355 but regions identified with
356 air codes can overlap with any region identified as a component
357 (i.e. one that has a nonzero item code).
358 Regions identified with different air codes, however, can not overlap.
359
360 \section{Directed Acyclic Graph and Database Details}
361
362 One of the critical aspects of a graphics software package
363 is its internal data structure.
364 Since geometric models often result
365 in very large volumes of data being generated,
366 the importance of the data structure here is emphasized.
367 Thus it is felt that a brief introduction to the
368 organization of the MGED database is
369 important for all users.
370
371 The database is stored as a single,
372 binary, direct-access
373 UNIX file for efficiency and cohesion,
374 with fixed length records called database {\em granules}.
375 Each object occupies one or more granules of storage.
376 The user sees and manipulates the directed acyclic graphs
377 like UNIX paths (e.g., car/chassis/door),
378 but in a global namespace.
379 There can be many independent or semi-independent
380 directed acyclic graphs within the same database,
381 each defining different models.
382 The figure also makes heavy use of the {\em instancing} capability.
383 As mentioned earlier, the
384 {\em leaves} of the graph are the primitive solids.
385
386 Commands exist to import sub-trees from other databases and libraries,
387 and to export sub-trees to other databases.
388 Also, converters exist to dump databases in printable form for
389 non-binary interchange.
390
391 \section{Model Building Philosophy}
392
393 The power of a full directed acyclic graph structure for representing
394 the organization of the database gives a designer a great deal of
395 flexibility in structuring a model.
396 In order to prevent chaos, most designers at BRL choose to
397 design the overall structure of their model in a top-down manner,
398 selecting meaningful names for the major structures and sub-structures
399 within the model.
400 Actual construction of the details of the
401 model generally proceeds in a bottom-up
402 manner, where each sub-system is fabricated from component primitives.
403
404 The first sub-systems to be constructed are the chassis and skin of the
405 vehicle, after which a set of analyses are run to validate the geometry,
406 checking for unintentional gaps in the skin or for solids which overlap.
407 The second stage of model construction is to build the features of the
408 main compartments of the vehicle.  If necessary for the analysis
409 codes that will be used, the different types of air compartments within
410 the model also need to be described.
411 The final stage of model construction is to build the internal
412 objects to the desired level of detail.
413 This might include modeling engines, transmissions, radios,
414 people, seats, etc.
415 In this stage of modeling, the experienced designer will draw heavily on the
416 parts-bin of model components and on pieces extracted from earlier
417 models, modifying those existing structures to meet his particular
418 requirements.
419
420 Throughout the model building process it is important for the model builder
421 to choose part names carefully, as the MGED database currently has a
422 global name space, with individual node names limited to 16 characters.
423 In addition, BRL has defined conventions for naming the elements in the
424 top three levels of database structure,
425 allowing people to
426 easily navigate within models prepared at
427 different times by different designers.
428 This naming convention
429 facilitates the integration of design changes into existing models.
430
431 \chapter{THE BASIC EDITING PROCESS}
432
433 \section{Interaction Forms}
434
435 Textual and numeric interaction with the MGED editor is the most
436 precise editing paradigm because it allows exact
437 manipulation of known configurations.
438 This works well when the user is designing the model
439 from an existing drawing, or when all dimensions are known (or are computable)
441
442 The use of a
443 tablet or mouse, knob-box or dial-box, buttons, and a joystick
445 Direct graphic interaction via a point-push-pull'' editing paradigm
446 tends to be better for
447 prototyping, developing arbitrary geometry, and fitting
448 together poorly specified configurations.
449 Having both types of interaction capability available at all times
450 allows the user to select the style of interaction that best
451 meets his immediate requirements.
452
453 \section{The Faceplate}
454
455 \begin{figure}
456 \centering \includegraphics{faceplate.ps}
457 \caption{The MGED Editor Faceplate.}
458 \label{faceplate}
459 \end{figure}
460
461 \begin{figure}
465 \end{figure}
466
467 When the MGED program has a display device attached, it
468 displays a border around the region of the screen being used
469 along with some ancillary status information.  Together, this
470 information is termed the editor faceplate''.
471 See Figure \ref{faceplate}.
472 In the upper left corner of the display is a small enclosed area
473 which is used to display the current editor state;
474 this is discussed further in the Editor States section, below.
475
476 Underneath the state display is a zone in which three pop-up'' menus
477 may appear.
478 The top menu is termed the button menu,'' as it
479 contains menu items which duplicate many of the functions assigned to
480 the button box.
481 Having these frequently used
482 functions available on a pop-up menu
483 can greatly decrease the number of times that the user needs to remove
484 his hand from the pointing device (either mouse or tablet puck)
485 to reach for the buttons.
486 An example of the faceplate and first level menu is shown in
488 The second menu is used primarily for the various editing states,
489 at which time it contains all the editing operations which are generic
490 across all objects (scaling, rotation, and translation).
491 The third menu contains selections for object-specific editing operations.
492 The choices on these menus are detailed below.
493
494 It is important to note that while some display hardware that MGED runs on
495 has inherent support for pop-up menus included, MGED does not
496 presently take advantage of that support, preferring to depend
498 It is not clear whether the slight increase in functionality that might
499 accrue from using display-specific menu capabilities would offset the
500 slight nuisance of a non-uniform user interface.
501
502 Running across the entire bottom of the faceplate is a thin rectangular
503 display area which holds two lines of text.
504 The first line always contains a numeric display of the model-space
505 coordinates of the center of the view and the current size of
506 the viewing cube, both in the currently selected editing units.
507 The first line also contains the current rotation rates.
508 The second line has several uses, depending on editor mode.
509 Normally it displays the formal name of the database that is being
510 edited, but in various editing states this second line will instead
511 contain certain path selection information.
512 When the angle/distance cursor function is activated, the second
513 line will be used to display the current settings of the cursor.
514
515 It is important to mention that while the database records all
516 data in terms of the fixed base unit of millimeters, all numeric interaction between
518 The user may select from millimeters, centimeters, meters, inches, and
519 feet, and the currently active display units are noted in the first
520 display line.
521
522 The concept of the viewing cube'' is an important one.
523 Objects drawn on the screen are clipped in X, Y, and Z, to the size
524 indicated on the first status line.
525 This feature allows extraneous wireframes which are positioned within view
526 in X and Y, but quite far away in the Z direction to not be seen,
527 keeping the display free from irrelevant objects when zooming in.
528 Some display managers can selectively enable and disable Z axis clipping
529 as a viewing aid.
530
531 \section{The Screen Coordinate System}
532
533 \begin{figure}
534 \centering \includegraphics{coord-axes.ps}
535 \caption{The Screen Coordinate System.}
536 \label{coord-axes}
537 \end{figure}
538
539 The MGED editor uses the standard right-handed
540 screen coordinate system,
541 as shown in Figure \ref{coord-axes}.
542 The Z axis is perpendicular to the screen and the positive Z direction is
543 out of the screen.  The directions of positive (+) and negative (-) axis
544 rotations are also indicated.  For these rotations, the Right
545 Hand Rule'' applies:  Point the thumb of the right hand along the direction
546 of +X axis and the other fingers will describe the sense of positive
547 rotation.
548
549 \section{Changing the View}
550
551 At any time in an editing session, the user may add one or more
552 subtrees to the active model space.  If the viewing cube is
553 suitably positioned, the newly added subtrees are drawn on the display.
554 (The reset'' function can always be activated to get the entire active
555 model space into view).
556 The normal mode of operation is for users to work with wireframe
557 displays of the unevaluated primitive solids.  These wireframes can be
558 created from the database very rapidly.
559 \begin{figure}
560 \centering \includegraphics{crod.ps}
561 \caption{An Engine Connecting Rod.}
562 \label{crod}
563 \end{figure}
564
565 \begin{figure}
566 \centering \includegraphics{crod-close.ps}
567 \caption{Close-Up Connecting Rod, Showing Z-clipping.}
568 \label{crod-close}
569 \end{figure}
570
571 On demand, the user can request the calculation of
572 approximate boundary wireframes that account for
573 all of the boolean operations specified along the arcs of the
574 directed acyclic graph in the database.
575 This is a somewhat time consuming process, so it is not used
576 by default, but it is quite reasonable to use whenever the
577 design has reached a plateau.
578 Note that these boundary wireframes are not stored in the database,
579 and are generally used as a visualization aid for the designer.
580 Figure \ref{crod} shows an engine connecting rod.
581 On the left side is the wireframe of the unevaluated primitives
582 that the part is modeled with, and on the right side is the approximate
583 boundary wireframe that results from evaluating the boolean expressions.
584
585 Also, at any time the user can cause any part of the active model space
586 to be dropped from view.
587 This is most useful when joining two complicated subsystems
588 together;  the first would be called up into the active model space,
589 manipulated until ready, and then the second subsystem would also be
591 perhaps to eliminate overlaps or to change positioning tolerances,
592 one of the subassemblies could be dropped from view,
593 and editing could proceed.
594
595 The position, size, and orientation of the viewing cube can be
596 arbitrarily changed during an editing session.
597 The simplest way to change the view is by selecting one of nine
598 built in preset views, which can be accomplished by a simple keyboard
599 command, or by way of a button press or first level menu selection.
600 The view can be rotated and translated to any arbitrary position.
601 The user is given the ability to execute a {\bf save view} button/menu
602 function that attaches the current view to a {\bf restore view} button/menu
603 function.
604
605 The rate of rotation around each of the X, Y, and Z axes
606 can be selected by knob, joystick, or keyboard command.
607 Because the rotation is specified as a rate, the view
608 will continue to rotate about the view center until the rotation
609 rate is returned to zero.
610 (A future version of MGED will permit selection of rate or value
611 operation of the knobs).
612 Similarly, the zoom rate (in or out) can be set by keyboard
613 command or by rotating a control dial.
614 Also, displays with three or more mouse buttons have binary (2x) zoom
615 functions assigned to two of the buttons.
616 Finally, it is possible to set a slew rate to translate the view
617 center along any axis in the current viewing space, selectable
618 either by keyboard command or control dial.
619 In VIEW state, the main mouse button translates the
620 view center;  the button is defined to cause the indicated point to become
621 the center of the view.
622
623 The assignment of zoom and slew functions to the mouse buttons tends to
624 make wandering around in a large model very straightforward.
625 The user uses the binary zoom-out button to get an overall view, then
626 moves the new area for inspection to the center of the view and uses
627 the binary zoom-in button to obtain a close up'' view.
628 Figure \ref{crod-close}
629 shows such a close up view of the engine connecting rod.
630 Notice how the wireframe is clipped in the Z viewing direction
631 to fit within the viewing cube.
632
634
635 In order to assist the user in creating and manipulating a complicated
636 hierarchical model structure, there is a whole family of editor commands
637 for examining and searching the database.
638 In addition, on all keyboard commands, UNIX-style regular-expression
639 pattern matching, such as *axle*'' or wheel[abcd]'', can be used.
641 of the node names used in the model.  If no parameters are specified,
642 all names in the model are printed,
643 otherwise only those specified are printed.
644 The names of solids are printed unadorned, while the names of combination
645 (non-terminal) nodes are printed with a slash (/'') appended to them.
646
647 If the user is interested in obtaining detailed information about the
648 contents of a node, the list ({\bf l}) command will provide it.
649 For combination (non-terminal) nodes, the information about all departing
650 arcs is printed, including the names of the nodes referenced, the boolean
651 expressions being used, and an indication of any translations and rotations
652 being applied.
653 For leaf nodes, the primitive solid-specific describe yourself''
654 function is invoked, which provides a formatted display of the parameters
655 of that solid.
656
657 The {\bf tops} command is used to find the names of all nodes which are
658 not referenced by any non-terminal nodes;  such nodes are either
659 unattached leaf nodes, or tree tops.
660 To help visualize the tree structure of the database,
661 the {\bf tree} command exists to
662 print an approximate representation of the database subtree below the
663 named nodes.
664 The {\bf find} command can be used to find the names of all non-terminal
665 nodes which reference the indicated node name(s).  This can be very helpful
666 when trying to decide how to modify an existing model.
667 A related command ({\bf paths}) finds the full tree path specifications
668 which contain a specified graph fragment, such as car/axle/wheel''.
669 In addition to these commands, several more commands exist
670 to support specialized types of searching through the model database.
671
672 \section{Editor States}
673
674 The MGED editor operates in one of six states.
675 Either of the two PICK states can be entered by button press,
676 menu selection, or keyboard command.  The selection of the desired
677 object can be made either by using {\em illuminate mode}, or by
678 keyboard entry of the name of the object.
679
680 Illuminate mode is arranged such that if there are {\bf n} objects visible on
681 the screen, then the screen is divided into {\bf n} horizontal bands.
682 By moving the cursor (via mouse or tablet) up and down through these bands,
683 the user will cause each solid in turn to be highlighted on the screen,
684 with the solid's name displayed in the faceplate.
685 The center mouse button is pressed when the desired solid is located, causing
686 a transition to the next state (Object Path, or Solid Edit).
687
688 Illuminate mode offers significant advantages over more conventional pointing
689 methods when the desired object lies in a densely populated region of the
690 screen.  In such cases, pointing methods have a high chance of making an
691 incorrect selection.
692 However, in sparsely populated regions of the screen, a pointing paradigm
693 would be more convenient, and future versions of MGED will support this.
694
695 \section{Model Units}
696
697 All databases start with an ident'' record which contains
698 a title string that identifies the model, the
699 current local units (e.g., mm, cm or inches) of the model,
700 and a database version identification number.
701 As noted, all numerical information
702 in the database is stored in the fixed base
703 unit of millimeters,
704 and all work (input and output) is done in a user-selected local unit.
705 The user can change his local unit at any time
706 by using the {\bf units} command.
707 This way of handling units was selected to free the user from worrying
708 about units conversion when components are drawn from the parts bin''.