It seems from the forum that intersection results have too many knots and people waste time cleaning up the results.
If this is indeed a problem I’d like to collect some example here and get a You Track item opened for it.
As background I’ll explain some of the issues. The divide and conquer approach that SSX takes results in a bunch of intersection pieces that need to be concatenated. Furthermore they come with 2d parameter space curves which have generally matching parameterization. Another issue is the surface tree decomposition used for geometric calculations. This takes a surface and breaks it us into smaller bi-bezier patches, but it currently doesn’t record if the break was at a knot and what the knot multiplicity was. If I knew that adjacent spans joined smoothly I would know that the ideal intersection curve through there is smooth (at least for a transverse intersection).
I’d chime in on this just to say that on work where I need the highest quality, I never expect the first intersection to be my final trim object. I would agree that the intersection curves COULD certainly be cleaner, but cleaner is very much a subjective sliding scale. My personal opinion is that if you care about this level of quality, then you are (or should) be rebuilding your trim curves regardless. So much more control that way, and better quality.
Here, a 40 unit-wide 3 x 3 degree, 4 x 4 point surface is intersected with a plane surface at 0.01 model tolerance. The resultant curve has knot multiplicities of 3,3,3,3,3,2,3. In this case, the curve is actually G2 continuous through all the interior knots, but this isn’t always the case when intersecting smooth surfaces. G2 continuity is more guaranteed with knot multiplicity <= (degree - 2).
I was able to create intersection curves with only simple interior knots by creating an intersection curve at 0.001 tolerance then either rebuilding or removing knots (by RhinoCommon methods) using the remaining tolerance of 0.009 (0.01 - 0.001).
So you’re saying that functions that use surface-x-surface intersection results to build trimmed surfaces or polysurfaces, (like Trim, Split, or Boolean) have these ssx results built in as edges. To rebuild this edge you would have to extract the face, dup the border, replace the edge with your preferred rebuilt edge, retrim, join. Quite a messy process.
I assume the issue is that you you are building a surface off the intersection result and the extra knots make it a mess, for example unintended splitting at fully multiple knots that get interpreted as kinks. Is this correct? Are there other downstream workflows where the extra knots are a problem?
Yes, if the continuity of the curve is as expected, then dealing with G0 and G1 seams is minimized such as when using _FilletSrf on faces are created by _ExtrudeCrv of intersection curves.
A more direct example uses _Sweep1 with _Style=AlignWithSurface. The red surface in the image below was made using the intersection of 2 surfaces (1 is hidden). At 0.1° tolerance, 2 of the edges on the side opposite the intersection are G0 and the other is G1. The green surface was made by first replacing the edge with a rebuilt curve using RhinoCommon. The face’s interior knots are simple. Unfortunately, the relevant parameter space curve of the white face has 331 control points.
