algorithmic modeling for Rhino
re-ordering items inside different tree branches
Hi All,
i've been struggling for a while with a problem of re-ordering items inside lists which are organized in different branches of a data tree. I hope someone can help me to understand how to solve my problem.
As you can see from the attached img, i have a slice of a dome which i have subdivided in 5 smaller surfaces. Since i need to work on the single curves that define each surfaces, i would like to re-order the list of the curves in the sequence i have written in blue.
Another problem i'm facing is the fact that in the 5th surface (branch 4) the sequence of the curves is different from all the others!...
Basically i would like to operate simultaneously on the 4 curves that define the 5 surfaces so that they behave in the same way... I hope i'm making sense...
Thank you in advance for any advise you can give me...
Views: 1346
- Attachments:
-
-
Dome_01.jpg, 373 KB
-
Replies to This Discussion
-
Permalink Reply by Joseph Oster on
-
Deconstruct the midpoints of the edges and sort them by their Z value first, then their Y value (Sort a List by two or more attributes)?
-
-
-
I've encountered variations of this problem a number of times recently - basically how to determine which edges are opposite from each other and perhaps which is top, bottom, "left" and "right". It just occurred to me that instead of sorting by X or Y (after Z), it might work better to use the distance from the origin?
In each of these Brep faces, the bottom edge is first (0), the top edge is last (3), "right" is second (1) and "left" is third (2).
Left and right are relative to your point of view, of course, and top and bottom don't mean anything if the surface is flat (parallel to WorldXY) but it seems to work reasonably well at treating all surfaces and edges consistently.
-
-
-
This might be handy - a cluster ('xEdges') to sort the edges of surfaces based on edge mid-points and a choice of sorting options. It should work with any number of edges but when there are four, 0 and 3 are always opposite each other and when sorted first by Z, will be bottom and top, respectively.
It works with multiple surfaces (above) or one at a time (of course) - click to see animation:
Inside the 'xEdges' cluster:
"Distance" is the distance of the point from the origin (0,0,0) and might not be useful if the surfaces are arrayed around the origin...
- Attachments:
-
-
sort_edges_2015Dec29a.gh, 70 KB
-
-
-
Permalink Reply by Francesco Bedeschi on
-
Joseph,
this is great! Thank you for your help... actually i was trying to test the previous solution you offered.. I'll try this one as well...
My only question is: will it work also if the surface is not planar? Basically i am working with surfaces defined by 4 arc-like curves...
F
-
-
-
btw: here's my definition... i'm trying to build the internal structure of the Pantheon's dome...
- Attachments:
-
-
pantheon_005.gh, 38 KB
-
-
-
-
The cluster works perfectly!
Grazie mille!! (Thank you..) :)
-
-
-
Excellent! Yes, it works with non planar surfaces - doesn't care, just sorts the edges. Which sorting option works best for you in this case?
-
-
-
sort by Z,Y,X...
-
-
Permalink Reply by Hyungsoo Kim on
-
Hi.
On the sidelines of Joseph's sophisticate solution, I'd like to introduce "Sort Along Curve" component.
It's not that intellectual way, but pretty much straightforward.
- Attachments:
-
-
pantheon_005_re.gh, 38 KB
-
-
-
-
Wow! Took me awhile to figure this one out. You created circles at the center of each surface using the plane ("Frame") from 'EvalSrf'; then the 'Sort Along Curve' component finds the 'Curve Cp' on those circles for each of the surface edge mid-points and returns a 'Point index map' to their position in the original sequence. WOW!! Talk about sophisticated, this appears to be far more so and more likely to succeed in all cases without having to choose the "best" sort option manually, as my 'xEdges' cluster does.
But it depends on all the circles being aligned/oriented so their start points are in the same relative position, right? What makes that happen here? When I look at the circles and "frames" they are centered on, they are FAR AWAY from where I expect them to be!?
So I still don't quite understand this one? Can you explain it? Looks like a very handy addition to the toolkit, thanks. Not quite what I would call "pretty much straightforward" though. ;-)
P.S. Here's what I first thought was going on, but as you can see, the planes are not aligned and the "sorting" fails:
-
-
-
To me, it looks fine...
- Attachments:
-
-
pantheon_005_reV2.gh, 42 KB
-
-
-
-
Whoa, wait a second... Before your latest post (pantheon_005_reV2.gh), I looked at this again and saw it as I expected the first time!?
I wonder if I managed to hook up the wrong wire while exploring it? Because what I was seeing looked more like what I see now in your revV2, in the new group below "Sort Along Curve Way...".
That's weird. But anyway, part of my question remains; what's the difference between the 'Frame (F)' output of 'EvalSrf' and the plane I created from the 'P' and 'N' points? Obviously they are aligned as required while the planes are not. Why?
P.S. Is this some kind of joke? Now I see that the new group uses 'PopGeo' to get this pattern of five planes and circles far away from the surfaces we are interested in, like what I saw before (the blue circles in my previous post)... that's not in the first version you posted. MYSTERY!!!
-
About
Welcome to
Grasshopper
Translate
Search
Photos
Videos
© 2024 Created by Scott Davidson.
Powered by
