"Fossies" - the Fresh Open Source Software Archive

Member "brlcad-7.32.4/doc/mged/a.tex" (29 Jul 2021, 31651 Bytes) of package /linux/misc/brlcad-7.32.4.tar.bz2:

    1 \title{\bf{\huge{
    2 DRAFT *** DRAFT *** DRAFT \\
    3 Users Manual for \\
    4 BRL-CAD Graphics Editor \\
    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
   68 For Targets (GIFT)
   69 \cite{gift1,gift2}
   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
  122 being made in the BRL-CAD software.
  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
  286 \cite{gift1,gift2}.
  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)
  440 in advance.
  441 
  442 The use of a
  443 tablet or mouse, knob-box or dial-box, buttons, and a joystick
  444 are all simultaneously supported by MGED for analog inputs.
  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}
  462 \centering \includegraphics{buttonmenu.ps}
  463 \caption{The Pop-Up Button Menu.}
  464 \label{buttonmenu}
  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
  487 Figure \ref{buttonmenu}.
  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
  497 on the portable menu system within MGED instead.
  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
  517 the user and the editor are in terms of user-selected display [or local] units.
  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
  590 called up as well.  When any necessary adjustments had been made,
  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 
  633 \section{Model Navigation}
  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.
  640 The simplest editor command ({\bf t}) prints a table of contents, or directory,
  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''.