> The general idea is to use the quasi-interpolating net (which apparently can > be generated with a maximum distance epsilon from the parent Bezier patch) > for ray tracing, but I was wondering - since we're talking about Bezier > sub-patches of NURBS surfaces in the first place, could you construct and > refine these quasi-control nets for potentially overlapping sub-patches and > test whether pairs of these nets intersect for a given region? Ideally, with > refinement, you might be able to recognize when and where two nets were > converging, and determine the shared surface regions as guided by the nets.
I've read the paper. Your idea of constructing "quasi-control nets" and test the intersection of the nets is just like what we do in the ssx_transverse case: using triangular approximation of sub-surfaces and test their intersections. This is really slow for the overlap cases, because the number of intersecting sub-surfaces is too large. First, how to get the "potentially overlapping sub-patches"? Currently the method we discussed several days ago can give us the boundary curve segments of the overlap regions (and also some "noisy" segments), but not whether a specific patch has overlap or not. If we need that information, as you are talking about "potentially overlapping sub-patches", we need curve-surface intersections and point-surface intersections on the sub-patch to the other surface, which needs lots of computations. And if we want a more accurate overlap region, we also need to test whether a small "grid" in the "quasi-control nets" is overlapped or not. This is too time consuming. Maybe I've misunderstood your ideas, but as far as I'm concerned, this is not quite practical. I'd like to share my current ideas: 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.) 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). 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. After we can get the overlap regions, things get much easier. The bounding box sub-division below can eliminate the bounding boxes fully inside the overlap regions can be eliminated, and intersection points inside should also be eliminated. Thanks for the resources and ideas you provide, and look forward to your opinions on my ideas. :) Cheers! Wu
[email protected]
Description: Binary data
------------------------------------------------------------------------------ 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
