Taz, Yea, that's pretty much what I was thinking of. I actually didn't get a chance to really try out recreating it, so your solution was actually much more compact than I though it would wind up being. Although your solution is quite good, its still setup to deal with a specific number of surfaces (simply because it relies on individual components to achieve the restructuring). To me, this really only half solves the solution, since the recreation of the structure is not parametric. Changing the structure within the component itself allows this to be based on the path structure that's inputed into the component (you may have multiple paths with different numbers of surfaces).
I think the creation and manipulation of paths are coming along, but I've always (and still) see data manipulation as being the most cumbersome aspects of creating definitions. Its one of the last things for new users to pick up, and and sometimes its the only thing getting in the way between what you have and the result you're looking to achieve. If components can have that extra flexibility to change their output based on a known (and reasonably logical) structure, then that frees up a lot of data manipulation. Arriving at certain results becomes much easier, quicker, and with less clutter within the definition itself. David, Take your time...it took me a while to get the diagram together, so... -Damien On Mar 29, 3:56 pm, taz <tzez...@gmail.com> wrote: > Hey Damien, > > Before you and David get carried away I just wanted to follow along by > giving the "hard way" a try. If I'm understanding correctly from your > example, the image below would represent tree conversion from option 1 > to option 3 (but only for a finite number of surfaces, 3 in this > case). If such a routine could be made to function similar to the > current data matching settings within a given component, that would be > very versatile. Giving equal priority to data matching and tree > sorting would seem to make sense. > > Note to David: Merge Multiple with 3 inputs seems to be misbehaving. > It's making the correct tree structure but it seems to be losing data. > > http://grasshopper3d/web/string_thru.jpg > > -taz > > On Mar 29, 12:05 pm, damien_alomar <dominos...@gmail.com> wrote: > > > Rather than take up an old thread I figured I'd start a new one to > > keep things clean. I think it would be a great advantage to have > > several different options for the path structure of a given > > component. The first component that came to mind was the Divide > > surface component, so I put together an example as to how several > > different structures might work. > > >http://grasshopper3d.googlegroups.com/web/multiplePathOutputs_divSrf.... > > > The first option depicted is simply what we have now, so no real need > > to explain that one. The second option is adding an extra branch per > > U row or V column (per U column is in the example). This would allow > > for the data contained by each branch to represent individual rows or > > columns of points rather than having all of the points generated from > > a given surface all together. > > > The third option is possibly slightly more complex, but could be very > > useful and very hard to assemble manually. What the third option does > > is "strings through" all of the index points, so that all of the U(n)V > > (n) points for the surfaces could be connected easily. Imagine a > > curve or polyline going from an given index on surface A, then surface > > B, all the way to surface N. This means that the data within the top > > most branches has as many elements as the surfaces within that path. > > > Hopefully this makes sense as to how these different pathing options > > could actually be structured, and hopefully the usefulness of these > > options is clear. > > > Best, > > Damien
