How to force trim to always pull curves to its surface?

The most frequently encountered error for me in Rhino is trim operations done in perspective view, which don’t pull the curves towards the surface for one reason or another. Sometimes it’s really obvious (like when it defaults to the cplane and just destroys the surfaces) but sometimes it’s more difficult to spot.

The above surface for example, has a closed polycurve that I even separately, manually pulled to the surface, and STILL the trim doesn’t do it properly.

I know commands can be scripted in Rhino, so I’d just prefer to always have my trims to be pulled, regardless of how Rhino internally interprets the curves. Can anyone help me accomplish this?

yeah, some time the trim doesn’t pull the crv also if in prospective.
my guess is that Mcneelies changed the behavior and only 3D curve where pulled.
A 2D crv do not also if in perspective.

Do you mean project not pull?

Pull, changes the curve because it is pulled along surface’s normals. Project is done according to the camera. AFAIK, trim projects the curve orthogonally you should not use Trim or Project in perspective view.

I mean pull, because the surface is 3D and an ortho view is not.

For this very reason, I prefer to use “Extrude straight” (! _ExtrudeCrv) or “Extrude curve normal to surface” (! _Fin). Then I use the resulting extrusion as a split object.


Wonder if that can be “baked” into a single button, similar to what @Pascal did for me here, including deletion of the temporary extruded object?

That is the answer to your question asked in your subject line. .

If it doesn’t work that probably means there is something wrong with your surface. For instance, Pull may fail to work correctly with degenerate geometry. There is no way of telling by looking at your picture

It is also possible that the pulled curve is to close to the surface’s natural boundary. Rhino won’t trim off a sliver that is less than the document tolerance. In that case you may get a better result5 if you extend the surface a little before trimming.

I said it a few times in other topics before: The best way to accurately trim or split a surface or polysurface is for Rhino to be programmed to use 10 times higher precision than the absolute tolerance for the “Trim” and “Split” commands. For example, if the absolute tolerance is 0,001 mm, then the trim tolerance should be 0,0001 mm. Trimming works considerably better if you temporarily change the tolerance to be higher during that operation, then you can revert to the regular state.

Since Rhino (still) does not have that functionality, it often produces inaccurate results after split or trim of an object, no matter whether those commands are executed in isometric or Perspective view. Trimming or splitting with a trimming surface/polysurface also produces these unwanted errors.

Here is the topic where I explained the issue in detail:


Hello - The simple way out is to set your file tolerance to .0001. Split/trim/project are functions that, so to speak, make the most use of tolerances. What would the larger one be for?


Setting the absolute tolerance to a very small number (with more zeroes) brings too many problems with file density caused by extreme amount of control points of the created surfaces (especially if you use “Blend surface”, “Match surface” or “Offset surface”). While “Match surface” and “Offset surface” both provide options for custom tolerance, the “Blend surface” command suffers a lot by sticking to the file tolerance instead.
Here is a simple example where 4 identical sets of two extrusions were used to create a blend surface in-between. Every blend surface was created at different absolute tolerance to show the huge impact of the latter over the control point density:

Split and Trim custom tolerance.3dm (107.1 KB)

This is why I don’t consider using very tight absolute tolerance as a general solution for the shortcomings of the “Split” and “Trim” commands (as well as “Project curve”) while using them in cases such like the Tolerance test.3dm that I uploaded in the other topic from my link above. :slight_smile:


Hello- What tolerance would you expect Join to use then? The larger one? If so, what is gained by trimming at the smaller tolerance? If not, then surfaces created at the larger tolerance will, very possibly, not join. I’m not convinced, yet, that anything is clearer or more workable in your scenario.

Maybe a macro, for now, to get those difficult trims:

! _-DocumentProperties _Units 
_AbsoluteTolerance .0001 _EnterEnd
 _Trim _MultiPause _-DocumentProperties _Units
 _AbsoluteTolerance .01 _EnterEnd

(BTW, re: your blend example - the testTrimRefit tool in V7/WIP untrims that left-hand extrusion nicely and allows a simple BlendSrf. That is a test command at the moment but the hope is it will be ‘real’)




