On Wed, Jul 17, 2013 at 11:47 AM, phoenix <[email protected]> wrote:
> > But remember you have another challenge for something like that -
> recognizing when a curve-surface intersection is not actually part of the
> outer loop but is instead an "inner" curve segment. One approach might be
> to maintain a 2D "grid" of unit squares that maps to the Bezier patches and
> corresponds to their "flattened" topology - using that to track the edge
> status (intersecting/not-intersecting/partial) should make it much easier
> to determine when a particular edge is part of the final "outer" loop.
>
> Recognizing inner loops is really an important question to think about.
> (BTW, if an overlap region has an inner loop, should we report two
> ON_SSX_EVENTs? One for the outer loop and one for the inner loop.)
>
Unfortunately, I think the "robust" way to handle that particular issue is
to report "sets" of loops - one outer and zero or more inner - as
individual events, and even using that definition multiple "events" are
possible for sufficiently complex surface interactions. I say this because
we may have a situation where an "inner" trimming loop has another
intersection of the same surfaces that occurs entirely within that loop,
and the only way to represent that is going to be to have the loop within
the "inner" loop be the outer loop of a new surface - i.e. it may take
multiple NURBS surfaces to describe the results of two general surfaces
interacting.
I'll try to think of a way to generate an appropriate example - mentally,
I'm thinking of two complex surfaces that start as the same surface in
space, and then have various control points at various (different) places
on the two surfaces moved in various directions. The result would be
almost like intersecting two different perturbed water surfaces, with a
myriad of shared subsurfaces, as well as each surfaces having other
subsurfaces both above and below the other surface.
> As for the approach you mentioned above, an edge may not be aligned with
> the grids, because it might be boundaries of the other surface "projected"
> to this surface. Have I missed anything?
>
It's more likely that I have - I was thinking each NURBS surface could be
viewed as a "grid" of Bezier patches, and the intersection logic would
recognize which "grid patches" on both surfaces had all four edges
coincident with another surface and which ones had three or less - if those
patches are delineated by the knots in the NURBS UV space, then you could
know which "knot patches" were completely involved with a surface/surface
event and which were only partially involved (hence "outer"). I may not
have understood your idea fully, or I may be misunderstanding how the
Bezier patch idea works for the intersection problem.
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
