"Fossies" - the Fresh Open Source Software Archive

Member "brlcad-7.32.4/doc/notes/regions.txt" (29 Jul 2021, 14245 Bytes) of package /linux/misc/brlcad-7.32.4.tar.bz2:

As a special service "Fossies" has tried to format the requested text file into HTML format (style: standard) with prefixed line numbers. Alternatively you can here view or download the uninterpreted source code file.

    1 .\" $Header$
    2 ;Date:     Fri, 24 Apr 87 9:58:56 EDT
    3 ;From: Keith Applin (VLD/VMB) <keith@BRL.ARPA>
    5 About MGED objects.  The generic name given to any member of an MGED file
    6 is object.  There are 2 divisions at the next level: primitives(solids) and
    7 combinations.  The primitives are just as you might expect, the defining
    8 parameters.  The combinations consist of members with a boolean operation.
    9 The combinations are further divided into regions and groups.  A group
   10 is a combination consisting of any objects along with only the union
   11 operation.  A region is a combination of any objects (but generally only
   12 primitives and other regions) along with any of the operations.  These
   13 regions are special in that they are ALL that the ray-tracing evaluates
   14 or sees.  Hence every path must contain a region for ray-tracing purposes.
   15 If a path does not have a region in it, then when ray-traced, a region will
   16 be created consisting of only the solid at the bottom of the path.
   17 The regions also have a material code number attached, to be used by some
   18 of the ray-tracing applications.
   20 The procedure generally followed in building a model is:
   22 	1.  Build the primitives at desired locations, etc.
   23 	2.  Make the regions of these solids to produce the
   24 	    desired shape.
   25 	3.  Make higher level groups of these regions,
   26 	    generally according to function, etc.
   27 	    NOTE: using this procedure, the regions
   28 	    cannot occupy the same volume in space (overlap)
   30 I got your "castle" today and took a quick look at castle.g.  The use of
   31 all regions (using the union operation) allows just about everything to
   32 overlap (interfere).  The "E" command in MGED does not know how to
   33 evaluate regions within regions, hence you must use the "e" command to
   34 display such animals.
   36 I didn't get a chance to look at castle-gr.g, but I assume you used groups
   37 (non-region combinations) to define the higher levels instead of regions.
   38 Of course, once you do this, any overlaps between the lower level regions
   39 will show up during ray-tracing.
   41 Both ways of doing business are okay, except you must be careful about
   42 overlapping regions when higher levels are made using groups.  I guess
   43 it is a case of personal preference.
   44 ========================================
   45 ;Date: Sun, 26 Apr 87 18:51:29 edt
   46 ;From: Mike McDonnell <mike>
   48 Thanks for your clear explanation of the differences between
   49 regions and groups.  I now understand some of the differences
   50 between the two types of combination objects.  I also still don't
   51 *like* those differences, at least in some respects.  For example,
   52 if the raytracer only sees regions then why can't MGED evaluate
   53 [E] hierarchies of regions?  This is a nice way to preview a
   54 model in detail before you raytrace it.  Much cheaper than
   55 raytracing, and much better than 'e' evaluation for complex
   56 objects.  Is there a good reason for this behavior?  As a
   57 newcomer to the CAD package I can maybe see the ugly aspects of
   58 it better than some of you "old hands" who have come to accept
   59 its peculiarities.  In fact I still see no good reason to have
   60 such an entity as a group at all.  Why not make a group a special
   61 case of a region and make regions equally acceptable to all the
   62 various programs in the CAD package?  If the purpose of groups is
   63 to have a way to check that nothing overlaps, then it seems to me
   64 that this can be checked by special commands operating on
   65 regions.  If the "purpose" of groups is that they are historical
   66 baggage, then they should be excised as a warty complication of
   67 what could be an elegant system in which there are only solids
   68 and regions with solids as leaf nodes and regions for all
   69 interior nodes.
   70 ========================================
   71 ;Date:     Mon, 27 Apr 87 13:39:32 EDT
   72 ;From: "Gary S. Moss (SLCBR-VLD-V)" <moss@BRL.ARPA>
   74  For our mission, we require there be groups as such.  Regions are used
   75 to describe low-level functional units of homogeneous material composition.
   76 Groups are used to combine regions in order to assemble higher level functional
   77 units of heterogeneous material composition or to describe application-specific
   78 lists of objects.  As far as the software is concerned, groups are not
   79 boolean combinations, but simple lists of objects.  That is why these pseudo
   80 unions will result in overlaps if the 2 members of a group occupy the same
   81 space.  If groups WERE evaluated as unions, it would incur considerable CPU
   82 overhead, and would encourage mis-use of this construct.  That is, someone
   83 could model two road wheels that happened to overlap (due to modeling
   84 error) and then group them together to form a "road_wheels" group, which
   85 would take care of the overlap by unioning them together.  Typically, we
   86 group most of the description into an application-specific entity like
   87 "exterior" for doing a certain type of analysis.  Now, if groups were
   88 really unions of objects, nothing could possible overlap.  For our mission,
   89 we MUST have accurate geometry, and this would allow errors to go unnoticed.
   91 The region evaluator in MGED is deficient in that it does not handle
   92 regions within regions.  We have always known this, the code that does
   93 the region evaluation was taken from the CIDD code which does not
   94 support regions within regions.  It has been improved somewhat since it
   95 was grafted onto MGED, but we intend to rewrite it eventually.  This
   96 project is not high on our priority list.
   98 The RT library handles regions within regions fine, but since they are
   99 supposed to be of homogeneous material composition, the upper-most
  100 region material ID takes precedence.  Perhaps the regions could be
  101 modified to include the group as a special case, but this does not sound
  102 "cleaner" to me given the functional distinctions that I have
  103 mentioned.  I think "historical baggage" is not an accurate description
  104 of groups, because they are much cheaper then regions and have a
  105 distinct purpose.
  107 ~moss/...
  108 ========================================
  109 ;Date:     Wed, 29 Apr 87 2:01:37 EDT
  110 ;From: Mike Muuss <mike@BRL.ARPA>
  112 The "problem" with regions is more of a definitional one.  Internal to
  113 the software, there are only two types of nodes, non-terminal ("combinations")
  114 and terminal ("solids").  It is possible to set a flag on a non-terminal
  115 node marking it as a region.
  117 The problem comes from the fact that everything above the region flagged node
  118 (towards the root) is used for grouping, where as everything below the
  119 region flagged node is actually defining a single, solid, self-consistent
  120 chunk of 3-d space.  Therefore, regions are chunks of 3-space, and
  121 regions are grouped together to form the model.  It is permitted in RT,
  122 but not in some earlier software, to perform non-union operations on
  123 regions (i.e., subtract one region from another).
  125 The "big-E" command in MGED is slated for overhaul.  The task of
  126 "facetizing" a CSG model is a difficult one;  the current code in MGED,
  127 while very useful, is quite inadequate.  I had hoped to have created
  128 a general capability for facetizing MGED databases last year, but lots
  129 of things (most importantly the Cray, and the CAD Distribution itself)
  130 kept getting prioritized ahead of that project, and it still languishes.
  132 	Best,
  133 	 -Mike
  135 From:     Keith Applin (VLD/VMB) <keith@BRL.ARPA>
  136 Subject:  Good Modeling Practices
  138 Solid modeling using MGED can tend to be quite individual, however I
  139 will attempt to give my version ( < 500 words ) of some "good" modeling
  140 practices.  To model a particular object, I would recommend something
  141 like this:
  143 First decide how to represent the object, including the amount
  144 of detail and the solid[s] and region[s] necessary.  Then the solids
  145 are created and edited to have the size, shape, and orientation desired.
  146 Solids can be created via "make", "cp", "mirror", or "in" commands.
  147 Depending on complexity the solids are created in the desired location
  148 or; to take advantage of symmetry created at the origin and later
  149 translated (and "push"ed) to the desired location.  Once all the solids
  150 are finished it is time to create the region[s], which tell how to combine
  151 the solids to represent the object.  The region[s] are then given
  152 the desired item/air and material codes.  I usually use the "edcodes"
  153 command to do this.  The region[s] are then put into a group, usually
  154 for function.  A group is just a collection of objects
  155 for functionality definition.  A group really has no operation as such,
  156 and is really just a collection of objects.
  158 Now a little bit about regions.  Regions are the objects that the
  159 application ray-tracing interrogates.  If solids are not part of
  160 regions they will not be "seen" at all.  Some ray-trace applications
  161 will create a default region out of such an orphan solid.  Thus one
  162 in general does not have solids in a "functional" group.  There are
  163 times when temporary groups are made, say for editing purposes, where
  164 it is desirable to include solids.
  166 There are three operations allowed in regions; intersection (+),
  167 union (u) and difference (-).  Intersection gives the common volume,
  168 union gives the volume in all members, and difference subtracts from one
  169 member the common volume with a second.  The union operator needs
  170 clarification as to precedence:
  172 	r region1 u solid1 - solid2 u solid3 - solid4
  174 is evaluated as:  region1 = u (solid1 - solid2) u (solid3 - solid4)
  176 Thus, the above region with unions is the same as the two regions:
  178     r region1 + solid1 - solid2   and    r region2 + solid3 - solid4
  180 In fact, it is probably better practice to make the two distinct regions.
  181 Of course, by using the two regions instead of the "union" region, one
  182 must be aware of possible interference between the two regions.
  184 Note,  r region1 u solid1 - solid2   and   r region1 + solid1 - solid2
  185 produce the exact same results; however, for good practice one should use the
  186 union only when the region is really intended for unions (i.e. more than
  187 one union operation).
  189 Members of regions are generally solids, however other regions are
  190 acceptable.  Again it is probably good practice to use regions as
  191 members of other regions only when really necessary.
  193 The above is a brief summary of my views of "good" modeling practices,
  194 for what it's worth.  Comments?
  196 			-keith-
  198 From:     "Gary S. Moss" (VLD/VMB) <moss@BRL.ARPA>
  200 	The suggestion of parenthesis is a good one, however the modeler
  201 is not designed in a way that would accommodate this scheme, at least not
  202 in a straightforward manner.  There is no place to store an "expression"
  203 that represents the region set operations.  The way it is done is that
  204 every member of a region contains an operation and the boolean expression
  205 falls out of the order of the region members as entered with the "r"egion
  206 command, with precedence following a couple of rules;
  208 	1] operations are applied "left to right" (the current operation
  209 	is done to the current solid with respect to the existing region).
  211 	2] there are implied parentheses that lie in-between union operators.
  213 so
  215 	+ s1 - s2 + s3 u s4 - s5 u s6
  217 is equivalent to:
  219 	((s1 - s2) + s3) u (s4 - s5) u s6
  221 that is, if parenthesis were allowed.  Therefore, you can think of the
  222 solids between unions (surrounded by implied parentheses) as sub-regions.
  223 The order of the region members (which can be printed out with the "l"
  224 command) is critical, and must be scrutinized when members are added or
  225 deleted from a region.
  227 	Physically, the only thing that is stored in the region record
  228 is the number of members (length).  Immediately following the region
  229 record are "length"-many member records which contain; the object's name,
  230 the set operation, and a transformation matrix.  It is not clear that we
  231 could permit parenthesis without radical redesign of the data base
  232 structure.  Although I concede that it would be nice, it does not seem to
  233 be justified once you understand how the implied precedence work.
  235 Thoughts anyone?
  236 ~moss/...
  238 From:     Mike Muuss <mike@BRL.ARPA>
  240 Using "groups" BELOW the "region" node for expression grouping
  241 is perfectly fine.  Using the implied parens around UNION operators
  242 is another strategy.
  244 Parens would be nice, but we don't presently have any easy way of
  245 storing them.  Early versions of librt didn't know about the
  246 "implied parens" rule, a legacy from GIFT, now we are stuck with it.
  248 Overall, I don't feel the present state is unacceptable.
  249 	Best,
  250 	 -Mike
  252 From:     "John R. Anderson" (VLD/ASB) <jra@BRL.ARPA>
  254 Gwyn suggested in a previous message that a component should be kept as
  255 a single region if possible.  Back in the days of GIFT, it was common
  256 practice to describe a component with more than one region.  We tried to
  257 stay away from complex regions mainly because the more complicated the
  258 region, the harder it is to figure out what is going on and what effects
  259 a single change might have. Therefore, a component was often a series of
  260 simple regions with the same ident code.  I use the term "component" to
  261 refer to an object with a particular ident code, but I'm not sure this
  262 is still the accepted definition.  I have no qualms about letting "mged"
  263 or "rt" crunch through complex regions, but I think we should make it
  264 very clear to all users if components described as a group of regions
  265 are going to cause them trouble later on.
  268 				-John
  270 From:     Earl Weaver (VLD/ASB) <earl@BRL.ARPA>
  272 Perhaps we have a semantic problem here.  The term "component" may mean
  273 different things to different people.   For example, most people would
  274 think of a flight control rod in a helicopter as one component.  However
  275 an application program  may need to know the difference between the
  276 tube-part of the control rod and each end (or clevis) of the rod because
  277 those sections of the control rod might  exhibit different physical
  278 properties.  Thus it would be appropriate to model that one "component"
  279 (which in reality is one piece--not designed to be disassembled) as
  280 three regions and each one can be treated as a component.  My practice
  281 would be to group those three "regions" into "control_rod", then further
  282 group the control rods into flight controls.
  284 					-Earl
  286 From:     Doug Gwyn (VLD/VMB) <gwyn@BRL.ARPA>
  288 I think "component" should still be identified with a collection of MGED
  289 "regions" that share an "ident code".  For the time being I don't see
  290 any necessity to make an actual single MGED "region" out of them.