Poor result on trim after draft

Why does many of Rhino’s tools which operates on surfaces/polysurfaces not split its result into several smaller surfaces, rather than outputting an insanly complex single surface (like fillet edges and tapered extrudes do)?

Here’s an example I ran into just now:

drafttrim.3dm (131.2 KB)

Even if I adjust a custom render mesh to a really, really high resolution, the glitch remains.

But no wonder really, that draft surface has 141 spans!

Can someone tell me what I can do with that surface? I mean, what workflows does experienced Rhino users use to edit such a surface?

EDIT: After rebuilding it and accepting a 0.1mm deviation, I was actually able to put a fillet on it which I’m very impressed by… but that fillet is equally crazy (though it works)…

But as I suspected I’m not able to join this drafted surface with the one from which it was originally extruded, so I still suspect I’m using the software in an unintended way, though perhaps that should be a different topic because that’s not what I originally posted about…

Hello - I can’t see for sure what you started with but your comments make me think the input was a trimmed surface edge, is that correct? Extruding tapered pretty much always makes surfaces more complex than the input curve, the less planar the input, the higher the angle and the deeper the extrusion, generally, the more complexity. But starting with a trimmed edge curve is only going to densify things more. Can you post your inputs to the surface?


I know that trimmed edges are usually more complex, but when I used Duplicate Edges on them, I was very pleased to see that they had a very reasonable topology… unless Duplicate Edges actually rebuilds them first?

draft.3dm (110.6 KB)

Also, pretty consistently when I attempt to use the Extrude Curve Tapered I get this result:


So it seems to me it’s either a crazy complex surface with manual work to rebuild and re-trim afterwards, or frayed surfaces with also lots of manual work?

Hello - just to see if there is anything on the right track here - have a try with this python. The UI is a little, er, underdeveloped at the moment, but it may get you what you want… Dup the edges of your surface and Join, then use this thing and set the angle to 30 (or -30, you may need to change it if it locks on the wrong way)

You should get this, for example:


FinTools.py (12.7 KB)

This is a little different than the ExtrudeCrvTapered since it is based on the normals and not the CPlane or extrusion direction, but in this case it amounts to the same thing, I believe…

To use the Python script use RunPythonScript, or a macro:

_-RunPythonScript "Full path to py file inside double-quotes"

@eobet - I updated the script, above- I think it is better now, if not quite right yet.



Wow, that’s absolutely amazing! And the UI is even better than the built-in tools, because it says the angle and length right there in the viewport! I mean, that’s pretty close to the Alias msdrft tool even, so that’s pretty impressive.

Two issues what I’m having a difficult time working around, though:

  1. The typed values and the visible values don’t match…

  2. Values on the second curve also end up being completely different (and no chainselect)…

(Oh, and I just noticed that you can’t press enter/right mouse to finish the command either, you have to click in the viewport.)

Is this going to be included by default in Rhino at any point?

Hm - the reported and asked-for angles should match, though they might be reversed (e.g. 135/45) - getting all that to work just right has been a challenge … but I’ll try it on your surface again - it seemed to do OK the first time through.

I see some goofiness… one thing is, if you dupEdge and join it all up before hand into one curve it works more easily, but yeah, I see I need to massage this a little - thanks for testing. Now that I think about it, I did not do a lot of testing other than on untrimmed edges and isocurves… I would not expect that to matter in this way but it seems something is amiss in your example file.


1 Like

That worked! And it’s so smooth, I love it.

I wonder if that super smooth performance comes from the fact that the resulting surfaces are only G0 instead of G1 or G2, though.

Still, this is ways better than the built-in tools. Is it normal angle at every point on the surface even, or does it just sample a single point?

Oh, and I managed to make it crash when I was testing the above question myself on this surface:

fin-crash-example.3dm (80.7 KB)

Thank you so much for making this, and let me know if you want me to test more! :slight_smile:

Hello - ideally it should be normal at all points BUT it is specifically making a simple surface rather than an exact one.
I’ll check the crash…

Thanks, I see the crash, I’ll see if I can figure it out… looks like it is in making the preview surface.

@eobet - I can stop the crash but there is definitely a problem with single continuous edges like that.

I don’t know what it is yet. I do not have it working beyond failing more gracefully. There is a ‘FlipAngle’ option added here as well:
FinTools.py (13.5 KB)

@eobet - just as a possible workflow with this thing, Project a curve with Loose=Yes, then use this tool to ‘fin’ the resulting curve and then, if needed, MatchSrf the result back up to the surface (CurveNearSurface=On) with Refine on to get the edge of the fin within tolerance of the surface (and still get a far cleaner, simpler result than working from a ‘true’ projected curve and ExtrudeCrvTapered.


1 Like

Thank you for the update, and sorry to throw a wrench into you script with the closed curve. I just wanted to test something quickly. I’ve never actually used the ellipse curve tool before, and am much more interested in using several curves with blends between them.

The angle is now accurate between the viewport editing and the angle you enter in the command line, but interestingly, before if I entered 30 for distance, the viewport would say 29, but in your last update when I enter 30, the viewport says 31. :slight_smile: