Damien, What I came up with definitely wasn't parametric, but as such even a finite solution wasn't really feasible until the Graft (twiggy thing) component came out with the latest version.
I believe I remember some of your previous commentary on data management. As it stands now cross reference is kind of like the nuclear option and should be used only sparingly, so sometimes I find myself forgetting in which cases it's necessary from lack of use. Your suggestion has me wondering if data management and tree sorting (I'm making up terms here...) could even coexist within a component without becoming too confusing to work with. Maybe the trees do need to take over but, on the other hand, would that really make things any less cumbersome depending on the frequency with which certain (predefined? programmable?) tree structures are used? I'm out of my league here, but maybe an additional interface could improve tree functionality. It's funny that a "tree" data structure is such a visual idea to begin with... It (almost) makes me want to see something branching. I'm sure David will weigh in soon enough with what the future holds, but I'm just giving this thread a bump. -taz On Mar 29, 7:11 pm, damien_alomar <dominos...@gmail.com> wrote: > 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
