[brlcad-commits] SF.net SVN: brlcad:[32760] brlcad/trunk/doc/docbook
Open Source Solid Modeling CAD
Brought to you by:
brlcad
From: <sta...@us...> - 2008-09-25 04:16:04
|
Revision: 32760 http://brlcad.svn.sourceforge.net/brlcad/?rev=32760&view=rev Author: starseeker Date: 2008-09-25 04:15:41 +0000 (Thu, 25 Sep 2008) Log Message: ----------- Add books and articles to docbook Added Paths: ----------- brlcad/trunk/doc/docbook/articles/ brlcad/trunk/doc/docbook/articles/Makefile.am brlcad/trunk/doc/docbook/articles/build_pattern/ brlcad/trunk/doc/docbook/articles/build_pattern/build_pattern.xml brlcad/trunk/doc/docbook/articles/build_pattern/build_pattern_images/ brlcad/trunk/doc/docbook/articles/build_pattern/build_pattern_images/figure1.png brlcad/trunk/doc/docbook/articles/build_pattern/build_pattern_images/figure2.png brlcad/trunk/doc/docbook/articles/build_pattern/build_pattern_images/figure3.png brlcad/trunk/doc/docbook/articles/build_pattern/build_pattern_images/figure4.png brlcad/trunk/doc/docbook/articles/build_pattern/build_pattern_images/figure5.png brlcad/trunk/doc/docbook/articles/build_pattern/build_pattern_images/figure6.png brlcad/trunk/doc/docbook/articles/build_pattern/build_pattern_images/inline1.png brlcad/trunk/doc/docbook/articles/build_region/ brlcad/trunk/doc/docbook/articles/build_region/build_region.xml brlcad/trunk/doc/docbook/articles/build_region/build_region_images/ brlcad/trunk/doc/docbook/articles/build_region/build_region_images/figure1.png brlcad/trunk/doc/docbook/articles/build_region/build_region_images/figure2.png brlcad/trunk/doc/docbook/articles/build_region/build_region_images/figure3.png brlcad/trunk/doc/docbook/articles/build_region/build_region_images/figure4.png brlcad/trunk/doc/docbook/articles/ebm_primitive/ brlcad/trunk/doc/docbook/articles/ebm_primitive/ebm_primitive.xml brlcad/trunk/doc/docbook/articles/ebm_primitive/ebm_primitive_images/ brlcad/trunk/doc/docbook/articles/ebm_primitive/ebm_primitive_images/figure1.png brlcad/trunk/doc/docbook/articles/ebm_primitive/ebm_primitive_images/figure2.png brlcad/trunk/doc/docbook/articles/ebm_primitive/ebm_primitive_images/figure3.png brlcad/trunk/doc/docbook/articles/mgedrc/ brlcad/trunk/doc/docbook/articles/mgedrc/mgedrc.xml brlcad/trunk/doc/docbook/articles/mgedrc/mgedrc_images/ brlcad/trunk/doc/docbook/articles/mgedrc/mgedrc_images/figure2.png brlcad/trunk/doc/docbook/articles/mgedrc/mgedrc_images/figure3.png brlcad/trunk/doc/docbook/articles/oed/ brlcad/trunk/doc/docbook/articles/oed/Makefile.am brlcad/trunk/doc/docbook/articles/oed/README brlcad/trunk/doc/docbook/articles/oed/lollipop.png brlcad/trunk/doc/docbook/articles/oed/oed.xml brlcad/trunk/doc/docbook/articles/oed/oed_0001.png brlcad/trunk/doc/docbook/articles/oed/oed_0002.png brlcad/trunk/doc/docbook/articles/oed/oed_0003.png brlcad/trunk/doc/docbook/articles/oed/oed_0004.png brlcad/trunk/doc/docbook/articles/oed/oed_0005.png brlcad/trunk/doc/docbook/articles/oed/oed_0006.png brlcad/trunk/doc/docbook/articles/oed/oed_0007.png brlcad/trunk/doc/docbook/articles/oed/oed_0008.png brlcad/trunk/doc/docbook/articles/oed/oed_0009.png brlcad/trunk/doc/docbook/articles/oed/oed_0010.png brlcad/trunk/doc/docbook/articles/oed/oed_0011.png brlcad/trunk/doc/docbook/articles/oed/oed_0012.png brlcad/trunk/doc/docbook/articles/oed/oed_examples.asc brlcad/trunk/doc/docbook/articles/pipes/ brlcad/trunk/doc/docbook/articles/pipes/pipe_images/ brlcad/trunk/doc/docbook/articles/pipes/pipe_images/figure1.png brlcad/trunk/doc/docbook/articles/pipes/pipe_images/figure2.png brlcad/trunk/doc/docbook/articles/pipes/pipe_images/figure3.png brlcad/trunk/doc/docbook/articles/pipes/pipe_images/figure4.png brlcad/trunk/doc/docbook/articles/pipes/pipe_images/figure5.png brlcad/trunk/doc/docbook/articles/pipes/pipe_images/inline1.png brlcad/trunk/doc/docbook/articles/pipes/pipe_images/inline2.png brlcad/trunk/doc/docbook/articles/pipes/pipe_images/inline3.png brlcad/trunk/doc/docbook/articles/pipes/pipe_images/inline4.png brlcad/trunk/doc/docbook/articles/pipes/pipe_images/inline5.png brlcad/trunk/doc/docbook/articles/pipes/pipe_images/inline6.png brlcad/trunk/doc/docbook/articles/pipes/pipe_images/inline7.png brlcad/trunk/doc/docbook/articles/pipes/pipe_images/inline8.png brlcad/trunk/doc/docbook/articles/pipes/pipes.xml brlcad/trunk/doc/docbook/articles/projection_shader/ brlcad/trunk/doc/docbook/articles/projection_shader/projection_shader.xml brlcad/trunk/doc/docbook/articles/projection_shader/projection_shader_images/ brlcad/trunk/doc/docbook/articles/projection_shader/projection_shader_images/figure1.png brlcad/trunk/doc/docbook/articles/projection_shader/projection_shader_images/figure2.png brlcad/trunk/doc/docbook/articles/projection_shader/projection_shader_images/figure3.png brlcad/trunk/doc/docbook/articles/projection_shader/projection_shader_images/figure4.png brlcad/trunk/doc/docbook/articles/projection_shader/projection_shader_images/figure5.png brlcad/trunk/doc/docbook/articles/projection_shader/projection_shader_images/figure6.png brlcad/trunk/doc/docbook/articles/projection_shader/projection_shader_images/figure7.png brlcad/trunk/doc/docbook/articles/tire/ brlcad/trunk/doc/docbook/articles/tire/README brlcad/trunk/doc/docbook/articles/tire/tire.xml brlcad/trunk/doc/docbook/articles/tire/tire_0001.png brlcad/trunk/doc/docbook/articles/tire/tire_0002.png brlcad/trunk/doc/docbook/articles/tire/tire_0003.png brlcad/trunk/doc/docbook/articles/tire/tire_0004.png brlcad/trunk/doc/docbook/articles/tire/tire_0005.png brlcad/trunk/doc/docbook/articles/tire/tire_0006.png brlcad/trunk/doc/docbook/articles/tire/tire_0007.png brlcad/trunk/doc/docbook/articles/tire/tire_0008.png brlcad/trunk/doc/docbook/articles/tire/tire_0009.png brlcad/trunk/doc/docbook/articles/tire/tire_0010.png brlcad/trunk/doc/docbook/articles/tire/tire_0011.png brlcad/trunk/doc/docbook/articles/tire/tire_0012.png brlcad/trunk/doc/docbook/articles/tire/tire_0012.svg brlcad/trunk/doc/docbook/articles/tire/tire_0013.png brlcad/trunk/doc/docbook/articles/tire/tire_0013.svg brlcad/trunk/doc/docbook/articles/tire/tire_0014.png brlcad/trunk/doc/docbook/books/ brlcad/trunk/doc/docbook/books/Makefile.am brlcad/trunk/doc/docbook/books/README brlcad/trunk/doc/docbook/books/tutorial_series/ brlcad/trunk/doc/docbook/books/tutorial_series/Makefile.am brlcad/trunk/doc/docbook/books/tutorial_series/VolumeII.xml brlcad/trunk/doc/docbook/books/tutorial_series/VolumeIII.xml brlcad/trunk/doc/docbook/books/tutorial_series/book_authors.xml brlcad/trunk/doc/docbook/books/tutorial_series/volumeIII_images/ brlcad/trunk/doc/docbook/books/tutorial_series/volumeIII_images/figure1.png brlcad/trunk/doc/docbook/books/tutorial_series/volumeIII_images/figure10.png brlcad/trunk/doc/docbook/books/tutorial_series/volumeIII_images/figure11.png brlcad/trunk/doc/docbook/books/tutorial_series/volumeIII_images/figure12.png brlcad/trunk/doc/docbook/books/tutorial_series/volumeIII_images/figure13.png brlcad/trunk/doc/docbook/books/tutorial_series/volumeIII_images/figure14.png brlcad/trunk/doc/docbook/books/tutorial_series/volumeIII_images/figure15.png brlcad/trunk/doc/docbook/books/tutorial_series/volumeIII_images/figure16.png brlcad/trunk/doc/docbook/books/tutorial_series/volumeIII_images/figure17.png brlcad/trunk/doc/docbook/books/tutorial_series/volumeIII_images/figure18.png brlcad/trunk/doc/docbook/books/tutorial_series/volumeIII_images/figure19.png brlcad/trunk/doc/docbook/books/tutorial_series/volumeIII_images/figure2.png brlcad/trunk/doc/docbook/books/tutorial_series/volumeIII_images/figure3.png brlcad/trunk/doc/docbook/books/tutorial_series/volumeIII_images/figure4.png brlcad/trunk/doc/docbook/books/tutorial_series/volumeIII_images/figure5.png brlcad/trunk/doc/docbook/books/tutorial_series/volumeIII_images/figure6.png brlcad/trunk/doc/docbook/books/tutorial_series/volumeIII_images/figure7.png brlcad/trunk/doc/docbook/books/tutorial_series/volumeIII_images/figure8.png brlcad/trunk/doc/docbook/books/tutorial_series/volumeIII_images/figure9.png brlcad/trunk/doc/docbook/books/tutorial_series/volumeIII_images/inline1.png brlcad/trunk/doc/docbook/books/tutorial_series/volumeIII_images/inline2.png brlcad/trunk/doc/docbook/books/tutorial_series/volumeIII_images/inline3.png brlcad/trunk/doc/docbook/books/tutorial_series/volumeIII_images/invalidarbs.png brlcad/trunk/doc/docbook/books/tutorial_series/volumeIII_images/primitive1.png brlcad/trunk/doc/docbook/books/tutorial_series/volumeIII_images/primitive2.png brlcad/trunk/doc/docbook/books/tutorial_series/volumeIII_images/primitive3.png brlcad/trunk/doc/docbook/books/tutorial_series/volumeIII_images/primitive4.png brlcad/trunk/doc/docbook/books/tutorial_series/volumeIII_images/primitive5.png brlcad/trunk/doc/docbook/books/tutorial_series/volumeIII_images/primitive6.png Added: brlcad/trunk/doc/docbook/articles/Makefile.am =================================================================== --- brlcad/trunk/doc/docbook/articles/Makefile.am (rev 0) +++ brlcad/trunk/doc/docbook/articles/Makefile.am 2008-09-25 04:15:41 UTC (rev 32760) @@ -0,0 +1,4 @@ + +SUBDIRS = oed + +include $(top_srcdir)/misc/Makefile.defs Property changes on: brlcad/trunk/doc/docbook/articles/Makefile.am ___________________________________________________________________ Added: svn:mime-type + text/plain Added: svn:eol-style + native Added: brlcad/trunk/doc/docbook/articles/build_pattern/build_pattern.xml =================================================================== --- brlcad/trunk/doc/docbook/articles/build_pattern/build_pattern.xml (rev 0) +++ brlcad/trunk/doc/docbook/articles/build_pattern/build_pattern.xml 2008-09-25 04:15:41 UTC (rev 32760) @@ -0,0 +1,300 @@ +<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" +"../../resources/standard/dtd/docbookx.dtd"> +<article xmlns:xi="http://www.w3.org/2001/XInclude"> + <articleinfo> + <title>Using the Pipe Primitive</title> + + <xi:include href="../../books/tutorial_series/book_authors.xml" xpointer="Intro_MGED_Tutorial_Series_III_authors"/> + + <legalnotice> + <para>Approved for public release; distribution is unlimited</para> + </legalnotice> + </articleinfo> + + <sect1 id="build_pattern_generalinfo"> + <title>General Pattern Information</title> + <para> + As mentioned previously, the Build Pattern tool automates the process of + making copies of existing geometry in rectangular, spherical, or + cylindrical patterns. The user can choose to pattern at any of three + depths of duplication: top, regions, and primitives. + </para> + <para> + The Build Pattern tool is run from the graphical user interface (GUI) + (under the Tools menu); it currently has no command-line equivalent. The + bottom of the pattern control GUI is a usage dialog box that lists + pertinent information about each item on the GUI as the user mouses over + the text. + </para> + <para> + There are many input fields. Some stand alone, and others belong to series + that work together to provide the needed information for a specific + option. Each series is demarked by a diamond-shaped check box. If the + diamond is highlighted red, then all fields in that series are required. + All required fields must be filled in for the pattern tool to work + properly. It is also important to note that all dimensions must be in + millimeters and that no commas should be used in number strings. + </para> + <para> + The Build Pattern tool is designed to work from a prototype geometry + object. That is to say, the object that is patterned is not included in + the resultant pattern. + </para> + </sect1> + + <sect1 id="build_pattern_names"> + <title>Pattern Names</title> + <para> + As shown in Figure E-1, the tool appends three numbers to all patterned + objects (unless you are using the increment option for primitives, in + which case, the numbers for regions and primitives are incremented by the + increment amount). For rectangular patterns, the first number is the + X axis offset, the second is the Y axis offset, and the third is the Z + axis offset. For spherical patterns, the first number references the + azimuth, the second references the elevation, and the third references the + radii. For cylindrical patterns, the first number references the radii, + the second number references the height, and the third number references + the azimuth. + </para> + </sect1> + + <sect1 id="build_pattern_fields"> + <title>Common Fields for all Patterns:</title> + <para> + There are several fields in the pattern tool GUI that are common to all + types of patterns. + </para> + <para> + The Group Name field is for the name of the combination to be created (or + appended to) by a pattern call. + </para> + <para> + The Source String and Replacement String fields must be used together. The + source string is the set of characters in each element of the patterned + object to be changed. The replacement string is the set of characters that + will replace the source string. + </para> + + <figure> + <title>Example of pattern-generated assembly names.</title> + <mediaobject> + <imageobject> + <imagedata align = "center" fileref="../../tutorials/build_pattern/build_pattern_images/figure1.png" format="PNG"></imagedata> + </imageobject> + </mediaobject> + </figure> + + <para> + The Increment field is only for use when duplicating to the primitive level. + It is added to the leftmost number field of each primitive. To determine the + increment, examine the primitives of the object(s) you wish to pattern and find + the largest span. For example, to create a pattern to the primitive level with + the following primitives (which may or may not be in regions or + assemblies), + <literallayout> +part.s22 part.s22-1 part.s23 part.s24 part.s24+1 part.s24-1 part.s25, + </literallayout> + one needs to determine the span. Note that the leftmost numbers in these + primitives range from 22–25. Thus, as shown in the following expression, the span is + four (inclusively). + + *******NEED FIGURE HERE***** + + If we use an increment of four, we will get the following set of primitives. + <literallayout> +part.s26 part.s26-1 part.s27 part.s28 part.s28+1 part.s28-1 part.s29 + </literallayout> + + Although it is acceptable to use a greater increment, gaps in numbers may be + troublesome if one is using this capability extensively. + </para> + + <para> + Finally, the Objects field is used for the names of all the items to be + patterned. + </para> + </sect1> + + <sect1 id="build_pattern_stringsub"> + <title>String Substitution</title> + <para> + It is also possible to create a pattern in which a string of characters in + each element in the object is changed (e.g., "l_" -> "r_"). This is useful + for symmetry applications (e.g., left - right) or series (e.g., 1 - n). + Each element of the object must have the source string so the user must be + thorough and name each primitive, region, and assembly properly. Consider + the following example: + <inlinegraphic fileref="../../tutorials/build_pattern/build_pattern_images/inline1.png" /> + </para> + <para> + Top-level duplications copy the patterned object and reference its entire + structure with matrices, as follows: + <literallayout> +/pattern group + /COPIED assemblies [MATRICES] + /assemblies + /regions + /primitives + </literallayout> + + Region-level duplications copy all assembly and regions and reference from the + region level down with matrices. + + <literallayout> +/pattern group + /COPIED assemblies + /COPIED regions [MATRICES] +/primitives + </literallayout> + + Primitive-level duplications copy the entire tree structure to the primitive + level without matrices using an increment on all primitives. + + <literallayout> +/pattern group + /COPIED assemblies NO MATRICES + /COPIED regions + /COPIED primitives + </literallayout> + </para> + + </sect1> + + <sect1 id="build_pattern_recpatterns"> + <title>Rectangular Patterns</title> + <para> + The rectangular pattern GUI (shown in Figure E-2) is designed to + facilitate one-, two-, or three-dimensional rectangular patterns. The + default X, Y, and Z directions are positive along each axis. In order to + create a rectangle that is not axis aligned, these vectors may be changed + with the condition that each must remain precisely perpendicular to the + other two. If the Use Directions series is checked, the user specifies the + number of copies and the Delta between copies for each axis. If the Use + Lists series is checked, the user can specify a list of deltas along each + axis. + </para> + + <figure> + <title>The user interface for building rectangular patterns.</title> + <mediaobject> + <imageobject> + <imagedata align = "center" fileref="../../tutorials/build_pattern/build_pattern_images/figure2.png" format="PNG"></imagedata> + </imageobject> + </mediaobject> + </figure> + + </sect1> + + <sect1 id="build_pattern_spherical"> + <title>Spherical Patterns</title> + <para> + The spherical pattern GUI (shown in Figure E-3) facilitates sphere-shaped + patterns rotated around a center vertex using user-specified radii with + azimuth and elevation angles. As shown in Figure E-4, the patterned + objects--in this case, a series of arrows--may be oriented as built around + the sphere or rotated by azimuth and/or elevation such that they are + oriented toward the pattern center using the Rotate Azimuth and Rotate + Elevation check boxes. + </para> + + <para> + As shown in Figure E-4, the Pattern Center field is the coordinate at the + center of the pattern. The Object Center field is a user-defined + coordinate used to locate the object(s) relative to the pattern center. It + acts as the key point for any transformations to the pattern object(s). + </para> + + <para> + The Starting Azimuth and Starting Elevation fields follow the same + right-hand-rule Cartesian coordinate conventions as Multi-Device Geometry + Editor (MGED) viewing. The Starting Radius is the distance from the + Pattern Center to the object center at the user-specified azimuths and + elevations. + </para> + + <para> + If the Create Az/El series is checked, the user defines the number of + azimuths and elevations and the deltas between each. If the Use Lists + series is checked, the user must specify a list of azimuths and/or + elevations. + </para> + + <para> + The Create Radii and Use Radii List series define offsets from the + Starting Radius, allowing the user to create a pattern of concentric + spheres. If Create Radii is checked, the user specifies + the Number of Radii and the Radius Delta in order to construct a number of + equally offset sphere patterns. If the Use Radii List is checked, the user + specifies a list of radius offsets. + </para> + + <figure> + <title>The user interface for building spherical patterns.</title> + <mediaobject> + <imageobject> + <imagedata align = "center" fileref="../../tutorials/build_pattern/build_pattern_images/figure3.png" format="PNG"></imagedata> + </imageobject> + </mediaobject> + </figure> + + <para> + Without the Rotate Azimuth or Rotate Elevation boxes checked, the + patterned objects are oriented as built without any rotations. Notice, for + example, that every arrow in Figure E-5 points to the left. Notice also + that for each patterned arrow, the Object Center (here specified as the + tip of the arrow) is located on the circle outline at a distance of one + Starting Radius from the Pattern Center. If we set the Object Center to + the coordinate at the base of the arrow, the base would then lie on the + circular outline. Wherever the Object Center is set is the point at which + MGED works with the Object Center coordinate to place and rotate patterned + objects. + </para> + + + <figure> + <title>Examples of different spherical pattern orientations.</title> + <mediaobject> + <imageobject> + <imagedata align = "center" fileref="../../tutorials/build_pattern/build_pattern_images/figure4.png" format="PNG"></imagedata> + </imageobject> + </mediaobject> + </figure> + + + <figure> + <title>Implementation of spherical patterns.</title> + <mediaobject> + <imageobject> + <imagedata align = "center" fileref="../../tutorials/build_pattern/build_pattern_images/figure5.png" format="PNG"></imagedata> + </imageobject> + </mediaobject> + </figure> + + </sect1> + + <sect1 id="build_pattern_cylind"> + <title>Cylindrical Patterns</title> + <para> + The cylindrical pattern GUI (shown in Figure E-6) facilitates the creation + of cylinder-shaped patterns with user-defined center, direction, height, + azimuth, and radii inputs. The Base Center is the vertex of the cylinder + shape. The Object Center is a user-defined coordinate used to locate the + object(s) relative to the Base Center and Height Direction. It acts as the + key point for any transformations to the pattern object(s). The Height + Direction is the vector along which the cylinder runs. The Starting Height + is the offset from the Base Center along the Height Direction that the + pattern will place the Object Center. + </para> + + <figure> + <title>The user interface for building cylindrical patterns.</title> + <mediaobject> + <imageobject> + <imagedata align = "center" fileref="../../tutorials/build_pattern/build_pattern_images/figure6.png" format="PNG"></imagedata> + </imageobject> + </mediaobject> + </figure> + + </sect1> + +</article> Property changes on: brlcad/trunk/doc/docbook/articles/build_pattern/build_pattern.xml ___________________________________________________________________ Added: svn:mime-type + text/plain Added: svn:eol-style + native Property changes on: brlcad/trunk/doc/docbook/articles/build_pattern/build_pattern_images/figure1.png ___________________________________________________________________ Added: svn:mime-type + application/octet-stream Property changes on: brlcad/trunk/doc/docbook/articles/build_pattern/build_pattern_images/figure2.png ___________________________________________________________________ Added: svn:mime-type + application/octet-stream Property changes on: brlcad/trunk/doc/docbook/articles/build_pattern/build_pattern_images/figure3.png ___________________________________________________________________ Added: svn:mime-type + application/octet-stream Property changes on: brlcad/trunk/doc/docbook/articles/build_pattern/build_pattern_images/figure4.png ___________________________________________________________________ Added: svn:mime-type + application/octet-stream Property changes on: brlcad/trunk/doc/docbook/articles/build_pattern/build_pattern_images/figure5.png ___________________________________________________________________ Added: svn:mime-type + application/octet-stream Property changes on: brlcad/trunk/doc/docbook/articles/build_pattern/build_pattern_images/figure6.png ___________________________________________________________________ Added: svn:mime-type + application/octet-stream Property changes on: brlcad/trunk/doc/docbook/articles/build_pattern/build_pattern_images/inline1.png ___________________________________________________________________ Added: svn:mime-type + application/octet-stream Added: brlcad/trunk/doc/docbook/articles/build_region/build_region.xml =================================================================== --- brlcad/trunk/doc/docbook/articles/build_region/build_region.xml (rev 0) +++ brlcad/trunk/doc/docbook/articles/build_region/build_region.xml 2008-09-25 04:15:41 UTC (rev 32760) @@ -0,0 +1,143 @@ +<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" +"../../resources/standard/dtd/docbookx.dtd"> +<article xmlns:xi="http://www.w3.org/2001/XInclude"> + <articleinfo> + <title>Using the build_region Command</title> + + <xi:include href="../../books/tutorial_series/book_authors.xml" xpointer="Intro_MGED_Tutorial_Series_III_authors"/> + + <legalnotice> + <para>Approved for public release; distribution is unlimited</para> + </legalnotice> + </articleinfo> + + <para id="build_region1"> + Just as the Build Pattern tool can help automate the process of building + multiple occurrences of objects, the build_region command can help + automate the process of creating regions. The command (which currently has + no graphical user interface equivalent) uses meaning assigned by the user + in the primitive name based on the intended use of the primitive. + </para> + + <para id="build_region2"> + The user includes the Boolean operation and relational information in the + name of the primitive using a simple naming convention. The naming + convention is designed around the following two assumptions: + </para> + + <itemizedlist id="build_region3"> + <listitem> + <para> + The same text "tag" is used for all primitives in a region. + </para> + </listitem> + <listitem> + <para> + A sequential numbering pattern is used. + </para> + </listitem> + </itemizedlist> + + <para id="build_region4"> + For example, let's say we want to build the four rounded corners of a + "tub" region for a toy metal wagon assembly (see Figure F-1). We could + choose something such as "wgn"--an abbreviated form of "wagon"--as the + tag. This tag is short, easy to type, and representative of the final + assembly name. Our primitives would therefore be of the form wgn.s#. + </para> + + <figure id="build_region5"> + <title>The rounded corners of a toy wagon.</title> + <mediaobject> + <imageobject> + <imagedata align = "center" fileref="../../tutorials/build_region/build_region_images/figure1.png" format="PNG"></imagedata> + </imageobject> + </mediaobject> + </figure> + + <para id="build_region6"> + Next, we create an arb8 for one long side of the wagon tub. It is named + wgn.s1. After that, we create an rcc for one corner of the tub. It is + named wgn.s2. To get a hollow quarter cylinder, we need to subtract a + cylinder and intersect a bounding box (see Figure F-2). In order to relate + the subtraction and intersecting primitives with wgn.s2, they will each + share the same root name, wgn.s2. The subtraction primitive will be named + wgn.s2-1, and the intersecting primitive will be named wgn.s2+1. + </para> + + <figure id="build_region7"> + <title>Arb8, cylinder, and two Boolean primitives.</title> + <mediaobject> + <imageobject> + <imagedata align = "center" fileref="../../tutorials/build_region/build_region_images/figure2.png" format="PNG"></imagedata> + </imageobject> + </mediaobject> + </figure> + + <para id="build_region8"> + Now we have created the following four primitives: + <literallayout> +wgn.s1 wgn.s2 wgn.s2+1 wgn.s2-1 + </literallayout> + If we separate the primitives sequentially as follows, + <literallayout> +wgn.s1 + +wgn.s2 wgn.s2+1 wgn.s2-1, + </literallayout> + we can begin to see the Boolean structure falling out of the naming + convention + <literallayout> +u wgn.s1 + +u wgn.s2 + wgn.s2+1 - wgn.s2-1 + </literallayout> + If we wanted to make a second subtraction from wgn.s2--say, for a drain + hole in the corner of the wagon--we would name that primitive wgn.s2-2 + (see Figure F-3). We can break this name down as follows: + + *****NEED IMAGE HERE***** + </para> + + <figure id="build_region9"> + <title>The region and the subtraction primitives.</title> + <mediaobject> + <imageobject> + <imagedata align = "center" fileref="../../tutorials/build_region/build_region_images/figure3.png" format="PNG"></imagedata> + </imageobject> + </mediaobject> + </figure> + + <para id="build_region10"> + Note that the root name stays the same so we can maintain the + relationship, and the second number (associated with the Boolean + operation) is incremented sequentially. + </para> + + <figure id="build_region11"> + <title>Raytraced image with hole.</title> + <mediaobject> + <imageobject> + <imagedata align = "center" fileref="../../tutorials/build_region/build_region_images/figure4.png" format="PNG"></imagedata> + </imageobject> + </mediaobject> + </figure> + + <para id="build_region12"> + Obviously, the overall success or failure of the build_region command + depends on primitives being named properly. But if they are, the command + can organize them in one automated step, creating complex regions in just + a few keystrokes. + </para> + + <para id="build_region13"> + Another modeling benefit of the build_region tool is that it allows the + user to quickly organize primitives. Assume, for example, that we have + used the aforementioned naming convention to construct a complicated + region. If there was a subsection of the region that we needed to, say, + keep out for another assembly, delete from our database, move slightly, or + copy, it would be a simple matter to create a new region with just those + primitives that we needed. + </para> + +</article> Property changes on: brlcad/trunk/doc/docbook/articles/build_region/build_region.xml ___________________________________________________________________ Added: svn:mime-type + text/plain Added: svn:eol-style + native Property changes on: brlcad/trunk/doc/docbook/articles/build_region/build_region_images/figure1.png ___________________________________________________________________ Added: svn:mime-type + application/octet-stream Property changes on: brlcad/trunk/doc/docbook/articles/build_region/build_region_images/figure2.png ___________________________________________________________________ Added: svn:mime-type + application/octet-stream Property changes on: brlcad/trunk/doc/docbook/articles/build_region/build_region_images/figure3.png ___________________________________________________________________ Added: svn:mime-type + application/octet-stream Property changes on: brlcad/trunk/doc/docbook/articles/build_region/build_region_images/figure4.png ___________________________________________________________________ Added: svn:mime-type + application/octet-stream Added: brlcad/trunk/doc/docbook/articles/ebm_primitive/ebm_primitive.xml =================================================================== --- brlcad/trunk/doc/docbook/articles/ebm_primitive/ebm_primitive.xml (rev 0) +++ brlcad/trunk/doc/docbook/articles/ebm_primitive/ebm_primitive.xml 2008-09-25 04:15:41 UTC (rev 32760) @@ -0,0 +1,116 @@ +<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" +"../../resources/standard/dtd/docbookx.dtd"> +<article xmlns:xi="http://www.w3.org/2001/XInclude"> + <articleinfo> + <title>Using the Extruded Bitmap Primitive</title> + + <xi:include href="../../books/tutorial_series/book_authors.xml" xpointer="Intro_MGED_Tutorial_Series_III_authors"/> + + <legalnotice> + <para>Approved for public release; distribution is unlimited</para> + </legalnotice> + </articleinfo> + + <para id="ebm1"> + The extruded bitmap (ebm) primitive allows the user to make a + three-dimensional (3-D) shape from a two-dimensional black-and-white + image. This feature can be helpful when dealing with complex outlines, + text, or other complicated shapes captured as images. + </para> + + <para id="ebm2"> + For example, the ebm could be used if one wanted to model 3-D letters, + such as in a company name, onto the side of a simulated wall or building. + Note also that the same image used for the projection can, with some extra + processing, form the basis for the ebm (see Figures C-1-C-3). + </para> + + <figure id="ebm3"> + <title>Example of the .bw image used for ebm.</title> + <mediaobject> + <imageobject> + <imagedata align = "center" fileref="../../tutorials/ebm_primitive/ebm_primitive_images/figure1.png" format="PNG"></imagedata> + </imageobject> + </mediaobject> + </figure> + + <figure id="ebm4"> + <title>Example of ebm.</title> + <mediaobject> + <imageobject> + <imagedata align = "center" fileref="../../tutorials/ebm_primitive/ebm_primitive_images/figure2.png" format="PNG"></imagedata> + </imageobject> + </mediaobject> + </figure> + + <figure id="ebm5"> + <title>Example of the ebm with projection shader added.</title> + <mediaobject> + <imageobject> + <imagedata align = "center" fileref="../../tutorials/ebm_primitive/ebm_primitive_images/figure3.png" format="PNG"></imagedata> + </imageobject> + </mediaobject> + </figure> + + <para id="ebm6"> + To make an ebm, the image file must be a black and white (.bw) file. A .bw + image is a grayscale raw image file with only one channel. Each pixel can + be turned on or off, but it has no color data. As shown in Figures C-2 and + C-3, the white part of the image may be extruded in a straight line in the + +Z direction to whatever length the user specifies. Regardless of the + complexity of the geometry, all of the extruded shapes form a single ebm + primitive. + </para> + + <para id="ebm7"> + To enter an ebm in a database, the in command must be used. The arguments + are as shown in the following example: + </para> + + <informaltable frame="all" id="ebm8"> + <tgroup cols='7'> + <tbody> + <row><entry>in</entry><entry>sample.ebm</entry><entry>ebm</entry><entry>image.bw</entry><entry>600</entry><entry>800</entry><entry>1</entry></row> + <row> + <entry>Make a shape.</entry> + <entry>Name it sample.</entry> + <entry>Make it an ebm.</entry> + <entry>Use the image.bw image file.</entry> + <entry>The image is 600 pixels wide.</entry> + <entry>The image is 800 pixels high.</entry> + <entry>Extrude the shape 1 inch (or whatever working units are in effect at the time) in the +Z direction.</entry> + </row> + </tbody> + </tgroup> + </informaltable> + + <note id="ebm9"> + <title>Points to Remember About the ebm</title> + <itemizedlist mark="bullet"> + <listitem> + <para> + The ebm cannot be created with the make, create, or inside + commands. + </para> + </listitem> + <listitem> + <para> + The desired width and height of the ebm are input as pixel + values, but the extrusion distance can be expressed in any + working units. + </para> + </listitem> + <listitem> + <para> + Extrusions are made in the +Z direction, although after an ebm is + made, the shape can be rotated, translated, or scaled. + </para> + </listitem> + <listitem> + <para> + When extruded, all shapes form a single ebm primitive. + </para> + </listitem> + </itemizedlist> + </note> +</article> Property changes on: brlcad/trunk/doc/docbook/articles/ebm_primitive/ebm_primitive.xml ___________________________________________________________________ Added: svn:mime-type + text/plain Added: svn:eol-style + native Property changes on: brlcad/trunk/doc/docbook/articles/ebm_primitive/ebm_primitive_images/figure1.png ___________________________________________________________________ Added: svn:mime-type + application/octet-stream Property changes on: brlcad/trunk/doc/docbook/articles/ebm_primitive/ebm_primitive_images/figure2.png ___________________________________________________________________ Added: svn:mime-type + application/octet-stream Property changes on: brlcad/trunk/doc/docbook/articles/ebm_primitive/ebm_primitive_images/figure3.png ___________________________________________________________________ Added: svn:mime-type + application/octet-stream Added: brlcad/trunk/doc/docbook/articles/mgedrc/mgedrc.xml =================================================================== --- brlcad/trunk/doc/docbook/articles/mgedrc/mgedrc.xml (rev 0) +++ brlcad/trunk/doc/docbook/articles/mgedrc/mgedrc.xml 2008-09-25 04:15:41 UTC (rev 32760) @@ -0,0 +1,261 @@ +<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" +"../../resources/standard/dtd/docbookx.dtd"> +<article xmlns:xi="http://www.w3.org/2001/XInclude"> + <articleinfo> + <title>Setting Up a .mgedrc File</title> + + <xi:include href="../../books/tutorial_series/book_authors.xml" xpointer="Intro_MGED_Tutorial_Series_III_authors"/> + + <legalnotice> + <para>Approved for public release; distribution is unlimited</para> + </legalnotice> + </articleinfo> + + <para id="mgedrc1"> + Similar to the preferences or settings options in other computer + applications, the .mgedrc file is a useful tool to customize the look and + functionality of the U.S. Army Ballistic Research Laboratory - + Computer-Aided Design (BRL-CAD) package and minimize potentially + time-consuming actions. Using Multi-Device Geometry Editor (MGED) commands + and the Tcl/Tk scripting language, users can modify default settings, + specify features to be toggled on or off whenever MGED is started, + establish typing shortcuts for a command or a series of commands, locate + and size the command and geometry windows, and perform a host of other + customizations. + </para> + <para id="mgedrc2"> + The command to create/update a .mgedrc file with the graphical user + interface (GUI) is found under the File drop-down menu. When the + Create/Update .mgedrc command is called, it writes an extensive list (~500 + lines) of default settings and comments representing the default state of + the command and graphics windows. + </para> + <para id="mgedrc3"> + As shown in Figure D-1, there are two basic parts to a .mgedrc file: (1) + the information before the MGEDRC_HEADER and (2) the information after the + MGEDRC_HEADER. The information before the header is any text created by + the user. The information after the MGEDRC_HEADER is written by the + Create/Update .mgedrc command and is a comprehensive list of the default + settings and options for the MGED user interface. If any edits are made to + the .mgedrc text after the header, these changes will be overwritten by + the default settings if the Create/Update .mgedrc command is called again. + The information before the HEADER, however, is not changed. + </para> + + <note id="mgedrc4"> + <para> + Remember that when creating/updating .mgedrc files, if any + conflicting/repeated commands are found, BRL-CAD "obeys" the last + command listed. + </para> + </note> + + <para id="mgedrc5"> + In Figure D-1, note that lines have been added before the header to show + different raytracing options and the commands have been sectioned into + functional divisions separated by comment fields (comment fields are + denoted by the symbol "#"). + </para> + + <figure id="mgedrc6"> + <title>The two basic parts of the .mgedrc file: (1) information before header, and (2) information + after header.</title> + <mediaobject> + <imageobject> + <imagedata align = "center" fileref="../../tutorials/mgedrc/mgedrc_images/figure1.png" format="PNG"></imagedata> + </imageobject> + </mediaobject> + </figure> + + <para id="mgedrc7"> + Each command includes the following four basic components: + + <itemizedlist> + <listitem> + <para> + the "proc" (procedure) prefix, + </para> + </listitem> + <listitem> + <para> + a unique name, + </para> + </listitem> + <listitem> + <para> + arguments, and + </para> + </listitem> + <listitem> + <para> + the body (i.e., commands that MGED should execute). + </para> + </listitem> + </itemizedlist> + </para> + + <para id="mgedrc8"> + The symbol ";" signifies command separation (a return), and the symbol "$" + inserts the value of the subsequently named variable. + </para> + <para id="mgedrc9"> + The following text discusses some specific examples of the type of + shortcuts that can be created by users to expedite common operations such + as executing raytraces with particular parameters, accepting and rejecting + edits, setting azimuth and elevation, etc. + </para> + <para id="mgedrc10"> + First, the command to execute a specific kind of raytrace can often be + long and tedious to type. For example, if a user wanted to render an image + in a window 256 pixels high and wide, with a background color of white, + and with the ambient light set to 0.7, the following text would have to be + typed: + + <literallayout> +rt -s256 -C255/255/255 -A.7 + </literallayout> + + However, it is a simple matter to add a line to the user's .mgedrc file to + automate the calling of this instruction. The user's line might be as + follows: + + <literallayout> +proc 256wa {} {rt -s256 -C255/255/255 -A.7} + </literallayout> + + Diagrammed, this line breaks down as follows: + <informaltable> + <tgroup cols='4'> + <tbody> + <row> + <entry>proc</entry> + <entry>256wa</entry> + <entry>{}</entry> + <entry>{rt -s256 -C255/255/255 -A.7}</entry> + </row> + <row> + <entry>Denotes that a Tcl procedure is being created.</entry> + <entry>Names the procedure 256wa.</entry> + <entry>Denotes that there are no arguments.</entry> + <entry>Denotes the MGED command that will be executed. + The rendering will be 256 pixels square size (as + signified by -s), will have a background red-greenblue + value of 255 255 255 (as signified by the -C + option), and will have an ambient light setting of 0.7 + (as signified by the -A option).</entry> + </row> + </tbody> + </tgroup> + </informaltable> + + Now, all the user has to type on the command line to execute a rendering with the previously + listed options is the following procedure name: + + <literallayout> +256wa + </literallayout> + + Note that this name has been intentionally kept short and function-based. It reduces a + 27-character command to a 5-character command and provides the user with an idea of the + action it performs. The 256 stands for the rt square size, the w stands for a white background, + and the a stands for ambient lighting. But this convention is just a suggestion. The user may + choose any name that is unique and does not contain words that are reserved for MGED + commands (e.g., create). + </para> + + <para id="mgedrc11"> + The .mgedrc file can also be used to create shortcuts for other types of command line or GUI + commands. For example, the syntax for creating a shortcut for accepting and rejecting edits + from the command line might be as follows: + + <literallayout> +proc acc {} {press accept} +proc rej {} {press reject} + </literallayout> + + In addition, a possible shortcut for calling a standard viewing geometry might be as follows: + + <literallayout> +proc 145 {} {ae 145 25} + </literallayout> + + And to save the extra selection step when making or copying a primitive, the respective + procedure syntax for combining the make and sed commands and copy and sed commands + might be as follows: + + <literallayout> +proc mks {newprim primtype} {make $newprim $primtype; sed $newprim} + </literallayout> + +and + + <literallayout> +proc cps {oldprim newprim} {cp $oldprim $newprim; sed $newprim} + </literallayout> + + </para> + + <para id="mgedrc12"> + Figure D-2 shows a sample section of a .mgedrc file that allows the user to specify the command + line editor, customize the window size and placement, and toggle the function keys. + </para> + + <figure id="mgedrc13"> + <title>Sample elements and functionality of a .mgedrc file.</title> + <mediaobject> + <imageobject> + <imagedata align = "center" fileref="../../tutorials/mgedrc/mgedrc_images/figure2.png" format="PNG"></imagedata> + </imageobject> + </mediaobject> + </figure> + + + <para id="mgedrc14"> + The diagrammed command for sizing and positioning the command window is as follows: + <informaltable> + <tgroup cols='4'> + <tbody> + <row> + <entry>set mged_default</entry> + <entry>(geom)</entry> + <entry>475 × 250</entry> + <entry>+65 +80</entry> + </row> + <row> + <entry>Sets MGED command window defaults.</entry> + <entry>Specifies command window.</entry> + <entry>Sizes the window width to 475 pixels and the height to 250 pixels.</entry> + <entry>Denotes window location will be 65 pixels from the left side of the + display and 80 pixels from the top edge of the display.</entry> + </row> + </tbody> + </tgroup> + </informaltable> + </para> + + <para id="mgedrc15"> + As illustrated in Figure D-3, to specify the window size, the user inputs + width-by-height dimensions for each window (i.e., 475 × 250). To specify + the placement of the windows on the display, the user specifies offset + distances (i.e., +65 +80) from the edges of the display (as measured in + pixels). The first number defines the distance for the left/right + placement, and the second number is for the up/down placement. The "+" + symbol indicates a distance from the left side of the display to the left + side of the window or from the top of the display to the top of the + window. Alternatively, if a "-" symbol were present (as shown on the right + side of Figure D-3), it would indicate a distance from the right side of + the display to the right side of the window or from the bottom of the + display to the bottom of the window. + </para> + + <figure id="mgedrc16"> + <title>Sample window dimension input and positioning.</title> + <mediaobject> + <imageobject> + <imagedata align = "center" fileref="../../tutorials/mgedrc/mgedrc_images/figure3.png" format="PNG"></imagedata> + </imageobject> + </mediaobject> + </figure> + + +</article> Property changes on: brlcad/trunk/doc/docbook/articles/mgedrc/mgedrc.xml ___________________________________________________________________ Added: svn:mime-type + text/plain Added: svn:eol-style + native Property changes on: brlcad/trunk/doc/docbook/articles/mgedrc/mgedrc_images/figure2.png ___________________________________________________________________ Added: svn:mime-type + application/octet-stream Property changes on: brlcad/trunk/doc/docbook/articles/mgedrc/mgedrc_images/figure3.png ___________________________________________________________________ Added: svn:mime-type + application/octet-stream Added: brlcad/trunk/doc/docbook/articles/oed/Makefile.am =================================================================== --- brlcad/trunk/doc/docbook/articles/oed/Makefile.am (rev 0) +++ brlcad/trunk/doc/docbook/articles/oed/Makefile.am 2008-09-25 04:15:41 UTC (rev 32760) @@ -0,0 +1,25 @@ + +docbookdir = $(BRLCAD_DATA)/docbook/oed + +docbook_DATA = \ + README \ + lollipop.png \ + oed.xml \ + oed_0001.png \ + oed_0002.png \ + oed_0003.png \ + oed_0004.png \ + oed_0005.png \ + oed_0006.png \ + oed_0007.png \ + oed_0008.png \ + oed_0009.png \ + oed_0010.png \ + oed_0011.png \ + oed_0012.png \ + oed_examples.asc + +EXTRA_DIST = \ + $(docbook_DATA) + +include $(top_srcdir)/misc/Makefile.defs Property changes on: brlcad/trunk/doc/docbook/articles/oed/Makefile.am ___________________________________________________________________ Added: svn:mime-type + text/plain Added: svn:eol-style + native Added: brlcad/trunk/doc/docbook/articles/oed/README =================================================================== --- brlcad/trunk/doc/docbook/articles/oed/README (rev 0) +++ brlcad/trunk/doc/docbook/articles/oed/README 2008-09-25 04:15:41 UTC (rev 32760) @@ -0,0 +1,22 @@ +Docbook processing: + +Tools: + + Editing: Emacs + NXML mode + + Processing: xmlto and fop + +Conversion to pdf using xmlto and Apache FOP: + +xmlto fo oed.xml; fop oed.fo -pdf oed.pdf + +Converstion to html using xsltproc: +XML_CATALOG_FILES="../../catalog.xml" xsltproc -nonet -o oed.xhtml docbook.xsl oed.xml + +Common issues: + + Different systems tend to have different locations for + storing the docbookx.dtd file referenced at the top of + the xml document. Be sure to change this path to the + correct local path for docbookx.dtd before attempting + the above conversion. Property changes on: brlcad/trunk/doc/docbook/articles/oed/README ___________________________________________________________________ Added: svn:mime-type + text/plain Added: svn:eol-style + native Property changes on: brlcad/trunk/doc/docbook/articles/oed/lollipop.png ___________________________________________________________________ Added: svn:mime-type + application/octet-stream Added: brlcad/trunk/doc/docbook/articles/oed/oed.xml =================================================================== --- brlcad/trunk/doc/docbook/articles/oed/oed.xml (rev 0) +++ brlcad/trunk/doc/docbook/articles/oed/oed.xml 2008-09-25 04:15:41 UTC (rev 32760) @@ -0,0 +1,878 @@ +<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" +"../../resources/standard/dtd/docbookx.dtd"> +<article> + <articleinfo> + <title>Object Editing - the <command>oed</command> Command</title> + <author> + <firstname>Clifford</firstname> + <surname>Yapp</surname> + </author> + + <legalnotice> + <para>Approved for public release; distribution is unlimited.</para> + <para>Date approved: 05/09/2008</para> + </legalnotice> + + </articleinfo> + + <abstract> + <para> The <command>oed</command> command in MGED is used to enter + what is called "object edit mode" + <footnote> + <para>In some places in MGED this will be referred to as "matrix + edit mode" - the terms both refer to the same concept.</para> + </footnote> + - practically speaking, this mode allows transformations on combined + objects (combinations of primitives created with + <command>comb</command>, for example.) These transformations are not + (by default) made to the coordinate information in the primitatives + in question but are stored instead in a <emphasis>transformation + matrix</emphasis>. This article provides a brief overview and + explanation of the behavior of the <command>oed</command> command + and its uses.</para> + </abstract> + + <sect1> + <title><command>oed</command> - Basic Syntax and Operations</title> + + <para> The syntax of <command>oed</command> is fairly + straightforward: + <footnote> + <para>Note: <emphasis>lhs</emphasis> is an abbreviation for left + hand side and rhs similary stands for right hand side, given the + assumption that a path is displayed as an ascii stream with left + to right text orientation (e.g. /toplevel/level-1/level-2/etc.) + </para> + </footnote> + </para> + + <cmdsynopsis> + <command>oed</command> + <arg choice='req'><replaceable>path_lhs</replaceable></arg> + <arg choice='req'><replaceable>path_rhs</replaceable></arg> + </cmdsynopsis> + + <para><command>oed</command> serves primarily to make working with + combinations and regions practical when there are large numbers of + primitives involved. It is of course possible to move primitives + one by one to desired locations, but the process is extremely + tedious for any non-trivial combination of primitives and the + result is inflexible - for example,if the modeler wished to return + the primitives in a combination to their original position after + moving them <emphasis>as primitives</emphasis> the process of + moving them would need to be reversed one by one as well. Barring + being able to do everything perfectly the first time, individual + primitive placement is impractical.</para> + + <para>The notion of <emphasis>path</emphasis> in this context + refers to the tree of objects that traditionally makes up a CSG + model. Primitives will be combined with other primitives to make + groups of objects, and the "path" to any individual shape within + the combinations is described by the series of nodes in the tree + that identify the object of interest. For example, take a simple + model of a lollipop:</para> + + <para> + <screenshot> + <graphic align = "center" fileref="lollipop.png"></graphic> + </screenshot> + </para> + + <para> If we examine the tree structure of this object, we see it + resembles a filesystem - combinations and regions act a bit like + "folders" which can hold other folders and files. + <footnote> + <para> When tree structures are displayed, a "/" suffix denotes + a combination and a "/R" denotes a combination that is a region. + </para> + </footnote> + + <literallayout class="monospaced"> +mged> tree lollipop +lollipop/ + u outer-candy-shell.r/R + u outer-candy-sphere.c/ + u outer-candy-sphere.s + - core.s + - stick.s + u outer-candy-cyl.c/ + u outer-candy-cyl.s + - outer-candy-sphere.s + u stick.r/R + u stick.s + u core.r/R + u core.s + - stick.s + </literallayout> + + In the "filesystem" of a BRL-CAD object combinations can + hold combinations, regions and primitives. Regions + can hold combinations and primitives. + <footnote> + <para>Regions will accept other regions as constructive arguments + if given, but this is not good practice - BRL-CAD assumes a + region is composed of combinations and primitives which share a + material type.</para> + </footnote> + Primitives are always leaves on the tree - they do not "contain" + anything. Combinations, regions, and primitives can have + associated with them transformation data (sort of like metadata in + a filesystem) that tells BRL-CAD how to manipulate the combination, + region, or primitive in question. It is this data that will be + acted upon when the <command>oed</command> command is used. So in + the above example the full "path" of the outer-candy-sphere.c + combination used in lollipop would be: + + <literallayout class="monospaced"> +/lollipop/outer-candy-shell.r/outer-candy-sphere.c + </literallayout> + + Note that if we wish to operate on this combination it is not enough + to specify /lollipop/outer-candy-shell.r for the lhs and + outer-candy-sphere.c for the rhs - <emphasis>combinations and + regions do not themselves have default control points.</emphasis> In + other words, if you want to rotate a combination there must be a + point around which that rotation occurs - a combination will have no + default point assigned. This is the reason the rhs must always end + with a primitive - even though the intent is not to edit the + primitive, information necessary for most operations on the + combination will use information (such as default keypoint settings) + that the primitive <emphasis>does</emphasis> have. So, + + <literallayout class="monospaced">oed /lollipop/outer-candy-shell.r outer-candy-sphere.c</literallayout> + + is not enough. Either + + <literallayout class="monospaced">oed /lollipop/outer-candy-shell.r + outer-candy-sphere.c/outer-candy-sphere.s</literallayout> + + or + + <literallayout class="monospaced">oed /lollipop/outer-candy-shell.r outer-candy-sphere.c/core.s</literallayout> + + or + + <literallayout class="monospaced">oed /lollipop/outer-candy-shell.r outer-candy-sphere.c/stick.s</literallayout> + + + is needed to have <command>oed</command> actually enter edit mode on + lollipop's outer-candy-sphere.c. Because they are primitives in the + outer-candy-sphere.c combination, outer-candy-sphere.s, core.s and + stick.s are all legal - there will be illustrations later of the + consequences of different primitive choices.</para> + + <para>To demonstrate basic <command>oed</command> behavior an + example is in order. + <footnote> + <para>Bear in mind that these examples will be using very basic + primitives for the sake of simplicity and it is not guaranteed + that they will behave well for things like raytracing. In this + document raytraced screenshots are included to aid visualization. + Most of them are simple but there are sometimes a number of extra + steps needed to actually allow the objects to be raytraced with + the results seen here.</para> + </footnote> + <footnote> + <para><emphasis>path_lhs</emphasis> will be set to "/" for these + simple cases - this means either we will be working with + combinations that are not contained within any other combination/region + or the intent is to transform <emphasis>every</emphasis> instance of + the combination/region present regardless of where it appears in the + tree structure. "/" denotes the toplevel lhs path, or the "root of all + trees" in the database. Because every object in the database exists + "on its own" at the top level as well as inside tree structures, + operating on any object with a "/" path_lhs will always edit the matrix + associated with that particular combination/region independently + of any other transformations applied within tree structures.</para> + </footnote> + </para> + + <para> In an empty MGED session, create a new geometry database + called <emphasis>oed_examples.g</emphasis>. Enable the model + coordinate axes display by entering the MGED command + <command>rset ax model_draw 1</command>. Create two primitives: + <footnote> + <para> This document will respect the normal BRL-CAD naming + convention: use the .s extension for primitives, the .c + extension for combinations below regions, and the .r extension + for regions. Combinations above regions have no extension.</para> + </footnote> + + <literallayout class="monospaced">in sphere.s sph 0 0 0 4</literallayout> + <literallayout class="monospaced">in cube.s arb8 5 5 0 8 5 0 8 5 3 5 5 3 5 8 0 8 8 0 8 8 3 5 8 3</literallayout> + + There should now be a sphere and a cube visible on the screen. Next + create a combination of these two primitives: + + <literallayout class="monospaced">comb object1.c u sphere.s u cube.s</literallayout> + + After this command both the primitives and the combination are \ + present in the display, which will result in overlaps. Use the + <command>B</command> command to reduce the display to just the + combination. + <footnote> + <para>The <command>B</command> abbreviation stands for "blast" - + i.e. remove all objects from being displayed, and draw only the + specified objects.</para> +... [truncated message content] |