Add vertexes to curve intersection list in addition to surface inters…#737
Add vertexes to curve intersection list in addition to surface inters…#737phkahler merged 1 commit intosolvespace:masterfrom
Conversation
|
Like so many other times, I let this bake in my head for a while and think it's not a great implementation. It seems that curves are not split when they intersect the edge of another surface - not just at a vertex, but anywhere (see issue 497). Going to let it sit a while longer and see if something better comes to mind. I'm thinking about curve-curve intersections, which has me thinking about number 171 as well. Or I could merge it and do something better later? What do people think about that approach? This is a fairly small patch. |
|
On reflection, I don't understand this either. My high-level idea was that if a curve from shell A intersects a curve or vertex from shell B, then it must also intersect a surface from shell B at that same point (since curves lie on surfaces, and vertices lie on curves). If your change helps, then I think that shows the curve-surface intersection isn't working like I'd intended. That observation would be a good lead for debugging the curve-surface intersection, though. |
Correct. I think in cases like a small box having a coincident edge with a larger box the planes cut the long edge correctly and things work as intended. In the case of #680 there is a curve created by the intersection of two planes, but one of them is larger than the geometry inside it so that curve extends too far. The surfaces that meet at the magic vertex that fixes the problem are all tangent at that point - 2 flat surfaces and 2 revolved arcs. But I've seen other cases where a line should be cut at the edge of a surface and it doesn't happen - I think #497 and #537 are cases where a straight trim curve should be cut on the edge of another surface but doesn't. One thing I'm considering is moving these kinds of checks so they are more like a part of the curve-surface intersection (test against the trim curves of that surface explicitly). which would be less invasive. Similarly, I don't understand why the generic surface/surface intersection doesn't work when the intersection is along the edge of a surface, like on lathe seams. If we just move the cutting plane a tiny bit it works. Now we make a copy of the trim curve which can be exact, but that doesn't explain why it didn't work before. |
|
Yeah, seems strongly like the root problem is in the curve-surface intersection. We expect the Newton-type solver to break around tangencies and such, but it seems like there's also breakage beyond that. I see at least two possible directions:
Option (2) is less elegant, but I suspect it might have the biggest near-term payoff. It's also a speedup. |
…ections. Sometimes a vertex can be used to split a curve where surface intersections can't. Those unsplit curves can cause boolean failures.
194945f to
7cb4db4
Compare
|
I'm going to merge this for now because it fixes a few real problems. In the near future I intend to redo it to get better coverage of existing open issue but I don't have the cycles right now. |
|
A further fix for this is here #786 |
…ections.
Sometimes a vertex can be used to split a curve where surface intersections can't. Those unsplit curves can cause boolean failures. This fixes issue #680
Needs more testing to be sure it doesn't break anything.
@ruevs and @jwesthues This and the improvements suggested in the code comments should fix some other open issues.