For Grasshopper 2 it would be cool to have a layer picker (similar to Human’s item selector), which allows to pick the main layer and sublayers in multiple dropdown buttons directly from the Rhino document. This component could then be fed into the geometry pipeline component. This has two main advantages: it allows users to change the layer name without affecting the GH script and for larger documents with many nested layers, it helps avoiding typos.
I’ll just slide in here very briefly. I also would love to see an updated, improved GeometryPipeline component as it has proven to be really useful when designing interactive pipelines in Grasshopper.
Since I don’t know if we can expect any update in the near future, I got to work on this last year myself a bit and wrote a PipelineController component in GhPython. It might not be exactly what you’re looking for but it might help anyway and with some python knowledge I’m sure you can adapt it to your more special use cases. Here is a demo:
And finally, some shameless self-promotion The component is part of Cockatoo, a larger project that I published last year.
Since everything in cockatoo is python (this might change eventually) and completely open-source (this will not change), you can also get just the PipelineController UserObject from the GitHub repo:
Judging by the video, that’s actually a very nice solution for using a more dynamic geometry pipeline. Thanks for providing me with some new ideas. Does this setup slow down noticeably when using it on larger data? Apparently, C# and VB handle this much more efficiently (see this).
What I am looking for specifically though — and this is the reason for creating this post — is just a node with a dropdown interface that directly reads the document layers and sublayers, but doesn’t display the entire chain Layer1::Sublayer1:NestedSublayer1, but instead you’d use one “dropdown node” (the layer picker) for each layer and sublayer. But maybe that’s just me and I should simplify my layering system
Giving the nature of python I expect it to slow down of course. Some super-naive testing:
- Adding a single object: ~7ms until it arrives in gh
- Arraying an object x100: ~28ms until objects arrive in gh
- Arraying an object x1000: ~134ms until objects arrive in gh
- Arraying an object x10000: ~1.3s until objects arrive in gh (for reference: Human DynamicPipeline component takes 654ms here, so I would argue the python component is not too terrible)
So yes, of course C# or VB are faster. Why did I do it in python anyway? Because I really like python, I’m comfortable around it, I despise VB (the syntax is so ugly it should be forbidden IMO), wanted to do something in python where I was not sure if it would even possible, wanted all components of cockatoo to be in the same language, etc.
I’m sorry, now it’s also clearer for me and I think I misunderstood your original post a bit - sorry! Anyway, trying to provide another constructive solution approach using the mentioned ItemSelector, LayerTable, DynamicPipeline (all from Human) and a super teensy python script which just gives you sublayers of a layer as a list:
Here’s the code:
Thanks, that’s it!
The remark on python vs C# was not meant to be criticism, sorry if it came across like that. I don’t even know either of them. Good to see that it handles data relatively well compared to Human, so I’m tempted to try your setup as well in my next project.
No worris, not at all! Once I thought about your question I immediately got in “curiosity mode” and wanted to test the actual performance haha And then just wanted to explain a bit why things are like they are (despite knowing better I might add. Because the question why did I not do everything in C# is of course completely valid and I have asked myself again and again hahaha).
So in the end, very glad that I could help you!
Maybe this is a dumb question, I loaded the script into a GHpython node, but it does not work like the setup you used. The node doesn’t generate an output. Could you by any chance save the node itself and upload it here? Or explain to me what I am doing wrong here? The in/outputs were renamed to layer and children as well.
E: I should definitely take the time to learn programming too, I’m always impressed by people creating nice things, such as your custom nodes.
It might not work until you have clicked “Test” or “OK” in the editor. To be safe here is also the UserObject:
LayerChildren.ghuser (2.5 KB)
If that also does not work we might have found a more serious problem here
I can only recommend it! The things you can do with a computer increase exponentially (we should all know what this means by now…) once you know your way around a programming language. And once you are really comfortable around one language most of the others can be learned a lot easier.
Perhaps it was a copy paste issue with the script, anyways this works, miracles.
Here’s the idea I had on the layer picking. I plan to use the components below to filter out primary layers first. This makes the selection process very clean. With the main layer set, you could then go into sublayers. The idea behind setting it up like this is that you can easily rename layers in Rhino and you won’t have any issues with typos in long layer string names.
Perhaps it’s possible to integrate the Layer/Children node into this setup if you feel like exploring the possibilities. Or maybe you know a better way of doing this?
E; I think a Layer children with a second input for the primary layer string would do the trick.
Many thanks for the ideas and the component!