On Mon, Jul 30, 2012 at 11:41 AM, phoenix <284281...@qq.com> wrote:
> The 2D curves in UV parameter spaces can be created within the intersection
> process, and I have finished it now. It works quite well at present,
> although it might still need some improvement.
Excellent!
> So I wonder how to deal with these 2D trimming curves. How to use them to
> generate new trimmed b-rep surfaces? That is, if we want to form the
> evaluated b-reps, we need to know the topological structure of the whole
> solid. For example, we evaluate a union of two intersecting spheres, we need
> to know which side of the intersecting curve is inside the union, and which
> side is the outer boundary of the union. Could you please describe this in
> more detail?
Here are my initial thoughts on this topic:
1. If no curve is generated, then the structure is dictated by the
boolean operations only:
A U B:
a. If one of A or B contains the other, return the
containing brep. (So if B fits within A, just return A)
b. Otherwise... as a first guess I'd say try creating two
breps - combname_A and combname_b - which would be duplicates of the A
and B breps with local matricies applied and the substitute those two
breps into expressions further up the tree. Not entirely sure about
that - there are some more subtle issues there that require some
thought - but that should do for a first cut.
A - B:
a. B contains A - the geometry is completely subtracted
away, nothing to generate. Return nothing (or a null brep, if that
makes more sense in context.)
b. A contains B - B becomes the "inner" surface of A -
essentially, B gets flipped and turned into an interior face of A
c. A and B do not overlap at all - just return A.
A + B:
a. If one of A or B contains the other, return the brep
that is contained. (So if B fits within A, just return B)
b. If A and B do not overlap, return nothing (or a null
brep, if that makes more sense in context.)
2. If an intersection point is generated:
A U B: Hmm... don't worry about this case yet, I need to discuss
how we want to handle it with some of the other devs. Hopefully it
will be relatively rare, so you can focus on the other cases while we
decide what the "correct" behavior is.
A - B: Use the intersection point and the surface normal of A at
that point to form a plane. Shift that plane bn_tol in the direction
opposite that of the surface normal, find the intersection curve of
the result, and remove that from B. Not ideal in some ways, but will
ensure that A' does not intersect B.
A + B: No volume described by a single intersection point -
return nothing. (or a null brep, if that makes more sense in
context.)
3. If an intersection curve is generated, applying the trimming
curves will result in multiple surfaces (depending on whether the
curves are used as part of a new outer loop, or a new inner loop):
A U B: For each surface generated for A and B, test whether it
is inside the other brep. Once you know which surfaces are fully
inside the other breps, those surfaces may be discarded.
A - B: For each surface from B, check whether it is inside A.
If so, it is flipped and forms a new surface in the evaluated A (call
it A'). If not, the surface is discarded.
A + B: For each surface, is it inside both A and B? If so, it is
part of the new brep.
4. If an intersection surface is generated:
A U B: Remove the matching surfaces patches from both breps, and
merge to form a new brep.
A - B: This is a bit trickier - in this situation, the only
thing I can think to do is to find the plane of intersection of the
surfaces patches, move it bn_tol in the direction opposite that of the
surface normal of A's patch, find the new intersection curve between
that plane and A, and use that surface patch as the new surface for A'
in that region. That's not mathematically ideal, but it will achieve
the expected and desired result of A' not intersecting B.
A + B: This produces a plane, not a solid brep, so return
nothing. (or a null brep, if that makes more sense in context.)
Testing inside/outside when you have intersection curve(s)... I'm not
sure what the best approach is there yet. Some kind of bbox approach
might be possible, but I'm not sure if there's a better way...
perhaps you could take the 3D bbox of the intersection curve, subtract
it from the bboxes of the two input breps, and then for each surface
subdivide until you got a box that was unambiguously in only one of
the brep bbox - curve bbox boxes?
> As for the threshold of bounding boxes' sizes, I think using
> INTERSECT_MAX_DEPTH is just OK. If we use a constant value to decide whether
> a bounding box is small enough, it's not quite suitable because the original
> sizes of the surfaces can vary significantly. So using a max depth we
> guarantee that we arrive at a constant proportion of the original size in UV
> parameter spaces (because after each split the UV domains both become half).
> What's your opinion?
As long as performance and results both seem good, that sounds fine.
Cheers,
CY
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel
