Intersection is incomplete. The bug occurs in both V7 and V6. (I don’t have earlier versions installed to test.)
This bug appears to be caused by some “core” code which determines intersections and is used by numerous commands.
Simple single span degree 3 surface, not singularities stacked control points, split edges and located near the origin. The untrimmed surface is the “Original” surface in the attached file and images below. IntersectBugDC01.3dm (1.6 MB)
Absolute tolerance 0.001
Angle tolerance 0.1
Intersect a plane at z=15.000 with the surface results in an incomplete intersection of two open curves.
Trimming the surface as in “Trim A” below results in the same.
Trimming smaller as in “Trim B” below results in the correct intersection with a single closed curve.
Moving the intersection plane to z=14.900 results in the same.
Moving the intersection plane from to z=15.001 results in the correct, single closed curve intersection for all surfaces.
I have verified that this bug occurs using the follow commands.
Intersect - as described above
Section - in the Front and Right views
Contour - when a contour is at z=15.000 or z=14.900
Project - when the line in the attached file is projected in the Front or Right view
Split - fails with plane at z=15.000 or z=14.900
Trim - fails with plane at z=15.000 or z=14.900
I did limited testing with planes and lines slightly tilted and the failures were similar.
My guess is other commands which use intersection calculation have the same bug with this geometry.
@Pascal Inserting knots does not fix the bug. Inserting knots at the midpoints also causes the incomplete intersection in the smaller trimmed surface.
Attached file has knots inserted into the surfaces at the midpoints. IntersectBugDC02.3dm (1.6 MB)
I hope this becomes high priority. It is a problem with core geometry calculations which need to be reliable.This example is simple enough it should work all of the time. I took time to explore it and document it in the hope that the developer can find the core issue, not just a work-around type of patch.
@davidcockey Thanks for taking the time to isolate the problem and report the bug. I appreciate your opinion
I hope this becomes high priority. It is a problem with core geometry calculations which need to be reliable.This example is simple enough it should work all of the time.
This is the kind of feedback we need to prioritize fixing this code. I spent a lot of time for V7 (and am still working on now) improving the Curve x Surface Intersection code. I identified this a major flaw in Surface x Surface intersection ( the core code you are reporting as a problem).
This code is very complex. There are two things you should know about fixing it. First, the problem is most likely because of a fundamental flaw somewhere in the code. It’s probably not a simple bug, like that variable should have been a u instead of a v. That’s because I’ve already fixed hundreds of bugs in this code over many many years. All of the easy to fix bugs have already been fixed.
Second, There are hundreds of places for things to go wrong. Even though 2 failures look the same there is a good chance that they fail for unrelated reasons. So it’s important for me to have many bug examples. All of this bug reporting and logging is an important step in getting the code fixed.
Hello Greg, I have tonight identified another instance of this bug, I think. I ran a very simple FilletSrf on two orthogonal plane surfaces and specified G2 fillet type. I did not use trim or extend or apparent intersections or anything like that. Then I ran the Intersect command and it reported zero intersections found. Multiple attempts were made to rebuild the surfaces or other such activities to no avail. Finally, I extended the surfaces along their own axes and Intersect was able to find an intersection, but it was clearly incorrect. It should have been a 45 degree mitre cut but was a wiggly curve instead. I built the geometry from scratch 7 times. Oddly, on one instance I found partial success; a partial intersection curve was found but it was not complete. I rebuilt the surfaces one by one to see if the outcome improved. the curve went from edge to edge after that but was clearly incorrect. I did Undo to back up to before I rebuilt the surfaces but, oddly, now Intersect could not find the correct partial curve it had found before and continued to give the clearly incorrect result. weird. All partial and incorrect results that I have found have been irreproducible, too, which is extra weird.
On further investigation, it appears that the failure to find an intersection may be specific to the orientation of the surfaces. Below, I made three orthogonal fillets and the Intersect command found partial answers for two pairs but failed completely for the third pair.
I’ve just confirmed identical behavior in Rhino v.5. I had to manually construct the surface topology to be degree 5, but the Intersect command failed in the same manner. I had also previously confirmed the same in Rhino for Mac.
While I have your attention, there was mention earlier in this thread that the “Rebuild” command would “fix” the problem. Actually, the rebuild command fails to respect the topology of the input surfaces so the result is not an equivalence. Rebuilding a degree 3 by degree 5 single span untrimmed surface into a d3xd5 should be a NOP (no-operation) or identity operation but, in fact, the new surface will not even maintain tangent directions at its degree 5 edges.
This is an additional bug also persisting since v.5.
Could you please post the .3dm files that demonstrate these problems.
I think the problem with the G2 fillets is an intersection point with a 2nd order tangency. The best case for me are transverse intersection, where at every intersection point the surface normals are pointing in different directions. Cases where the surface are tangent I try to use the surface curvatures to find the directions of intersection curves. However in your case, not only are the tangent planes the same but the curvatures are the same as well. So I need some more refined test to deduce the intersection directions.
That sounds like an odd way to find an intersection. You say these surfaces are “tangent” with “the same” curvatures but that is clearly not the case. The magnitudes of the curvatures may be numerically equal at a given intersection point, but the directions of the curvature vectors are in orthogonal planes. I’m not a linear algebra guy but I would think there’d be some way to set the difference between the equations of the two surfaces to zero +/- TOL and solve.
Also, the algorithm is finding partial solutions for the intersections with the vertically oriented fillet and the other two, it is just not finding anything for the two that are oriented horizontally, so it seems to be a matter where the orientation of the parts has a bearing on the quality of the solution, hardly an affine state of affairs. I would think some digging into the code would yield an axis-specific error of some sort.
Finally, some experimentation with the exact placement of the CVs will yield complete solutions sometimes. In the attached V.5 file, if one builds the surfaces from BlendSrf using the defaults then the Intersect command will find exactly one of the three intersections, but it will find the complete intersection, not just a partial solution, so it seems that the exact relative positions of the CVs is important. In V.7 the default BlendSrf CV locations seems to be slightly different and the results are different from those obtained in V.5. In either case, manually setting the CVs to the default locations generated by the FilletSrf G2 defaults yields the same failure.
I disagree that both curvatures are zero except at the actual, instantaneous edges of the surfaces; this is easily verified within Rhino using curvature analysis tools.
The zeroth CV defines the edge position (G0); the first CV away from the edge defines the tangency direction at the edge (G1); the second CV away from the edge defines curvature at the edge (G2); the second CV being collinear with the first defines zero curvature at the edge but the third CV from the edge being not collinear defines the slope of the curvature graph as being non-zero, i.e. the curvature is not zero except at the edge. If this is the U direction then the uniform zero curvature in the V direction (since these are straight sections) necessitates that the local V direction is the normal to the plane containing the principal curvature, if there is one; there is, so the curvature in the U direction is the principal curvature. Likewise for the other surface, and those two planes perpendicular to their respective local V directions and containing the respective maximum curvatures are orthogonal because the surfaces were initially built orthogonal to each other.
Even though both surfaces are “nearly parallel,” I would think it still possible to discern that the instantaneous curvature vectors at a given point being in orthogonal planes generate direction info to find both the distance between the surfaces and a direction to search for closer approach via evaluation of a gradient. As previously stated, I’m not a linear algebra guy so maybe I hope too much against the vagaries of 64-bit double-precision computer architecture…?
Did you rebuild one surface or both surfaces to generate the intersection curve shown in your image? To me this looks to have been the result of the two surfaces having slightly different slopes at their edges, indicating that their zeroth and first CVs are not locally coplanar as in the original problem.
Here is the result from Rebuild on the green surface, which also loses tangency at the fillet edge in the amount of more than 11° (which is unacceptable):
I’m not sure what your objective is in pointing to the inconsequential trivial curvature case at the periphery. That point should have been found long before any curvature-based part of the Intersect algorithm was entered.
Everywhere in the interiors of both surfaces the curvatures are non-zero and also non-congruent between surfaces; and the instantaneous slopes are non-zero and non-congruent. The display pipeline clearly “knows” where the intersection of these two surfaces is; why can’t the geometry engine find it?
My objective was to point out that it is consequential and avoiding these conditions will produce better intersection results.
Multiple of the later stages of the Surface-x-surface intersection algorithm depend on previously found intersection points and the directions of incident intersections curves at these points. The intersection direction is deduced from the surface normals in the case of a transverse intersection point. At an intersection point where the surfaces are tangent with distinct curvatures the curvatures are used to compute these directions. At a tangent point with common curvatures I need another technique.
No, I won’t be avoiding the creation of adjacent, intersecting G2 surface fillets while using the world’s preeminent surface modeling tool; I do expect it to be able to find a basic mitered corner intersection between two surfaces, and to find the simple frustum slice intersections documented by @davidcockey.
