.\" $Header$
;Date:     Fri, 24 Apr 87 9:58:56 EDT
;From: Keith Applin (VLD/VMB) <keith@BRL.ARPA>

About MGED objects.  The generic name given to any member of an MGED file
is object.  There are 2 divisions at the next level: primitives(solids) and
combinations.  The primitives are just as you might expect, the defining
parameters.  The combinations consist of members with a boolean operation.
The combinations are further divided into regions and groups.  A group
is a combination consisting of any objects along with only the union
operation.  A region is a combination of any objects (but generally only
primitives and other regions) along with any of the operations.  These
regions are special in that they are ALL that the ray-tracing evaluates
or sees.  Hence every path must contain a region for ray-tracing purposes.
If a path does not have a region in it, then when ray-traced, a region will
be created consisting of only the solid at the bottom of the path.
The regions also have a material code number attached, to be used by some
of the ray-tracing applications.

The procedure generally followed in building a model is:

	1.  Build the primitives at desired locations, etc.
	2.  Make the regions of these solids to produce the
	    desired shape.
	3.  Make higher level groups of these regions,
	    generally according to function, etc.
	    NOTE: using this procedure, the regions
	    cannot occupy the same volume in space (overlap)

I got your "castle" today and took a quick look at castle.g.  The use of
all regions (using the union operation) allows just about everything to
overlap (interfere).  The "E" command in MGED does not know how to
evaluate regions within regions, hence you must use the "e" command to
display such animals.

I didn't get a chance to look at castle-gr.g, but I assume you used groups
(non-region combinations) to define the higher levels instead of regions.
Of course, once you do this, any overlaps between the lower level regions
will show up during ray-tracing.

Both ways of doing business are okay, except you must be careful about
overlapping regions when higher levels are made using groups.  I guess
it is a case of personal preference.
========================================
;Date: Sun, 26 Apr 87 18:51:29 edt
;From: Mike McDonnell <mike>

Thanks for your clear explanation of the differences between
regions and groups.  I now understand some of the differences
between the two types of combination objects.  I also still don't
*like* those differences, at least in some respects.  For example,
if the raytracer only sees regions then why can't MGED evaluate
[E] hierarchies of regions?  This is a nice way to preview a
model in detail before you raytrace it.  Much cheaper than
raytracing, and much better than 'e' evaluation for complex
objects.  Is there a good reason for this behavior?  As a
newcomer to the CAD package I can maybe see the ugly aspects of
it better than some of you "old hands" who have come to accept
its peculiarities.  In fact I still see no good reason to have
such an entity as a group at all.  Why not make a group a special
case of a region and make regions equally acceptable to all the
various programs in the CAD package?  If the purpose of groups is
to have a way to check that nothing overlaps, then it seems to me
that this can be checked by special commands operating on
regions.  If the "purpose" of groups is that they are historical
baggage, then they should be excised as a warty complication of
what could be an elegant system in which there are only solids
and regions with solids as leaf nodes and regions for all
interior nodes.
========================================
;Date:     Mon, 27 Apr 87 13:39:32 EDT
;From: "Gary S. Moss (SLCBR-VLD-V)" <moss@BRL.ARPA>

 For our mission, we require there be groups as such.  Regions are used
to describe low-level functional units of homogeneous material composition.
Groups are used to combine regions in order to assemble higher level functional
units of heterogeneous material composition or to describe application-specific
lists of objects.  As far as the software is concerned, groups are not
boolean combinations, but simple lists of objects.  That is why these pseudo
unions will result in overlaps if the 2 members of a group occupy the same
space.  If groups WERE evaluated as unions, it would incur considerable CPU
overhead, and would encourage mis-use of this construct.  That is, someone
could model two road wheels that happened to overlap (due to modeling
error) and then group them together to form a "road_wheels" group, which
would take care of the overlap by unioning them together.  Typically, we
group most of the description into an application-specific entity like
"exterior" for doing a certain type of analysis.  Now, if groups were
really unions of objects, nothing could possible overlap.  For our mission,
we MUST have accurate geometry, and this would allow errors to go unnoticed.

