[cgma-dev] r3517 - cgm/trunk/itaps

[Jason Kraftcheck]

James Porter wrote:
> On Mon, 2010-02-01 at 15:46 -0600, Jason Kraftcheck wrote:
>> It should consistently either always return RefVolume or always return Body.
>> Mixing them breaks things because the iGeom API doesn't have that
>> distinction (only one of them can be used for the iBase_REGION type.)  I
>> started changing some of the RefVolume stuff to return Bodys instead, but
>> perhaps the better solution would be to change all the functions (e.g.
>> create*) to return RefVolumes instead?
> 
> It seems like more code assumes the existence of Bodies than RefVolumes,
> so it might be easier to change RefVolumes -> Bodies. On the other hand,
> RefVolumes seem to hold more geometric/topological information, so
> they're probably closer conceptually to what ITAPS imagines an
> iBase_REGION to be.
> 
> Would using RefVolumes exclusively be limiting in any way? My
> understanding is that a Body is a collection of RefVolumes, but if
> that's not helpful (or if in practice, our Bodies only have one
> RefVolume), then I think it makes more sense to return RefVolumes
> everywhere.

This should be possible.  Some care would have to be taken when calling APIs
that normally work on Bodies (e.g. union, subtract, intersect, etc.)  If the
user asks to unite two RefVolumes for which one is one amongst several
RefVolumes in the owning Body, the code must first separate the RefVolume
such that it is in its own Body.  But if bodies are never visible through
the API, this kind of thing should never be visible to the application.

The only other difference is that operations that would produce multiple
volumes but one body must have the API changed.  For example, uniting two
non-interfering bodies results in a single body containing all of the
RefVolumes.  The intersection of two RefVolumes may be two or more different
RefVolumes (consider the intersection of a cylinder with a torus).  Same for
the difference.

- jason