When I Construct two cylinders in two different ways (with curve/GH, and direct draw in Rhino) and then Deconstruct them and Construct them again, the resulting cylinders are different . The Brep version gets the radius wrong, and resizes when rotated, and the axis direction is from top --> down, while the curve based cylinder constructed in GH behaves as expected (doesn’t resize during rotation, axis direction ccording to the direction if the inital line, etc). Identical
The Brep (the lower cylinder) seems to have a problem stemming from
Brep.GetBoundingBox() while the same code (
Brep.GetBoundingBox()) works fine on the first cylinder which were created from a curve/line (upper definition).
Why is this? And how do I properly deconstruct a cylinder so that it doesn’t matter how it was originally created?
Fig. 1. Two Cylinders created in two different ways - one from a curve, and the other one by direct draw in Rhino (passed on into GH via Brep):
Similar component in this example code, although here using a C# Script component so it can be shared:
DeconstructCylinder_Forum_CSScript_RIL.gh (7.8 KB)
That file still has the missing DeCyl component.
Different types of geometry can all look like cylinders. In order to deconstruct them you’ll have to write special code for each type.
Although there is the
TryGetCylinder method, so maybe that will work on all surface types.
Yes, the VS compiled version (same thing) can be omitted. But the same code is in the Script components to the far right.
I updated the Script component attached with a fix for when the Cylinder is created using a
PlaneNormal component, but then I only discovered a third case: when feeding the
Cyl-component directly with a vector instead of the
PlaneNormal component, see red-marked case .
Forum_DeconstructCylinder_CSScript_RIL_02.gh (26.1 KB)
I noticed that both the directions and the axis end pojnts can be switched, so “extending” the cylinder may gop in the wrong direction, and the Plane located in the wronf end, and… (ok, plane-version fixed but).
Q: So, how can I determine the different cases? (Like in this case when the Cylinder was created with the
Vector instead of the
What is the reason for creating different implementations of Cylinders (in the very same construct component) for indata of different types?
BTW: Deconstruct components for at least all the basic types should be standard components (like for Cylinders, Sphere etc).
There were no script components. That file only had the components already shown in your screencap. The 02 file uploaded later does have it, so now I can have a look at the code.
Strange. But good that I made it with the second file.
You can’t. The BRL Cylinder component takes a Plane, a Radius and a Height. If you decide to feed a vector into the plane input, then it will be converted into a plane before the component itself gets to have a look. The automatic conversion from vector -> plane is not particularly sensible because it strings together two other automatic conversions.
First the vector becomes a point through simple coordinate copying (i.e. the vector (6,8,-2) becomes the point (6,8,-2)), then the point becomes a plane which is parallel to
WorldXY but centred at (6,8,-2). So basically the plane used in the red-marked case is just a horizontal plane at the tip of the vector.
Automatic type conversions that happen inside the input parameters are not detectable later on. The output is just a cylinder, always of the same data type.
Forum_DeconstructCylinder_CSScript_RIL_03.gh (31.1 KB)
I used the TryGetFiniteCylinder method. Is that Rhino6 only? I don’t know.
Unfortunately, yes, Rhino 6 only. So I still have to go the “long way” to get the Radius and Plane;
Anyway, thanks for the information. I know that it’s abuse to use vectors, but every now and then there will be a shortcut due to convenience… gotta watch out for that.