algorithmic modeling for Rhino
I would like to create four point surfaces by connecting consecutive points on two separate curves. In my attached example I've extracted from the upper curve: points 0 and 1, and points 1 and 2 from the lower curve, to construct the surface shown. I'd like to do the same for upper curve points 1 and 2 and lower curve 2 and 3, and so on and so forth until the two curves form a faceted side. I was unsuccessful with loft and ruled-surface ( maybe I'm missing something ). A C# script would be preferable where I could walk through every point on each curve and send a set (list) of points to the four point surface component. Thank you in advance.
That's very easy ... but:
1. Are we talking polylines or curves in general?
2. How do you like to handle/manage differentiation (if exists) in nodes[polylines]/knots[curves]?
If I understand correctly, you want to treat your curves as polylines with vertices at all tangent discontinuities, then connect all the closest consecutive point pairs? Ie. you do not care about the curve shape in between the discontinuities?
That's correct understanding.
Why give up on lofting the top and bottom polyline segments? That doesn't looks so hard...
Why are the top and bottom point numbers off-by-one?
Can you upload that data as a GH or Rhino file?
Loft worked in Rhino when I baked the two curves, but not in GH (a setting might be needed). Ruled Surface component created too many facets.
The number are off by one as a result of the offset component.
That's a beautiful thing Joseph. I'll study your solution to get a better understanding of what you did, and thank you David & Peter for getting the ball rolling. You guys make it look so easy!
Get an indicative (and rather over simplified) approach to a very complex problem (I'm talking having the "general" case in mind VS real-life complex AEC facades/envelopes and other real-life freaky stuff ... don't ask, he he).
0. Only Polylines are invited to the party. Curves in general ... well ... that's far more complex than you can imagine (code that does that is strictly internal).
1. The sampling of polys is random (in Z) because polylines are ordered in Z automatically - but what if we need a different order? (you tell me, he he).
2. AFTER ordering the first poly determines the target node count: all the rest are tested against that value ... and they are discarded (and sampled in a list) accordingly - but what if we need a different "seed poly" ? (you tell me).
3. Polylines ARE not checked for orientation (sorry but the C# that does that is strictly internal). You can attempt to do it via the ClosedCurveOrientation Method ... but that thingy works on planar stuff AND closed curves (thanks but no thanks).
Notify if you need some other far more "tricky" examples on that matter.
May the Force (the dark option) be with you.
best, Lord of Darkness
Forgot the info thingy
And this ... er ... makes some(?) sense(??) more (in facades and the likes). But since facades are made via thickened stuff (not to mention critical clash detection blah, blah) ... it's just indicative.
It's good to see the anatomy of these machinations (strickly speaking in the indicative). It does shed light upon the darkness.
"Though wise men at their end know dark is right,
Because their words had forked no lightning they
Do not go gentle into that good night".
Let me be the candle to dispel this darkness.
The problem that William described was solved with standard GH components, no "darkness" (C code) required.
The offset curve used for the top of this structure contained more segments (120) than the original curve created for the bottom (56), as revealed by using 'Explode' on both of them.
Using 'Disc (Discontinuity)' instead of 'Explode', however, returned the same number of points for both top and bottom: 56. So the 't' values from 'Disc' were used to 'Shatter' both top and bottom curves, yielding 56 curve segments for both. Lofting these segment pairs worked perfectly.
I NEVER look at your posted code anymore Peter; once was enough for me.