The region evaluator in MGED is deficient in that it does not handle
regions within regions.  We have always known this, the code that does
the region evaluation was taken from the CIDD code which does not
support regions within regions.  It has been improved somewhat since it
was grafted onto MGED, but we intend to rewrite it eventually.  This
project is not high on our priority list.

The RT library handles regions within regions fine, but since they are
supposed to be of homogeneous material composition, the upper-most
region material ID takes precedence.  Perhaps the regions could be
modified to include the group as a special case, but this does not sound
"cleaner" to me given the functional distinctions that I have
mentioned.  I think "historical baggage" is not an accurate description
of groups, because they are much cheaper then regions and have a
distinct purpose.

~moss/...
========================================
;Date:     Wed, 29 Apr 87 2:01:37 EDT
;From: Mike Muuss <mike@BRL.ARPA>

The "problem" with regions is more of a definitional one.  Internal to
the software, there are only two types of nodes, non-terminal ("combinations")
and terminal ("solids").  It is possible to set a flag on a non-terminal
node marking it as a region.

The problem comes from the fact that everything above the region flagged node
(towards the root) is used for grouping, where as everything below the
region flagged node is actually defining a single, solid, self-consistent
chunk of 3-d space.  Therefore, regions are chunks of 3-space, and
regions are grouped together to form the model.  It is permitted in RT,
but not in some earlier software, to perform non-union operations on
regions (i.e., subtract one region from another).

The "big-E" command in MGED is slated for overhaul.  The task of
"facetizing" a CSG model is a difficult one;  the current code in MGED,
while very useful, is quite inadequate.  I had hoped to have created
a general capability for facetizing MGED databases last year, but lots
of things (most importantly the Cray, and the CAD Distribution itself)
kept getting prioritized ahead of that project, and it still languishes.

	Best,
	 -Mike

From:     Keith Applin (VLD/VMB) <keith@BRL.ARPA>
Subject:  Good Modeling Practices

Solid modeling using MGED can tend to be quite individual, however I
will attempt to give my version ( < 500 words ) of some "good" modeling
practices.  To model a particular object, I would recommend something
like this:

First decide how to represent the object, including the amount
of detail and the solid[s] and region[s] necessary.  Then the solids
are created and edited to have the size, shape, and orientation desired.
Solids can be created via "make", "cp", "mirror", or "in" commands.
Depending on complexity the solids are created in the desired location
or; to take advantage of symmetry created at the origin and later
translated (and "push"ed) to the desired location.  Once all the solids
are finished it is time to create the region[s], which tell how to combine
the solids to represent the object.  The region[s] are then given
the desired item/air and material codes.  I usually use the "edcodes"
command to do this.  The region[s] are then put into a group, usually
for function.  A group is just a collection of objects
for functionality definition.  A group really has no operation as such,
and is really just a collection of objects.

Now a little bit about regions.  Regions are the objects that the
application ray-tracing interrogates.  If solids are not part of
regions they will not be "seen" at all.  Some ray-trace applications
will create a default region out of such an orphan solid.  Thus one
in general does not have solids in a "functional" group.  There are
times when temporary groups are made, say for editing purposes, where
it is desirable to include solids.

There are three operations allowed in regions; intersection (+),
union (u) and difference (-).  Intersection gives the common volume,
union gives the volume in all members, and difference subtracts from one
member the common volume with a second.  The union operator needs
clarification as to precedence:

	r region1 u solid1 - solid2 u solid3 - solid4

is evaluated as:  region1 = u (solid1 - solid2) u (solid3 - solid4)

Thus, the above region with unions is the same as the two regions:

    r region1 + solid1 - solid2   and    r region2 + solid3 - solid4