This looks promising! Is there any way to squeeze a _fin command in there and use the result to trim with, and then delete the fin surfaces? (That is, to fake the trim by surface normal that Rhino is apparently lacking?)

Thanks! Your macro did the job perfectly! :slight_smile:

Let me explain the issue with using default tolerance setting for trim/split. The attached file below (which I also had in the other thread from the link in my last post above) consists a surface and a curve. If you try to split or trim the upper left corner of surface with the curve while at the default absolute tolerance of 0,01 mm, the trim/split will fail, because Rhino ignores the fact that the curve intersects with the surface by 0,008268 mm. However, if I temporarily set the absolute tolerance to 0,0001 mm (or if I run your custom macro), the split/trim works as expected and the resulting split surface is accurate.

Tolerance test.3dm (158.7 KB)

This is why I proposed to add an optional separate setting for the “Trim”, “Split” and “Project” commands in the Rhino options panel, which allows the user to set a finer tolerance just for these 3 specific commands, while the rest Rhino commands stick to the absolute tolerance.

I can’t try Rhino 7 WIP since it’s not available for users of Evaluation Rhino 6, but on your screen-shot I see one improvement in “Blend surface” that I pointed out recently - the inability of the end handles to align to the same direction as the edges of the target surface. It’s even shown on my screen-shot in my post above where the split surface caused irregular flow of the blend surface as the latter tried to be perpendicular to the split edge. Is it really possible to align the handles in Rhino 7? That would be a huge benefit in many situations. Recently I also faced similar case while I created a blend surface between two surfaces created by the people behind the XNurbs plug-in. Their 3d model was posted in another thread as an example where they claimed XNurbs achieves better result than any other Rhino tools. Then I proved that several Rhino tools achieve considerably better result than XNurbs in that particular example, but in order to align the sides of the blend surface I had to use some tricks such like “Match surface” with the “Match target isocurve direction”, as well as two blend curves as a guide for the blend surface. The other workaround was by using “Sweep 2 rails” instead of “Blend surface”. I wonder how Rhino 7’s “Blend surface” will behave there. Rhino 6’s “Blend surface” showed quite messy result while G1 or G2 is used. However, if G0 is used, followed by “Rebuild surface UV” and then “Match surface”, it works properly. This is the file:

Rhino tools are superior in this scenario.3dm (1.4 MB)

P.S.: Alias has refit setting for blend surface and match surface for years, so I’m happy to see that this very important option is being implemented in Rhino 7! :slight_smile:

1 Like


The behavior is intentional. the idea is chopping surfaces up into slivers smaller than the tolerance is a bad idea that can cause downstream problems. You may be better off extending the surface a little bit or using split by isocurve to get the result you want.

I don’t really object to a tolerance override whenever the user wants it, I’m just saying in this case it may not be in your best interest to use that strategy.

Usually the purpose of creating trimmed edges in Rhino is as a prelude to joining that edge to another surface’s edge. I don’t know why you find yourself in this situation so i am only guessing whether it is a good idea or4 not.

Also, your idea of having the option in Blendsrf to match by isocurve direction instead of perpendicular to an edge would be a good improvement.

That particular trimmed surface was exactly part of a polysurface with offset thickness consisting multiple joined surfaces. I fixed it by temporarily using a 10 times tighter tolerance just for the “Split” command, then I reverted to the regular tolerance. Everything worked smoothly with the “Join” command that followed the splitting. Without that “hack” Rhino refused to split or join the surface and created a bad object.

In the past I used to untrim and extend the surfaces, then I trimmed them again. However, that led to some issues with other edges of the surface that no longer were able to join the adjacent surfaces. Keeping the trim objects while untrimming also didn’t preserved the original shape of the trimmed edges prior the “Untrim” command. But the tolerance “hack” works 100% of the time. :slight_smile:

Many times Rhino has similar issues while trimming surfaces or polysurfaces at a steep angle (not necessarily 1 degree or less; sometimes failed even at 5 degrees or higher), such like the example below. Note that this is an exaggerated result made by purpose, because currently I don’t keep an existing problematic 3d model to upload as an example:

