On Thu, Jul 18, 2013 at 11:47 PM, phoenix <[email protected]> wrote:
> As currently we can get the boundary curve segments of the overlap regions
> (with "noisy" segments), the next we should do may be to construct the
> overlap regions with the boundary information. See the figure attached. In
> gray is the "knot grid" of the surface. If we sub-divide the surface to
> Bezier patches, each patch should be correspondent to one grid (a small
> square). And overlap regions must be bounded by the boundaries of the
> Bezier patches, which are the vertical or horizontal lines in the figure
> (or that of the other surface and projected to this surface's UV space,
> that's why we have a non-linear curve here). So we tests the vertical lines
> and horizontal lines with the other surfaces with curve-surface overlaps
> (vice versa), and we get the blue and red segments. The blue ones should be
> the finally boundary while the red ones are "noise" and should be
> eliminated. As we know, the boundary of a close overlap region should form
> a loop, so we link curves that share a same end point together, and finally
> the blue segments are link together to a closed loop, while the red ones
> cannot be linked together. (More discussions are needed for this step,
> because I'm not sure whether it can work for all cases.)
>
Excellent picture, that helps a lot - yes, I think we agree, as long as
that other paper's assertion that once we're down to Bezier patches we
won't have any "patch internal" shared sub-surface intersection activity
without involving the edges proves to be correct.
After we get the boundaries, we need to decide whether it's an outer loop
> (the overlap is inside the closed region) or an inner loop (the overlap is
> outside the closed region).
>
Won't we know that already? If we have a set of loops in UV space and the
"red" grid identifies the contiguous sub-pieces of the patch, the loop
whose 2D bounding box contains all the 2D bounding boxes of the other loops
is the outer loop for that "patch". Any inner loop of blue lines that is
not fully inside another "inner" loop's bounding box is an inner trimming
loop to the outer loop. Any "inner" loop that *is* fully within the
bounding box of another inner loop would have to be a new outer loop for a
new surface, working within the constraints of how openNURBS defines
surfaces with trims.
I remember having to decide which loop was an "outer" loop for the mesh ->
nurbs logic, and the best test I could come up with was the 2D bounding box
in the projection. (In that case, because of the nature of the patches, it
was an actual 3D projection of the patch to a plane, but doing the test in
the UV domain may actually make a lot more sense - it should be much more
robust.)
> We may like to choose an arbitrary point inside that region (take care of
> there may be also an inner loop inside), and tests it's an overlap point or
> not.
>
Maybe I'm not following properly, but will there be a situation involving
Bezier patches where knowing which are the "red", "gray" and "blue" lines
won't give us sufficient information? I.e. do we need to test the patch
interiors when we know what is happening on their boundaries, and where
("blue" lines) there is a behaviour change between shared and non-shared?
I.e. a patch that has all four edges red is part of *some* intersection
surface, which one being determined by the smallest outer loop that is
fully bounding its bounding box?
Cheers,
CY
------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
BRL-CAD Developer mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/brlcad-devel
