Yep, already in there. The Tree<T> class itself has a bunch of methods for conversions, and I’ve also got a huge set of extension methods in general for all sorts of framework and RhinoCommon types to make my (and eventually your) life easier.
1 Like
I’ve compiled some documentation from the current state of GH2, note that a lot of this code is currently in flux, and oftentimes the comments are outdated.
All the new tree stuff is in the Grasshopper.Data namespace.
3 Likes
Hi David,
Since you didn’t answer all my suggestions, here’s another one for you : A useful “Tree explorer”.
I always have this little noodle stack around to visualize the content of trees through panels and by highlight in the Rhino interface :
It would be great to have an “intelligent” version that would automatically adapt to the tree structure, providing the proper sliders (adapted to the various path and list lengths of the input tree).
This provides a great way to check if the lists are properly structured, and if the objects in the lists are ordered as required.
It also reminds me that it would be nice to see the preview objects in Rhino when a component which contains it is selected in the GH canvas, even if :
-The component’s "Preview is currently set to “Off”.
-The “Only draw preview geometry for selected objects” is not toggled “On”
This is my version of a ‘Tree/List Viewer’. Makes it so much easier to literally see data trees of geometry. Two sliders highlight a branch (‘path idx’) and item (‘list idx’), so you can see the sequence of paths and geometry in lists. GH would be impossible for me without this tool. The only issue is that preview on other components must sometimes be disabled to see the ‘Preview’ outputs of this tool.
vuTreeList_2017_Jan19a.gh (20.0 KB)
The two clusters (‘vTrE’ and ‘vList’) are “open source” (not PW-protected) using standard GH components.
2 Likes
Hi Joseph,
I see what you did with the sliders, but I need to explore trees with more branching levels.
Basically, the explorer should also adapt the number of sliders to the number of levels found in the tree.
Here’s an example with two paths indexes.
The idea would be to have automaticaly the good number of sliders and the proper ranges, all that in a nicely packed widget.
Hey…
U may want to have a look at this:
The number of the sliders is adapted according the Tree-Structure.
DoubleClicking the lower part of each slider locks it, and is interpreted as wildcard for this branch.
On top is a slider to get by item.
Some strange visual behaviour is going on, but yeah, it works 
Can get it here:
goto >>> MOrTools
BranchTree.gh (18.1 KB)
Tell me more!
Greets
1 Like
Trim tree could have a sibling component. Instead of specifying how many levels the user wants to trim, it could accept an input saying how many levels the tree should be left with.
1 Like
@DavidRutten; Symbols preceeding the param names, here drawn with rough ascii, but they can be smaller and drawn more subtle, perhaps closer to and the size of the connection knobs:
// Rolf
2 Likes
Yes please! It took me way too long to discover this component and it changed my life. Would be nice if paths were flattened instead of shifted out of existence too
@DavidRutten Are you adding metadata as a feature because Rhino 7 are going to support metadata? What I’m really hoping for is built in support for export of IFC files from both Rhino and Grasshopper.
It has nothing to do with Rhino 7. Rhino has always supported user and plugin data on objects, but even that is only tangentially related to GH2 meta data.
IFC is not the reason either, although I imagine BIM workflows benefit from the ability to attach data to values inside Grasshopper.
I am not planning to write support for IFC into the program. I’d rather leave that to people who know what it’s all about. GeometryGym and other developers basically.
2 Likes
Ok, thank you.
Is there anywhere I can read more about the possible applications of meta data in GH? I imagine Geometry Gym and Visual Arq will make greate use of this
Not yet. Also the applications are sort of up for grabs. Like, the documentation doesn’t concern itself with what you would do with addition, the sine function or meta-data. It’s just about how it works.
I do plan to reserve certain meta-data keys for meaning within Grasshopper. For example preview-colour, bake-layer and line-type.