ShrinkTrimmedSrf ...almost

Here is the difference between “ShrinkTrimmedSrf” and “ShrinkTrimmedSrfToEdge” on a bent pipe with end trims.

How silly is that ? Why make a shittty command, plus it’s actually working version ?
Imagine if “BoundingBox” was vaguely bounding objects, and that you needed to run “BoundingBoxWhichIsActuallyABoundingBox” command to get it done properly !

Anyways, I wouldn’t care too much if there was a Rhinocommon “ShrinkTrimmedSrfToEdge” equivalent, but there’s not, and therefor, I can’t use it inside Grasshopper.
And THAT, my friend, is really pissing me off.

Hello - on an arbitrary trim subject to tolerance it is very likely that the underlying surface will be shrunk so that the trim curve is not on the surface. If that is OK with you, then feel free to use the ShrinkTrimmedSrfToEdge command.


I don’t understand what you mean.
In my example, it is pretty obvious that “ShrinkTrimmedSrf” is doing a very poor job.
If you could give me and example where “ShrinkTrimmedSrfToEdge” would not work, I’d be interested to see it.

But if you read my words carefully, you will see that my real problem is that “ShrinkTrimmedSrfToEdge” (the “works as advertised” version of “ShrinkTrimmedSrf”) is not available in Rhinocommons.

If you could give me and example where “ShrinkTrimmedSrfToEdge” would not work, I’d be interested to see it.

A trimmed surface with more than 4 edges

The use for shrinktrimmedsrf is that it gives you a nice more even patch like surface. For your case it’s not what you need.

Also seems a tolerance issue thing according to Rhinos command library in the shrinktrimmedsrftoedge description “Shrinking the trimmed surface can sometimes cause problems later since having the edges so close to the trimming boundaries can cause commands that use the surface edges as input to fail.”

Hello - the problem is not that it will not work - it will shrink. But for non-isocurve trims, the trimming is subject to file tolerance for accuracy. So knowing exactly where the shrinking should stop is not possible with arbitrary (non-isocurve) trims - it can be that the edges will be outside the shrunk surface by some small amount. This is generally worth avoiding, especially if exporting to other software.


OK, wait a minute folks…
As I understand it, shrinking finds the first 4 isoparms (EAST, WEST, NORTH and SOUTH) of the underlying surface that “bump in a trim curve”, and makes what’s inside of these isoparms the new underlying curve.
Of course there are tolerance issues ; there are tolerance issues with ANYTHING going on in a computer.
Why isn’t this a problem with Bounding boxes, and such a fuss-fest here with shrinking ?

An why isn’t “ShrinkTrimmedSrfToEdge” accessible in Grasshopper ?

Why isn’t this a problem with Bounding boxes, and such a fuss-fest here with shrinking ?

I think because bounding boxes are not really ever always on the entire geometry, unless the bounding box is just bounding a box :smiley:

An why isn’t “ShrinkTrimmedSrfToEdge” accessible in Grasshopper ?

Lots of stuff are not accessible in Rhinocommon or exist as a combination of using multiple methods, it has always been behind Rhino development. But also keep in mind that Rhinocommon is made so devs can use it, maybe some stuff McNeel doesn’t want played with (maybe trade secrets) but more than likely it is just that Rhino develops faster. It could also be that ShrinkTrimmedSrfToEdge is a combination of Rhinocommon methods that are not so obvious to us. The latter is my guess. Just because it is a command in Rhino doesn’t mean it is a single neatly wrapped method in Rhinocommon with the same name, Rhinocommon tends to be a bit deconstructed so it is easier for devs to not be locked into just having the limitations of the Rhino commands, kind of like GH.

Also, you might start a request thread for it to be added to Rhinocommon. Seen that multiple times and they will add it in :wink: but it will most likely be added in to a future R6 version (dunno if you are using R5).

Well why don’t you add the equivalent of the absolute tolerance instead of letting all that insane amount of doe extend out the pie-plate ?
That would be plenty fine with me, but those tools that don’t do what they advertize really make no sense.
ExtendSrf is another one that comes to mind.
Whatever extension value you enter, you can be damn sure the surface will never be extended by that value.

Hello - please see the attached file.

ExtenSrfBy10_SetBasePoint.3dm (51.8 KB)


I know, I know…
Here’s what I replied to you last time.

In a nutshell : forget about algorithmic convenience ; think “user needs” !

So here goes my official wish :
Please add a “tightness” option to the “ShrinkTrimmedSrf” ; tightness being the min. distance between the edges of the shrunk surface and the trimming curves.
That way, you will replace a tandem of “useless version + risky version” tools by one that is actually useful.
As a bonus, you could conveniently upgrade the Rhinocommon “ShrinkFaces” with that argument.

This was mentioned before, but anyways…
In the past, users have had problems importing shrunk geometry from Rhino into other CAD programs. With the current settings of ShrinkTrimmedSrf, that problem has gone away. If you don’t need that command, don’t use it.

As for RhinoCommon, Pascal added RH-50712.

If you allow the user to set how “tight” the shrink has to be, he can always choose a value that will work for him.
As I said already, tolerance issues are everywhere, but dumbing stuff up is not my idea of a solution.

1 Like