Hi Cliff,
Sorry I'm quite busy with some other stuffs during these days so I didn't have
much time to dig into the r5 problem since I read your last email. :(
> I've dug into this example a little further, and it turns out that rather than
> leaving extra faces behind, the extra surface area at the top of the model
> is a consequence of the coplanar subtractions never getting subtracted
> from the original surfaces. I'm not sure where it's failing, because
> individually converting s5 and s6 and doing intersections of the faces in
> question
> does produce correct trimming curves. Is the direction error (which appears
> to be resulting from the coplanarity of the intersections) depriving the
> subsequent algorithms of necessary information?
I have seen that some code for co-linearity has been added to the boolean
evaluations. Will it be a problem that just setting m_curve3d, m_curveA and
m_curveB in the ssx_overlap event to NULL? By definition, they should store the
boundary curves of the overlap region, and are used in the surface splitting
procedure. If individual intersections are correct, I guess that here may be
the problem. In the new code, if coplanar==1, ON_Intersect isn't called.
Haha, just a guess.:) Maybe it's worth a try. The r5 case is a little bit
complicated, so I haven't done too much on it. But I don't think there are
direction errors - the direction of a surface is only reversed according to the
type of boolean operation and its role (e.g. minuend or subtrahend). But the
correctness of the curve directions need to be investigated.
> The brep_boolean_tests.g in src/librt/tests has some tests for basic
> sphere/sphere boolean operations as well, which are giving surfaces with
> surprising UV space trimming behavior. A quick look by myself and Keith
> suggests that the presence of the sphere's degenerate edge may be causing
> some confusion - we would expect to see two half-circle trims on the top
> and bottom given the intersection topology, but instead we seem to get one
> circle in the middle of the UV space.
You mean sph1.s - sph4.s? The result of only one circle in the middle of the UV
space in actually correct. If you convert the primitives to brep first, you can
find that the trimming curve of sph1.s_brep (brep sph1.s) is
(0,0,-1000)->(1000,0,0)->(0,0,1000), which is on the XZ plane. The trimming
curve of sph4.s also lies on the XZ plane. But sph4 is on the "y-side" of sph1,
so the intersection curve doesn't intersect the trimming curves. So we SHOULD
get only one circle in the middle. But if you move sph4 to center at
(1700,0,0), the result will be different. For sph1_brep, the intersection
should be two half-circle trims.
No need to say thanks as I'm responsible to follow up my work if there's any
problem. Of course, I'm really happy to see some progress by others on the brep
boolean evaluations.:)
Cheers!
Wu
------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
BRL-CAD Developer mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/brlcad-devel