In fact, it is probably better practice to make the two distinct regions.
Of course, by using the two regions instead of the "union" region, one
must be aware of possible interference between the two regions.

Note,  r region1 u solid1 - solid2   and   r region1 + solid1 - solid2
produce the exact same results; however, for good practice one should use the
union only when the region is really intended for unions (i.e. more than
one union operation).

Members of regions are generally solids, however other regions are
acceptable.  Again it is probably good practice to use regions as
members of other regions only when really necessary.

The above is a brief summary of my views of "good" modeling practices,
for what it's worth.  Comments?

			-keith-

From:     "Gary S. Moss" (VLD/VMB) <moss@BRL.ARPA>

	The suggestion of parenthesis is a good one, however the modeler
is not designed in a way that would accommodate this scheme, at least not
in a straightforward manner.  There is no place to store an "expression"
that represents the region set operations.  The way it is done is that
every member of a region contains an operation and the boolean expression
falls out of the order of the region members as entered with the "r"egion
command, with precedence following a couple of rules;

	1] operations are applied "left to right" (the current operation
	is done to the current solid with respect to the existing region).

	2] there are implied parentheses that lie in-between union operators.

so

	+ s1 - s2 + s3 u s4 - s5 u s6

is equivalent to:

	((s1 - s2) + s3) u (s4 - s5) u s6

that is, if parenthesis were allowed.  Therefore, you can think of the
solids between unions (surrounded by implied parentheses) as sub-regions.
The order of the region members (which can be printed out with the "l"
command) is critical, and must be scrutinized when members are added or
deleted from a region.

	Physically, the only thing that is stored in the region record
is the number of members (length).  Immediately following the region
record are "length"-many member records which contain; the object's name,
the set operation, and a transformation matrix.  It is not clear that we
could permit parenthesis without radical redesign of the data base
structure.  Although I concede that it would be nice, it does not seem to
be justified once you understand how the implied precedence work.

Thoughts anyone?
~moss/...

From:     Mike Muuss <mike@BRL.ARPA>

Using "groups" BELOW the "region" node for expression grouping
is perfectly fine.  Using the implied parens around UNION operators
is another strategy.

Parens would be nice, but we don't presently have any easy way of
storing them.  Early versions of librt didn't know about the
"implied parens" rule, a legacy from GIFT, now we are stuck with it.

Overall, I don't feel the present state is unacceptable.
	Best,
	 -Mike

From:     "John R. Anderson" (VLD/ASB) <jra@BRL.ARPA>

Gwyn suggested in a previous message that a component should be kept as
a single region if possible.  Back in the days of GIFT, it was common
practice to describe a component with more than one region.  We tried to
stay away from complex regions mainly because the more complicated the
region, the harder it is to figure out what is going on and what effects
a single change might have. Therefore, a component was often a series of
simple regions with the same ident code.  I use the term "component" to
refer to an object with a particular ident code, but I'm not sure this
is still the accepted definition.  I have no qualms about letting "mged"
or "rt" crunch through complex regions, but I think we should make it
very clear to all users if components described as a group of regions
are going to cause them trouble later on.


				-John

From:     Earl Weaver (VLD/ASB) <earl@BRL.ARPA>

Perhaps we have a semantic problem here.  The term "component" may mean
different things to different people.   For example, most people would
think of a flight control rod in a helicopter as one component.  However
an application program  may need to know the difference between the
tube-part of the control rod and each end (or clevis) of the rod because
those sections of the control rod might  exhibit different physical
properties.  Thus it would be appropriate to model that one "component"
(which in reality is one piece--not designed to be disassembled) as
three regions and each one can be treated as a component.  My practice
would be to group those three "regions" into "control_rod", then further
group the control rods into flight controls.

					-Earl

From:     Doug Gwyn (VLD/VMB) <gwyn@BRL.ARPA>

I think "component" should still be identified with a collection of MGED
"regions" that share an "ident code".  For the time being I don't see
any necessity to make an actual single MGED "region" out of them.