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

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’)

image

-Pascal

3 Likes

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

Yes

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:

2 Likes

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.

3 Likes

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:


2 Likes

Why not blend curves from the surface edges? Then surface from edge curves, surface match preserve isocurve direction.

I often use this workaround, however, it works properly only on flat surfaces. Extending the side edge of a double curved surface sometimes won’t guarantee that the snapped handle of “Blend surface” will translate to a G1 or G2 continuity. “Match surface” sometimes helps, but in certain cases (like the one I pictured above) it won’t. This is why sometimes I’m forced to use blend curves followed by “Sweep 2 rails” and “Match surface”.

Have you tried whether my proposed solution works on your model? :slight_smile:

Thanks , It works fine for me

In theory it should at least match G1 if you extend the edge linearly

I agree, on theory it should, but I noticed that in many occasions the continuity between side edges on double curved surfaces was not even G1, even though the continuity between surfaces was G2. In this case I had to use curve blend and match the blend surface to it.

OK so now you have revealed the real problem - offsetting polysurfaces.

personally I avoid OffsetSrf on joined surfaces precisely because it produces this sort of garbage. In my opinion it doesn’t save any time if you have to deal with fixing all the problems it creates. Better to explode the polysurface and offset and then do whatever extending and trimming needed manually… that way i end up with a nice clean result.

If your surfaces are designed well with good G1 continuity the offset will join nicely anyway. If there are places the offset surfaces don’t join that indicates there was less than G1 continuity on those edges.

No, the real problem is that Rhino does not trim at the proper place like where the trimming curve or surface intersects with the surface to be trimmed. Once the tolerance is temporarily changed to a greater number, the trim works as it should.

The offset surface from my file was just an example where the “Trim” and “Split” tools fail. These tools will also fail with a regular plane withing the same conditions.

As for the “Offset surface” tool, it regularly fails with no reason, despite the original model having perfect G2 continuity between the joined surfaces (using “Blend surface”, or “Sweep 2 rails” followed by “Match surface” with “Refine match” 0.001 mm and 0.1 degree curvature). Having G1 or G2 will not guarantee trouble-free offset polysurface since the command uses approximation with a certain amount of deviation rather than a mathematically exact offset. “Network surface” also uses similar approximation. This leads to some corner edges that don’t match the corresponding edges of the adjacent surfaces and Rhino reports them as “Out of tolerance”.
Also, in certain cases where G1 or G2 is involved, some offset surfaces have completely different shape than the input geometry. This is especially true where “Fillet edges” or “Blend edges” were used. Even a perfect closed G2 blend surface with nicely distributed control points gets split into a number of offset surfaces whose outside edges suddenly change direction where the blend surface fills the space between G1 fillets. I fully understand that, because Rhino tries to use normal direction as a boundary limit for the offset surface creation. However, I have seen many occasions where these split surfaces simply don’t share even G0 along their outside edges.

Take this, for example. Build a blend surface between both extrudes profiles (absolute tolerance 0.001 mm, angle tolerance 0.1 degrees), then check their continuity. Two edges will be G2, the rest two will be G1. Then make offset surfaces of them at 1 mm or 2 mm. then check the continuity between outside edges. It will be G0 on all 4 of them. I can’t find a better example where the edges were out of tolerance, but if I face the same issue again I will upload it here.
Offset surface G0.3dm (146.9 KB)

Sure but the probability of it happening is greatly increased if
you use offsetsrf on joined surfaces

If you have perfect G2 continuity then select the polysrf and do this :
:
Explode offsetSrf
sellast copyclip
undo paste join

I didn’t say it would. I said if you have good G1 continuity you can just offset the individual surfaces and then join the result.

These are also commands I never use precisely because they produce surfaces that do not have good G! continuity. If you make the fillets with filletSrf you won’t have problems with getting the offsetsrf to join.

There is no need for me to look at your example, I am well aware of the problem you are talking about. I avoid those problems by using filletsrf whenever possible.

There is a reason for me to use “Pipe” to cut the corners and fill the space with “Blend surface” instead (mostly G2, but sometimes G1 is also useful). I also use “Fillet surface”, and rarely rely on “Fillet edges” or “Blend edges”. But even when I use “Blend surface” and “Fillet surface”, the “Offset surface” tool sometimes creates very tiny new edges or split edges that cause issues. Sorry to say, but “Fillet surface” won’t solve the problem in some occasions. Maybe your kind of models are less complex, or I’m still a rookie Rhino user. :slight_smile:

I just tried your suggested macro
“Explode offsetSrf
sellast copyclip
undo paste join”
but it also failed to produce proper offset surface despite the joined input surfaces being G1 at either end. I also tried “Rebuild edges” on all input surfaces, then I joined them, verified the continuity again with the “! _GCon” command, then ran your macro and the end result was two offset surfaces that also had G1 at either side. However, after joining of the offset surfaces, one of the edges remained G1, while the opposite one became out of tolerance.
By the way, your macro does crazy things if I use it as a button macro. :slight_smile: The viewport basically freezes and the selected surfaces flash rapidly unless I hit the Esc key. Only copy/paste of the script works.

Doing offset surface on joined surfaces produces a bit different results than doing so on separate surfaces. However, both ways produce some errors in different locations of the models. Since the “Offset surface” command uses approximation based on user-set tolerance, I could imagine that if one of the offset surfaces get a slight deviation in a positive number withing the tolerance, and the adjacent offset surface has an exact or negative number, their shared edge(s) will be at such a distance that “Join” will fail. I regularly check the distance between offset surfaces and they are rarely exact numbers like the ones I used as an input.

Lastly, “Fillet surface” can’t help with automotive surfacing, because it’s just a G1, degree 2 surface that obviously lacks the required curvature and degree to be used for smooth free-form shapes of fenders, bumpers, engine covers etc.