It also happens when trimming a polysurface at a steep angle with smooth Pipe, despite the perfect match between surfaces prior the trimming. Sometimes the resulting split polysurface will have both edges of its surfaces being separated by a tiny amount which is enough to cause problems with the “Join” or “Match surface” tools. However, the tolerance “hack” solves the issue.

As for the purpose of using trimmed surfaces, I see the biggest benefit of them where 3, 5 or other number of surfaces meet together, as well as where the edges of the original surfaces are removed to be replaced with “Blend surface” or other type of surface that continues the existing shape in a way to follow the design intent. A few examples with trimmed surfaces combined with blend surface:


Match by isocurve direction is good normal workflows. I feel so lonely in this technic…

Yes, I often for trimming increase the tolerance (just for trimming and then I return back to the default one). Can create problems. I try to shrink or better cute isocurve. The tolerance “hack” also can create lots of points. I try to be as minimalistic and stingy as I can with my points. I often use a radius for the section and one acceleration point (ellipse) for the main master curve. I try not to use trim. Only when is a hole. I often expand the surface a little and set the control plane in the view direction before trimming.

Thank Pascal for the macro.
Remember that using the macro and aborting by pressing ESC, the absolute tolerance will be change to 0.0001 instead of the default one (0.001). So there is no Undo for this operations.

1 Like

The tolerance paradox hence intolerant of it.
Workable tolerance must be between 2 parameters instead of one?

The UI tolerance is in function of rhino and not the user need. But probably is better for the user to be the other way around. I need little tolerance for game dev but default or much more for trimming. In the FBX I do not need all that precision and file is much bigger.

“Blend surface” needs many improvements (I already proposed some last year in another topic here), but the 5 critical ones are these:

  1. Add possibility to align each individual handle to the tangent direction of the side edge of the target surface. Imagine something like what blend curve does. Currently, the handle could be adjusted manually “by eye” while holding the Alt key. Maybe you can call this option “Match target end direction”. :slight_smile: That way, the example above regarding the 3d model with the XNurbs patch will be no longer an issue for the improved “Blend surface”.

  2. “Match target isocurve direction” already exists as a global (applied to the whole length of the edge) option of the “Match surface” tool, but it will be amazing if it could be part of “Blend surface”, too. And make it as an individual setting for each of the handles, rather than forcing the entire edge to follow suit.

  3. Add tolerance settings similar to what’s already implemented in “Match surface” with the “Refine match” distance. I think that Pascal mentioned something similar that’s currently in a test phase in Rhino 7 WIP.

  4. Add an option to avoid creating of extremely dense rows of control points, by using “Mininum distance” as an input. Example: If you set the minimum distance to 2 mm, Rhino will create a blend surface whose control points will be distributed in such a way that they will never be closer than 2 mm from each other (the entire length of the edge must be longer than 2 mm, of course). Or use a percentage of the whole edge length as a limit amount.

  5. Ability to apply an adjustable “Planar sections” handle whose orientation could be conveniently modified at any time during the command. By default, once activated, orient the direction normal to the center of the preview blend surface". In many cases this is usually the most usable solution for open blend surfaces (ones that don’t blend between pipes etc).

Here is what the current “Blend surface” of Rhino 6 does at its best:
Note the top surface that was trimmed by two curves.

By default, “Blend surface” does this unnatural transitional shape, because it aligns the control point rows to be perpendicular to the target edge.

Applying “Match surface” with the “Match target isocurve direction” option fixes the upper right corner, however, it’ incapable of redirecting the control points around the upper left corner to follow he shape of the upper target surface. There is no way to smoothly align the left side edge of the blend surface to blend between both left edges of the target surfaces.


There is, but it it’s expensive and cumbersome, because you have to pay for and install Alias, and then export the surface to it and use “edge align”, and then import it back into Rhino. :wink:

But we’re way off topic now, and I still don’t see a solution to my original question (unless I missed it in all the unrelated (yet still important, though perhaps futile posts). :stuck_out_tongue:

1 Like

yes there is, whith a little workaround: Use extend to extend the side edges, then snap the handle to those: