Hi everybody,
we just published a new plugin for Rhino that brings dynamic blocks to Rhino:
AdaptivePartsEnvironment
With the Adaptive Parts Environment you can adapt parametric elements through an userfriendly UI in Rhino. It allows you to update geometry without having to “rebake” Grasshopper outputs.
The usage of adaptive parts does not require Grasshopper knowledge so anybody can use them once created.
Please be aware that this is still a BETA release and there might be some bugs with display or functionality. Nonetheless we’d love to hear your feedback. Please tell us if you like it, how it might be improved, which bugs you found so we can fix them or if you have special requests what should be integrated as well.
Yours
Dominik
5 Likes
Very cool plugin @DominikIC.
I’m having problems when using the copy command. It behaves more like move.
That means I can only have 1 instance of a given AdaptivePart.
But a very promising start!
/Morten
Thanks @molu!
Can you explain little bit further what the issue with copy command is? We did not have any problems so far with copying parts. Maybe you can send us the file as well? So we can find and fix the bug.
Yours
Dominik
This is an extremely powerful plugin, and I can think of so many ways this will impact our workflows. I’ll be trying it out immediately on our ongoing projects. Check this out @Eugen !!
I’m brainstorming how I’ll be using this in collaboration with other designers, so I have a few quick thoughts:
1 - is there a way to inspect back and edit the Grasshopper DNA after you’ve baked the block? Or is this occluded on purpose so that end-users won’t mess stuff up? It would be a useful feature for debugging & incremental development purposes.
2 - Perhaps these two buttons could be collapsed into a single one that toggles the detailed description on and off:
3 - It would be very useful to be able to select multiple objects that share a GH DNA and edit their parameters all at the same time. For example, let’s say I created a single APE-block for all the windows in a project, so that I can control both particular properties and dimensions (one needs to be a little longer, the other a bit taller, etc) and some visibility properties (I’ll play around with the curtains and sliding panels to create a dynamic scene for Enscape). These would all be the “same” block (DNA-wise). But if I wanted to tweak the frame width for every window or roll every curtain up, I would have to edit each of them manually, one at a time.
4 - Copying works fine for me as well.
Thanks again! Let me know how I can help. Love the concept & implementation. Cheers!
Hello!
Thanks, interesting plugin!
Besides the obvious benefit, here’s some (straight) critique:
1 - For me it’s a rather peculiar workflow, having to bake something from a GH script to get a dynamic block. (Especially since I could not find some quick intro tutorial, and had to experiment a while to get the idea. Maybe I missed it?)
Wouldn’t it be more straightforward being able to create some sort of special empty container block which on e.g. a double click opens it’s GH guts?
I’m trying to imagine what such a rig would look if someone wants to mix static and dynamic blocks (think parametric nuts&bolts on some static hull, alltogether in one block)… where and how would the params be exposed?
As much as such third party efforts are appreciable, I strongly believe that McNeel itself should provide some strong framework for all this.
2 - Agreed with Rafel: how to inspect the GH script inside the block later? Even baking out of GH again does not overwrite/replace the old block, but creates another one with an incremented index in the name.
3 - User interface: everybody seems to be so keen on creating his/her own interface flavor these days.
To name a few: Rhino itself, Grasshopper, GH2, The GH panel, Tabl_, Enscape (ugh), … Everybody wants to re-invent the wheel. Now here’s another one. That’s why Rhino looks somewhat …amateurish after a while. And what about the dark theme?
I like it when plugins look ‘unobtrusive’, and just like any other part of the Rhino UI. A positive example is VisualArq, which tries to embed itself in a ‘natual’ way.
Furthermore, these parameter buttons look like big sliders already…
…but they aren’t. One has to fold out the actual sliders with the second icon, and fold it back in with the third. As Rafael says in 2: could be combined in a toggle.
Also, the geometry should update immediately when moving the slider, not just after mouse up! That’s very important, and also the way it works inside GH.
4 - agreed with Rafael in 3: there needs to be a system where parameters can be set to be per-object, or per-type. If a param is set to per-type, then changing it would change all similar blocks, and if it’s set to per-object, it would be independent.
VisualArq elements can do this.
5 - Please, really: if I skip entering the email-address in the nag screen, it should not re-appear next time Rhino starts.
It’s going to be interesting, though, like all cans of worms… ; }
Thanks!
1 Like
Hi @Rafael_Igayara,
thank you very much for testing and your response, so I try to answer your questions and feedback:
- Currently there is no way to edit the GH DNA again after baking the block. We have something in mind for the future like a “admin mode”. Because main idea is really that the author of the block bakes it and all standard users can not mess it up any more… The main target group of this tool is not the GH-power-users but Rhino standard-Users who can then use the cool tools of the GH-Power-Users
- Very good idea, actually no need to have two buttons here…
- that is on your to do list and we are already working on that. Will be for sure included in one of the next releases.
Thanks again for your feddback
Yours
Dominik
1 Like
Hi @Eugen ,
thanks as well for your feedback and straight critique. Every critique is always welcome as it helps us to improve the tool 
So to answer your remarks:
- as already posted above the main idea is to enable standard Rhino-Users to use cool GH-Tools. So those people should not mess up GH definitions, that is why we closed it. Maybe we should introduce like a “authors mode” that makes this possible.
For finding the start: Currently we have only few tutorials available on our homepage, I think they explain it quite well. Have you seen them? AdaptivePartsEnvironment | Rhenso - as said, the GH script shall not be seen later, that is on purpose. Maybe a author mode could solve that. And we will need to include some kind of history of the GH-definitions to keep track of versioning of the blocks…
- true somehow… Only way to prevent this is that there is ONE standard way for UIs (the Rhino UI itself) and all others HAVE to use it… One idea for the future of our tool is that we deliver something like UI-styles to choose from and/or something like a “easy-UI-builder” so you can create your own UI. Although this is contrary to what you just said we want to give the GH-authors of these blocks the possibility of making the UI THEY need for their tool. As posted already, main idea of our tool is to enable GH-Power-Users to create cool tools and share them without sharing source code to everybody
- this is on our to do list already and will be implemented in one of the next releases.
- thanks, I will put it to the to-do list. I know there were some issues to control this window as some stuff was not correctly tracked on Rhino-Side, we reported and McNeel will fix it soon. As soon as they fixed we can fix as well.
Currently it is WIP/ Beta stage and we still have many things to improve/ fix, so thanks for your feedback!
Yours
Dominik
1 Like
Hi @DominikIC , looks great but I can’t load it on macOS, GH doesn’t seem to be able to read the GHA.
Here is the error :
The GHA file is either damaged or has been made with a newer version of .NET than Grasshopper itself.
Hi @flixchameroy ,
can you send us an email as well to support@rhenso.com?
So one of our developers can get in touch and solve the problem.
Yours
Dominik
- Yes, I figured it was intentional! However like I mentioned before I still feel it’s a useful feature, so let me expand a bit on why I think so:
(A) incremental development / debugging: Maybe you’ll have an APE block that works fine for some time, but then a new project or a new situation comes along, and you have to refactor the code to cover that unforeseen or previously unexisting particular case. Not to mention maybe definition crashes entirely because you didn’t think it through properly beforehand. That kind of situation comes up a lot in my usage of GH and I’m sure it will come up too as we integrate APE in our workflows.
(B) education / training: I only really learned advanced Grasshopper because people were kind enough to share their definitions online. I understand people might not want to do that (which is why you can have closed-source plugins and password-protected clusters and so on) but I’d like to pass it forward. Tinkering with others’ definitions is a powerful learning tool, and I’d like to make my own code accessible to anyone that might be interested in learning GH, today or in the future.
(C) documentation : part of what excites me about this project is that it keeps the parametric logic of the design alive within the Rhino file. The fact that the baking process erases the computational logic behind a particular geometric configuration has always bothered me immensely [which, incidentally, is why I believe this should be a core feature of Rhino/GH]. I’d like to be able to inspect a project back in the future and figure out, “what was the logic for this again?”, and have that be easily readable and accessible.
So instead of DNA-editing being entirely unavailable, I’d suggest you add an option to make it password-protected or something like that. I imagine this can be technically taxing (you’d have to introduce versioning, like you mentioned). Maybe you can start with bigger constraints for editability such as having to maintain the same inputs if you edit the DNA, if that would help somehow, then gradually make it more general.
- That’s nice, thanks! Additionally, might I suggest you add a few Rhino commands to manipulate the Ape Blocks and their parameters, such as SelectSameDNA, ExtractApeParameters, ReplaceApeBlock, etc. I figure those would be very useful too since this is all about better integrating our GH defs to Rhino-native workflows.
A few extra notes and questions:
-
I haven’t been able to test this yet, but what happens if an Ape block uses a GH plugin that is not installed in the computer that opened the Rhino file? Does Ape have the capability to prompt the user to download the necessary packages though Yak? Plugin management has also been a small nightmare in my experience of trying to integrate GH workflows into a bigger firm, and I wonder if you’ve given this any thought.
-
In the future, you could maybe set-up something like the Sketchup Warehouse where people can share their Ape definitions. Surely this would quickly attract more users, if they could easily access some useful smart blocks for their projects.
-
Do you intend to make this into a paid plugin?
Thanks again for putting this out and let me know if there’s anything I can do to help.
Best,
R
1 Like
Hi @Rafael_Igayara ,
thanks again for the very useful input from your side.
For sure our plan is not to get rid of GH or sharing GH-definitions. Sharing GH-definitions is the best way to learn stuff. But in some cases it just makes sense to make good tools and to close them so other people with zero GH-knowledge can simply use with them a easy UI and without messing things up.
For the incremental development/ debugging: Yes, you are totally right, we would need something like a authors mode and as well a history of for APE blocks.
for the documentation side: At some point it will be possible as well to use APE-blocks in GH again and you will have something like a whole parametric overview about our project with nested stuff etc.
For the other questions just a short notice for now (am on my way to holidays )
4. → I will ask developers what the current status of these issues is right now.
-
to have a warehouse for APE is planned for early next year
-
APE will be a paid plugin later yes.
Yours Dominik
1 Like
@MartinIC & @Darryl_Menezes
Can you both have a look on the technical questions of @Rafael_Igayara under 4.?
The suggestions under 3. are really good ideas, we should add them to the ToDo list
Hi @molu ,
We found out that this issue occurred when the “Global” parameter of an Input is set to true in the Grasshopper definition. This has been fixed in the new update v0.1.3.2
Thanks for pointing out
1 Like
Currently, if an Adaptive Parts Block is Missing a Plug-In Component, it is giving a notification, which Plug-Ins are missing. A direct download link to YAK is not provided as of now. We actually though of implementing it, but turned out to be a bigger task to technically realize it. It’s on our ToDo List, but we are not sure how quickly this will be implemented, since the list is quite long. 
We are also supporting script components (C#, Python, etc.) but are giving a warning before executing a script component inside the GH File.
Best,
Martin
1 Like
Dear @Rafael_Igayara ,
just wanted to let you know that your comment on incremental development/ debugging led us to the decision to integrate this point earlier than usually planned. So we are currently working on that and plan to have this feature included in the next release or the release after. So it should be available soon, probably end of september latest
Apart from that you can check the new feautures and bugs solved on our changelog where we document the progress:
AdaptivePartsEnvironment-ChangeLog | Rhenso
Yours
Dominik
1 Like
Hi @Eugen , just wanted to inform you that we already integrated some of your comments and put some other on higher priority so we are working on it right now.
You can check the changes and updates of the last releases here on our changelog:
AdaptivePartsEnvironment-ChangeLog | Rhenso
Yours
Dominik
1 Like
I just installed and tried your APE.
I like it, and already have a suggestion which would extend the capability of blocks by allowing a block to be an input in another block.
Instead of creating one giant House definition that includes a roof and roof shingles as a covering type… how about House that takes Roof block as input.
The Roof Block would take a ShinglesRoofCover block as input.
By reference the Shingles gh definition would have access to the roof block, deconstruct the block and retrieve the surfaces it requires to function. The surface selection could also by a parameter input of the shingles block.
The above would allow GH definitions to be smaller and easier to maintain and composition of multiple parts to happen directly inside rhino instead of single GH definition.
1 Like
Hi Richard,
thanks for your words and reply.
Indeed having blocks as input is one of our next features we are currently already developing.
As you mention this is a very powerful thing we need. But it is technically little bit complicated as it deals a lot with nesting blocks etc. which is not that easy to achieve in Rhino with coding.
But we’re on it!
May I ask for what purpose you are using APE? I ike to hear user stories
Yours
Dominik
Designing jewelry components.
For example, I would like a circular curve as a block for a ring, and on that I want to add profile curves as blocks, then a sweep block that takes a circle block and the profile blocks, etc… This would allow 100% parametric control of all parts and swappable components.
1 Like
I was able to accomplish something similar but updating the first block didn’t update the 2nd.
In the 2nd block definition I retrieved a list of blocks in the document, got the first block and extracted the geometry I wanted to give to the 2nd block logic.
This worked fine until I made changes to the first block parameters. The 2nd block didn’t see the update, and only reflected the first block changes after I made a single change to the 2nd block parameter.
Maybe some event handling between APE blocks would resolve this type of issue. I don’t know