"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
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.
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.
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.
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.
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?
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.
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?
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.
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.
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.
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.