DRec : Doesn't accept rectangle with radius

Hello!

DRec doesn't accept rectangles with radius.

I understand why it happens, because the output without a radius is not the same as with a radius. But this is cumbersome to work around in a way that allows adding radius retrospectively.

Maybe use a fallback routine for the DRec function that checks for 2 parallel sides and a closed curve (to check if its a rectangle) and then calculates the values from the distances between parallel lines, this method would work for manually drawn rectangles and squares.

Thanks for your time, really exciting tool!

Replies to This Discussion

Permalink Reply by Hyungsoo Kim on November 5, 2017 at 5:37pm

This could be a rather simple workaround than your description, i hope.

Permalink Reply by David Ledger on November 5, 2017 at 6:11pm

I agree, but this sort of work around substantially obscures design intent, makes diagrams more difficult to read etc. Thanks for the work around, but i think the deconstruction tool should support it natively.

It doesn't at all limit the tools functionality to support it natively, it only makes it easier to use.

Permalink Reply by Hyungsoo Kim on November 5, 2017 at 6:50pm

Your opinion is understandable, but that's how you understand and use GH.
It's not related to the functional defect of "DRec".
Rectangle with a radius yields a curve(closed planar curve) as a result. On the other hand as you can see in my screen grab, the "R" input of "DRec" wants a rectangle as input data.

In this case, "Curve" and "Rectangle" are recognized as different data types.

Permalink Reply by David Ledger on November 5, 2017 at 6:57pm

I understand, I think this would be a sensible change to the tool though, it would mean I wouldn't have to make large changes retrospectively to designs if I need to add fillets.

It also cannot see how the change would break backwards compatibility.

Permalink Reply by David Rutten on November 6, 2017 at 4:38am

The problem is a deep one, in that the definition of a 'rectangle' in the Rhino SDK makes no allowance for rounded corners. Other apps (like definitely XaraX and probably Adobe Illustrator) do and are subsequently able to retain a higher level of flexibility.

In Rhino however a rectangle is defined as only a plane and two numeric intervals (one for x, one for y). The possible solutions to this would be:

Extend the Rhino SDK Rectangle3d type to include constant radius fillet corners. This can be done, but is a lot of work and will break the SDK.
Create a new type in Grasshopper which is smarter than Rectangle3d. This complicates developing for Grasshopper because now you have to keep two different types in mind whereas before only one was needed.
Remove the Fillet Radius input from Rectangle components. I like this solution because it results in cleaner, simpler code, but it does mean people may need to use two components where before one was sufficient.
Make the Rectangle type smart enough so that it can recognise filleted rectangles and undo the filleting. This is something I can do right now for Grasshopper 1.0 and it in all likelihood would not break actual existing files even though it is technically a behavioural change.

I'll try and get (4) done for Rhino 6 SR1, I might decide to do (3) for Grasshopper 2.0. I sincerely doubt that (1) will ever get done and I dislike (2).

Permalink Reply by David Rutten on November 6, 2017 at 7:19am

I created a YouTrack issue for this: https://mcneel.myjetbrains.com/youtrack/issue/RH-42375

Permalink Reply by David Rutten on November 6, 2017 at 12:26pm

This should be fixed for Rhino6 SR1. Any curve whose control-points lie on a rectangle (that includes filleted rectangles) will auto-convert to a rectangle. The orientation may be lost, since it's a 50-50 change each side becomes either the width or the height. Actually it's worse, the underlying plane of the rectangle can exist in any one of eight different states.

Permalink Reply by Hyungsoo Kim on November 6, 2017 at 1:39pm

Always thankful for your thoughtfulness and hard work.

Permalink Reply by David Ledger on November 7, 2017 at 12:43am

Thankyou! Is that information lost currently with a standard rectangle?

Permalink Reply by David Rutten on November 7, 2017 at 4:30am

As soon as you fillet a rectangle, it stops being a rectangle and becomes a polycurve made up of four arcs, and two or four line segments, or, if the rectangle was a square the fillet radius exceeds half the width, you get a perfect circle. None of the information of the rectangle remains. That will still be true, it's just that, come Rhino 6.1*, the Rectangle parameter will be able to reverse engineer such a polycurve back into a rectangle. Probably not the same one you started with, but it will look the same if you do not pay attention to orientation and seam points.

* The reason this code went into Rhino 6.1 is because we're not supposed to make changes to Rhino 6.0 any more. Too close to release to start messing with it.

RSS