I can’t imagine it being too difficult for a fellow like you.
You probably wouldn’t get a kick out of it, but you sure would relieve the pain of many poor devils.
There is a serious reason why you can’t, curves on rhino are treated in a way that adding a fillet actually lose some information.
You might not see that in a rectangle but look at this: doing 2mm fillet, then 3mm, then 2mm again give wrong results, information was lost!
PS i worked on similar stuff 7 years ago…
http://v5.rhino3d.com/forum/topics/hatch-trimming-and-perimeter-editing
Trimming hatches is still NOT a thing on rhino 6
…
3 Likes
== DUCT TAPE FOR NOW ==
I think there are “different levels” of problems to address if integrating the many good ideas (plugins) that are extending the Rhino Core, and the two most important ones to get right when considering integrating stuff are the “technical integration” (hard, when different parts are designed in very different ways trying to solve different problems) and “integrate the user experience”.
Technical integration
Take for example a Kangaroo Solver trying to iteratively modify a full fledged Rhino Object with all the technical “baggage” that comes with a Rhino object. It would take forever to do what Kangaroo and GH in general can do in a blink of an eye today, because they were designed with “lightweight objects” from start. Only after “baking” you bring the two together. And that’s essentially how it technically must remain being, in order for GH/Kangaroo to remain being practically useful.
User interface Integration
But then we have the user experience perspective, which is an entirely different story. Developing User interface and UX from scratch is even harder than developing plain technology. In part because the “solution”(s) aren’t generic or given. It takes an awful lot of talent, and hard work, to gravitate towards an intuitive and well functioning UI. Integration of existing stuff OTOH is doesn’t always have to be that hard.
So what does Rhino/Bongo/GH (including Kangraoo) already have?
- Rhino Core – Technically OK, UI (um… “usable” but let’s leave it at that)
- GH – Technically suited to its task, UI is actually better than its reputation (OK+)
- Bongo – Technically OK (although well hidden). UI = Catastrophic. No less than catastrophic. Period.
Now look at what combinations if these parts could to to for example Bongo. The hardest thing you can do to make Bongo useful for a larger group of people (who value their time) is to make a better UI (needs total replacement. Period). But a low hanging fruit - which was NOT the path chosen - would have been to make a a .NET wrapper around the C++ Bongo core, then add a few (few) basic component to the GH menu’s - and you have solved half the UX problem with Bongo in a single simple move.
But no. The engine and combustion engineers - as professional and capable as they are in their engine and combustion field - didn’t think that making a useful dashboard was a good idea. They didn’t think that picking that “low hanging fruit” was a good idea. I just couldn’t believe it…
But to sum up, integrating user interfaces is not the same thing as integrating technology. And in many cases different technologies needs to be kept separate while covering the engines and combustion stuff under an opaque coat of useable dashboards. Add a knob here and a drawbar there and off you go. You may end up having a new and much more powerful product much sooner than some of the engine and combustion engineers can imagine, from their perspective deep down under the hood.
OK, now when I got this out of my system I can continue the struggle using the aforementioned bits and pieces wrapping them together with duct tape instead.
// Rolf
2 Likes
Just in case you didn’t catch it the first time: YES ! YES ! YESSSSS !
Please.
Even if it is just some sort of sandbox plugin to gauge viability and feedback. Anything would be better than what native Rhino has at present. Which is Nothing.
And please take a good look at Solvespace. It might not look it superficially, but it is such a beautiful, elegant piece of software. It’s so light it’s not even an .exe. No bloat (are you listening ADesk, Adobe?); no bull (ditto).
5 Likes
Hi @maje90 , have you somehow updated your SuperPerimeterEditor ?
I find that it could really be a great productivity booster for this kind of parts which are everywhere in mechanics, steel construction, and most industries/crafts where free-form is the exception, not the norm :
Yet, the SuperPerimeterEditor doesn’t address the most important issue which is maintaining the tangencies when you edit a corner :
Because of this, I try to keep a strictly polygonal system line , extrude that and fillet the solid.
That way, if I need to change any corner, I can “just” re-extrude and fillet anew.
For someone who has also tasted SolidWorks and the like, this is horrendous, but it’s still better than having to edit a perimeter with fillets without sketch constraints.
Yet, this trick doesn’t work in all cases : if you have a “diverging corner”, you need to make the fillet part of the perimeter, and you are screwed.
All this to say that if only ONE sketch constraint should exist in Rhino, it would be Tangency
(IMHO)
Maybe @DanielPiker his could give this a shot, as a warm-up before a more ambitious constraint solver ?
Something similar to Riccardo’s SuperPerimeterEditor, but maintaining tangential conditions in real time as a corner is edited.
This would require to re-create the corner handles so even filetted corners could be edited.
Daniel, if you remember, I had tried it on my own with Kangaroo and found some limitations.
Any thoughts ?
Sadly not.
I just needed some basic control over hatches (fast simple edits with control points like on autocad and the trimming part)… and received no feedback back then on the v5 forum…
How to add them?
If an arc and a line are tangent, they are supposed to be kept tangent? If not, not?
Just like this?
or
What if i want to add or remove a tangency between segments on an already existing curve?
How can the curve “remember” which segment is tangent with what other?
Is it possible to add some “meta data” on object? I don’t know.
I’m thinking of adding some information on the name of the curve, so a script could “store” information on the object itself.
Then if the curve is trimmed… everything is lost!?
Hi Riccardo, and thanks for your answer.
Keeping it simple, the tool would just review the connectivity of the segments, and for all the cases where a line is tangent to an arc, maintain that tangency when either :
-The arc radius is changed
-Either end of the segment is moved
-The arc center is moved
-The virtual connection point between the segment and the one on the other side of the arc is moved.
Maintaining tangency between arcs could be a plus, but the above would take care of a LOT of typical flat parts.
…what? 
It scares me to dive again into rhinoscript…
It is years that i mostly do grasshopper and c# scripts inside.
There are any way to use directly c# scripts on rhino?
Not today. We always think about adding this feature, but it hasn’t been a high priority item.
2 Likes
1 Like
I instantly tought about this:
I move the green point like you said, should it became like blue or like red?
(what are you using in your video? is that rhino?)
This is how I’d like it :
(It’s Fusion 360)
2 Likes
Yeah. Complete crap.
1 Like
Ok thanks for the reply.
It should be doable or better, integrate-able on my old script.
I can’t give ETA mainly because i have to re-discover how rhinoscript syntax works… and i have to reverse engineer my own code.
If i’ll do it it will be as proof of concept… nothing serious.
I’ve been struggling with these filetted polygons in Rhino for 20 years ; it can wait a bit longer.
’ will probably give it a try on my side with Grasshopper when I can find some time…
So it seems you are after an arc tangent to 2 curves, with given radius.
I realise you are ultimately looking for something fully integrated and interactive, but here’s a general geometric principle you can use for this that also covers the case with diverging lines where a simple fillet won’t work:
fillet_radius.gh (13.9 KB)
Note that the direction of the lines matters to get the offset on the correct side.
Thank you Daniel.
Here’s how I imagine this tool :
-Reference the fileted polygon
-GH analyses the characteristics in terms of a chain of segments ; these segments being either a line or an arc ; as well as the continuity (tangent or not).
-In cases of a “Line-Arc-Line” connectivity, create a handle at line intersection
-Create handles also on each segment end, and arc centers
-Let the user move the handles and re-calculate the chain in real time ; initial tangents must be maintained.
-Allow change of radii for any arc.
When moving any handle, degrees of freedom should be locked as in my Fusion example, or else the outcome becomes un-predictable.
There 'ya go, piece of cake !
2 Likes
In Bongo this is called IK (Inverse Kinematics). 
Only thing is that you have to explicitly define everything yourself, no assistance/suggestions from the software, which is what UX is all about.
// Rolf
That’s unfortunate.
I hope RMA may change their minds and raise that priority.