to do this I am only using GH components, no coding (C# or python).
I would like to share this work with you to understand how to solve and develop it with better logic. To make simple steps I used many components.
I have divided the design by steps, the ones I would do it by hand. This is the first step assonometria parallela_step1.gh (21.3 KB)
As I proceed, however, there are small problems and the definition becomes more and more complex to manage and order.
This is the script with the second step: assonometria parallela_step1+2.to review.gh (44.8 KB)
It works, but only for certain inputs. I probably have to change the logic of some steps. In the image below you can see the result.
I wanted to ask a few things in particular:
-how can I better manage inputs and outputs that are repeated and used several times in the same definition.
-how could I create annotation points for each entity I am going to create (lines and points) so that they can be easily identified in Rhino?
Telepathy is a great plugin for this. It allows you to reference parameters across a script with a simple naming system, where parameters given the same name will receive the same inputs.
As you have already done, itâs best to organise your script into discreet groups of logic. This helps with bug finding and script-reusability. Then you can use telepathy to connect between these groups. I would also highly recommend the plugin Autograph for the shortcuts it gives you to add new parameters âupstreamâ and âdownstreamâ of components.
Also, mastering Grasshopper DataTrees is very helpful for reducing complexity in scripts (however I canât see it being as useful here).
There is a good tutorial for Telepathy on the download page that I linked. It is by one of the plugin creators.
Iâm not sure about Autograph, itâs very powerful but I donât use many of itâs features. The main shortcut I use is: select a component in your script and press Alt + Left Arrow (Or right arrow) to insert a parameter downstream.
What sort of annotations did you want to create? Annotations within grasshopper, or within the Rhino Viewport. For printing, or for viewing in the model only?
What I did was to collect all the elements I am interested in displaying on one side, so that I could collect them in groups and be able to activate/deactivate their display on rhino as you see here:
Iâm not sure it is so straightforward. I had to pay a lot of attention because itâs easy to make mistakes (I used to double the output) Or anyway, it doesnât change much from how it was before.
Perhaps you meant differently?
when it crosses the intersection and is âbelowâ, it should change the direction of the arc, and be like the red arrow, but instead remains the same. ideas on how to solve this?
Iâve had a better look at your script, that is a neat method to control visibility - a bit complex through. What I would normally do is just collect the outputs to a custom âDisplayâ component and filter which parameters I want to pass through. Your solution is also fine though, and everyone solves some problems differently. I think there is no right or wrong way.
Having looked at your script, I think you have separated and labelled almost every step. This may help you stay organised, but for me, I would find it would slow my scripting process down and actually add to the complexity - but it all depends on the logic of your script and process.
Iâm afraid I donât understand the logic of the script too much because of the language barrier, but I have been able to make the change you requested by using a different âarcâ component.
This is seems to be the group with the main title.
I would use the Elefront plugin to create âtext dotsâ, using this component;
Hello @Patt
thanks for the solution, I followed your advice to visualize texts.
I still have to find the right workflow. I think you have to find a middle way between grouping the various steps together and dividing them up as much as possible and sorting everything.
In the first case you do it faster, but then you risk not understanding what the script is doing. (I have scripts that I had done like this and in fact I can no longer follow all the various parameters) In the second case everything is tidier, but it takes quite some time.
Here I put the result. I translated the steps into English so I hope you can follow better.
When I find some time I will try to develop the sequel.
greetings
This way it works, but you canât quite manage the order of the connecting objects.
Here in particular I noticed that dot K and right m are reversed. I think because they do not match the order in entwine.
I donât know why, but evidently the Connected-ListData block doesnât maintain the order in which the objects are inserted.
@Patt, I like this method of controlling the visibility of scene objects. I use a similar method where i copy/paste the key names of remote receive in a panel first. Your method skips that step, directly passsing in the Receiver data to the âconnected objectsâ component.
However, just @huskenazy cannot seem to fix the order issue. Using an Entwine before inserting it to the âconnect objectsâ caused an error with the Item Selector.
@crz_06@huskenazy
Apologies on the delay on this, 7 days is an eternity on the McNeel forum. I donât remember creating this but I like the way it works. Iâve managed to make a few improvements, mostly by using the component in Metahopper to get the data from the original Param and now the display comes through in the correct order. See file attached
I was using the Entwine for clarity of which component is connect in which order. I realise this only works if a âGet Connected Objectsâ component is included for each parameter. Using âGet Selected Componentsâ is probably more flexible.
