Green rail is able to trim. Red curve is not. Why is that?
trim-fail-again.3dm (470.8 KB)
EDIT: Yes, I’m aware there’s 1000 workarounds for this, btw, I just get failed trims so very often that I want to learn how to get to the bottom of them all.
I just noticed that the file was named “trim-fail-again”, so here’s apparently the first one I saved… same issue:
trimfail.3dm (68.2 KB)
Not sure why it fails. I don’t know of 1000 workarounds but one and that is to use trimming with 3d curves only on single surfaces, in other words, explode – trim – join
Hello - when you trim with a curve, it is pulled to the faces on the polysurface - in this case there are successful pulls to faces which cannot be trimmed with the result. In V7, curves which lie on a face are not pulled but used directly - this trim works in V7…
-Pascal
Sometimes, rebuilding a curve may not only work but give better results, as long as the rebuild is within your tolerances. I notice that even you green surface has what looks like extra segments/extruded-nodes which may won’t make the result any nicer.
Right but that’s the reason I made this thread. Why can’t they be trimmed? Because even in V6 when you do a rail from the exact same curves, they can be trimmed.
Glad to see it’s fixed in V7, but the amount of stuff that only get fixes in V7 is piling up for me now…
The answer is that when the exact same curves are edges it does not stupidly pull the entire curve to all the surfaces to be trimmed. That can create bits of pulled curve pieces that are not intended to be used.
. When it is a surface edge only the parts of the curve that are within tolerance of the surface are used to split that surface. The other side of that coin is the trimming will always fail if the edges are not within tolerance of the surfaces to be trimmed.
However that does not seem to be what is going on here. The reason your curves are failing is because they extend farther than they need to. If the trim curves are shortened so that they don’t extend past the edge the trimming works.
I’m curious how you made those curves, I ask because generally you won’t end up with curves that are extra long if you use the usual methods of getting curves on surfaces (pull, project, intersect etc)
Heh, that’s an old Alias habit. Always extend past what you want to perform an operation on, because you can’t guarantee that stuff aren’t 0.001 off somewhere (or if you want to change trim direction/projection, extending past is much safer).
But thank you for the information.
I’ve made a habit now in V6 to always either fin or rail whenever I want to trim a surface. I essentially never trim with curves anymore since it’s so incredibly unreliable (with “flat curves” not being pulled, no explicit trim direction, etc).
That only works if the curves are on the surfaces to be trimmed (within tolerance).
To make that work you first have to get the curves onto the surface. There is probably a way with fewer steps to do this trimming.
For instance, if you are projecting a curve onto the surface you could just trim with the original curve. In that case it wouldn’t matter if the curve is extra long.
Looking through my myriad of trim threads (hey, isn’t trimming in Rhino just great), I guess this is the most fitting one to put today’s example in (and in the last 5 years, at least I discovered fin):
Any particular reason not to use Pull (not Project) to pull the trim curve onto the surface?
Perhaps it would be better to discover the Pull command.
The way Fin works is it first pulls the curve to the surface and then makes the Fin surface. If you just pull the curve to the surface you can skip a step in your process.
After you pull the red curve the result is selected so you can just run trim and then skip the part where you select the cutter.
Can’t tell you why Trim doesn’t work with the red curve. Trim should also pull the curve to the surface in your example
.
Wow, I didn’t pay @davidcockey or @jim to say this, I swear!
I do agree that the user should be allowed to direct Rhino to do what the user needs done with respect to trimming surfaces with curves. But I think that can only be done effectively if there is first created a dedicated command for trimming surfaces with curves. As long as the option is buried inside a command that can take all kinds of cutters and all kinds of objects to be cut it will never work well.
The option to pull the curve to the surface is already what Rhino is supposed to be doing. What makes you think having an option to tell it what its already supposed to be doing will make it work any better?
Extending cutting curves on the surface to be cut is another example. Making that an option usually doesn’t work either.
IMO the only thing that will work well is to introduce a separate command designed for trimming surfaces with curves. That could give the user improved control of trimming that is targeted only for trimming surfaces with curves.
In some situations Project rather than Pull may be the desired behavior when trimming with a curve not on a surface.
Of course, there are a myriad of ways to trim surfaces with curves.
The question is why the trim command so overloaded?
There isn’t just one Boolean command that works for everything. If there was just one command for all booleans then when a user asks for it to work better they are told that this command has to work for curves and surfaces and meshes and polysrfs and it has to be able to add and subtract so we really don’t have any wiggle room to make it work any better.
That is where we are right now with the trim command. Trim is stuck where it was 25 years ago when everything was crammed into one command and there is no wiggle room to improve it so the myriad of possible improvements are just ignored.
Good point. In the CAD I mostly use at work there are three different trim commands:
“Trim sheet”, “trim body” and “trim and extend” which includes “make corner” that’s crazy useful… I use that literally all the time and it saves so much time (oh, and the commands have “extend” options which are actually useful unlike Rhino which only works in a very narrow use case, as well all having dual tolerance options).