I’m posting more and more trim failures in Rhino these days…
I want to create a hole in this surface and I can’t. The trim line was generated from a different intersection surface which was able to be trimmed… but this side refuses to and I don’t know why (yet).
traimfail99.3dm (159.0 KB)
(PS. I don’t need workarounds. An extrusion made it work, but still… I feel that the intersecting surfaces should just have been able to do a mutual trim in the first place…)
Hello- it would be helpful to have the other object - is it a surface or a poilysurface like this one?
-Pascal
I found the “error” in the other object. I haven’t found the error in these lines, though. Rhino tells me it’s a closed curve, which should then trim?
hey there , i was reviewed your file, so, I found a trouble with a surface, there a bunch of controls points overlaping each other, so import to have clean surfaces to avoit issues to cut, bolleans etc, I’ll attach the file fixed.
As mentioned I don’t need a workaround, but this is interesting information (which Rhino could easily have output as an error message). Because again, if you just extrude the curves and trim with those it works…
I’ve said it before, but McNeel employees tend to brag about “accurate trimming”, but when it comes to being error tolerant and heck, general trimming with curves, it’s pretty bad in my view.
Hello- One thing to keerp in mind is that trimming a polysurface is a different thing from trimming a surface, so a way out is often the explode a polysurface or extract the faces first when trimming with curves. That works in this case.
-Pascal
Again, why waste a user’s time with this? Why can’t Rhino handle this internally on its own? So many things in Rhino is such a manual and tedious process, which other CAD packages have automated a long time ago.
i agree these operation should have been fine tuned by now
I agree and disagree, I think that this is both a weak and strong point of Rhino, it let’s you do stuff where other programs just succeed or fail, and in the latter case leave you empty handed. I use the explode-before-trim trick in most cases if trims fail. On the file you posted I also noticed that pulling the curves toward the object will also work to trim the PolySurface.
I logged RH-72024 Trim Polysurface with (Poly)Curve fails
Rhino often gets confused how to trim/split a surface or a polysurface with a curve intersection while the latter is placed directly on it. Most likely it’s related to the fact that the curve intersection lacks one or a few control points that otherwise would make it perfectly laying on the surface. It’s a thing related to file tolerances.
Another common “bug” happens while trying to trim/split a surface at an extreme angle that confuses Rhino due to the file tolerance being too low. This is why the majority of those bugs could be resolved by trimming/splitting the surface(s) while the file tolerance is temporarily bumped 10 or 100 times. This topic explains the bug and the workaround for it in more details:
Oh, how about that! 
PS. Yes, manual option is good, but it should be an option. It’s Computer Aided Design, and Rhino could aid a lot more… 
I agree, hence my report 
Was cleaning out my files and I actually had an older example of this that I don’ think I had posted…
So again, yes, explode first works, but why should I have to? Where is the aid from Rhino? Why is Rhino wasting the user’s time when this clearly could be automated internally?
unexploded-wont-trim.3dm (482.4 KB)
thanks for the file, I logged this one as RH-72109 Trim Fails
FYI _DupBorder on the Green, then _Trim also works as workaround. This is another thing I often use.
IIRC, the explanation for much of the discrepancy that one sees is that there is a difference in how the Brep-Brep and the Curve-Brep intersectors work. The curve intersector might pull the curves to the surface if they are not far out, which doesn’t necessarily happen with the surface intersector.
In this case, if I run intersect on that example, it does give a closed loop intersection. So that makes me expect it should trim correctly without workaround.
another workarround (sorry if already mentioned:)
_intersect
or
_intersectTwoSets
use the resulting curves to trim or split
nice side profit: the intersections also help to understand or find geodetical issues if trim fails.
Well, I’m not sure if the actual surface trim function uses those curves to trim or not.
To trim or split a polysurface with a curve in a non-plan view the curve or portions of it must lie within tolerance of the polysurface.
As you can see this curve pulls off the polysurface in two places. These gaps prevent the curve from splitting the polysurface.
For trimming or splitting a single surface (at least in this case: non-plan view, …) we will use pullback to create the trimming curve on the surface. So as you noticed it works on a piece by piece basis.
However pullback is not used for polysurfaces because pull back of a smooth curve across a crease can produce a discontinuous pull back.
PolySrf_Pull.3dm (38.9 KB)
@GregArden
thanks for your explanation.
ok - and doing stuff with multiple knots or Degree 1 will result in ugly trimming because pullback is used…
trim_extreme_pull.3dm (51.5 KB)
so maybe the trim-function should check for those situations regardless whether it is a single or polysurface ?
if this checking is applied, it will also be able to inform the user about why trim failed or the result might be unexpected: something like this: trim resulted in gaps / steps along seams / creases / etc… see dots…
I like the Idea of having an option for
pull
project
curve on Surface only / within tolerance
for the trim command, or an trimAdvanced version.
EDIT:
also _pull command does not handle this special case.
so maybe a nice option in the pull command would be to allow polysurfaces and report destroyed Continuity - “resulting curve has 1 unexpected gab ?”
kind regards -tom
