> Won't we know that already?
Even though we don't know that already, it's quite easy to acquire that
information. It's not a significant question.
> 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?
I also recognize that this problem may occur. For example, an inner loop might
be exactly a single "grid" bounded by four red edges. So we do need to test the
patch interiors to find out that whether it's really a boundary (if both sides
of the curve are "shared", it should not be a boundary (red); if one side of it
is "shared" but the other is "non-shared", it should be a "blue" boundary;
otherwise, both sides "non-shared", we should report an error - the curve
should not be an overlap boundary, but instead a tangent intersection curve,
which should be handled by the bounding box sub-division logic. For the cases
above, the boundary of the inner loop becomes "blue" and it won't cause
problems.
Cheers!
Wu------------------------------------------------------------------------------
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
