I wrote a grasshopper script which is splitting Panels due to some parameters.
It is also possible to run the script from Tekla with Rhino.Inside.Tekla.
For better visibility I need to display the Rhino Viewer on the UI in Tekla.
Unfortunatelly Human UI’s performance is so bad that you can’t use the component appropriate anymore.
So I switched to the UI+ plugin, which seems to be working very well.
Is there a way to use the UI+ plugin for Rhino.Inside.Tekla?
If not, is there any other way I can display surfaces/Lines/Breps from grasshopper or the Rhino view on the Rhino.Inside.Tekla UI?
Not sure how/if you could use the UI+ plugin through the GH component for Tekla - might be tricky as the parameters for the definition need to be set directly by the GH component when the component is inserted or modified.
Do you plan to show something generated/stored by Grasshopper before actually picking any input, and what would that be? Keep in mind GH doesn’t calculate anything before the definition is actually triggered by the GH component. You can show a static image in the GH component dialog of course.
For creating temp graphics directly in Tekla when the plugin runs you could use the Display components from the latest GH link versions. In that case grab 1.16 here:
Hi Sebastian,
Thank you very much for your fast response!
I didn’t have the Display-components on the screen so far. This might be a solution for my problem!
To provide some context, I have developed a script akin to generative design processes, which iterates through various configurations for dividing insulation panels. The aim is to identify layouts that minimize material waste. However, it is crucial for the constructor to review and select the most suitable option before the script proceeds to generate the new panel configurations.
Given this requirement, I am interested in exploring the possibility of displaying the polylines representing each option in Tekla Structures. Ideally, the constructor would be able to view the alternatives by changing a number slider e.g. and make a decision on which configuration to proceed with. Following this selection, I would like to execute the remainder of the script based on the chosen option, potentially triggered by a button or similar interactive control.
Would it be feasible to implement a feature within Tekla that allows for preliminary visualization of the options, followed by a selective execution of the script based on user input? Such functionality would significantly enhance the utility and efficiency of the design process and fix my problem very well.
Is the script very slow? I’m thinking that otherwise you could just insert and update the objects for real while iterating through the options, possibly sprinkled in with some text and markup using the Display components. Or are you manipulating existing panels with something similar to the Split command in Tekla that doesn’t allow you to flip between options?
You could also create your temp graphics in the first part of the definition. Make the master slider for this show up in the GH component dialog, and the graphics would be rendered in Tekla and updated when the component is modified.
Then have a Stream Filter with a toggle like this:
That toggle would also show up in the GH component dialog in Tekla, and the filter sends input to the actual object creating components only when the user is happy with the temp rendering and decides to flip the toggle.
Hi Sebastian,
Thank you for your Input!
The option using the filter component with the boolean toogle seems like a great way for running my script.
I just added a toggle and tried to test this. Unfortunately my properties (number slider) as well as the boolean toggle can’t be triggered by the Grasshopper Component UI from Tekla. If I do the changes in Grasshopper itself, the changes are done in Tekla and everything works fine. But the canges cant’t be made from Tekla itself.
Are there some settings or anything I have to check before running the script from Tekla?
Hi Sebastian,
Thanks for your response and for providing the model.
I noticed the visuable changes in Tekla are only made while having the Construction Lines selected.
Then the number sliders and the boolean toggle to trigger the further code are working quite well!
The only problem is, that the code before, which is calculating the different options, is taking quite a lot of time too as it is iterating through many hundred possibilities.
Each time I’m changing the number slider for the design option, the whole code is running again which is not performant at all.
I calculated the possibilities in one big group an afterwards giving I´m them to a new C# Block wich is just for switching through options and outputting the data for the construcion lines.
So is there a posibility to just refresh this one code block while changing the number slider?
Or otherwise would it be possible to temporarely store data somewhere that the code does not have to run again completely?
Each time the plugin is modified the whole definition will be reloaded and solved. So any intermediate results will be forgotten if you don’t solve the calculation part again. Hence why saving them is probably the best option as you suggest - for this I would play with the Data Ouput and Data Input component.
I did a proof of concept here (also update the GH component before trying, link below):
There’s a Data Output component that stores the current results, and a Data Input component that retrieves the previous results. The key thing is that the Data Input component must be solved first so that it does’t just read in the current results in a loop. This is achieved by connecting it to a panel named “Ouput” or “Solve” and then put this panel to the back of the canvas by selecting it and hitting Ctrl+B.
You’ll have the same source/destination file for both the Data Input and Data Output components. One caveat is that the file path can’t be set parametrically, so that might affect things when you have more than one plugin instance placed in the model and they have the calculation turned off, as they will use the same saved results. Not sure about the best way to deal with that.
In the process I noticed the Data Output component doesn’t get automatically solved when using the GH component in Tekla - that’s fixed in this update (uninstall old version from the Extension Manager in Tekla first):
Thank you for this instruction!
A piece of background here, I am dealing with an analysis model and testing the possibility of going via GH component/GH app directly for final users to avoid GH . With this, as I have a Model Object component to select elements (Tekla Object pipeline as an option there as well), for every Run it requests the user to select elements (I was trying with Metahopper Enable/Disable object, but it did not work via GH component/ app). So, I am trying to keep the previous selection for the subsequent runs (there are a few steps to interact with calculation software) and facing some issues:
It seems to be that through Data Input/Output it is not possible to transfer model objects beams - they come as No values from Output (or as Grasshopper.Kernel.Types.GH_ObjectWrapper if I try to operate via selection). I have managed via GUID to get the required result (thank you for your script in some old topic), but it is a bit time consuming, hence, wonder whether there is anything I am missing here and it is possible to store Beams somehow?
When I go via GH component/ GH app, it does not update the _GHComponentData.ghdata, so, the previous results are not available. This concept will not work if not directly via GH, right?
Yes that’s the case, I think only native Grasshopper object types can be serialized through these components. Even if the Tekla objects somehow worked I think they would lose the connection to the actual Tekla model. So using guids is a safer bet.
I think that example was created with the GH component in mind, so at least back then it did work. Make sure you use the latest GH component version though, otherwise the Output component might not be solved.
Hmm, I am using the latest officially released version of the component. I will check it one more time there. But I do not need the WIP version for this purpose, right?
I was trying to save data to an external file, not via standard components, but via Python scripts - the same result, writing works, but reading is not.
While different trials, I ended up with the option that during the first run, the user should pick the elements in Tekla to construct an analysis model in Tekla (a kind of replication of the standard link feature). Then GUIDs of the picked elements could be taken and based on them an automatic selection filter in the model folder gets created (an option for a manual selection filter is also there). Ideally, further, for the subsequent runs in case of needed adjustments of the analysis model or while transferring to the calculation software, elements should get automatically picked based on the earlier created selection filter. But somehow Tekla crashes at this moment. Further tests are required. Normally we could drop a filter file to the model folder and use it straightaway. But here something goes wrong.
Additional question here, it is not possible to use surfaces for the temporary objects in Tekla, right? Meshes take time to be constructed, and lines even with a thickness of 4 are not thick enough.
I just tested the example file in this thread and it still works as intended on my machine, i.e. the Output writes to the specified file and the Input reads that same file. Don’t have a good guess as to why they don’t update the .ghdata file on your machine, could be a privileges thing - then again if python lets you write but don’t read it’s the opposite problem Your filter solution could be interesting if you can’t get the input/output components to work.
No, meshes are the only temp surface geometry type. If your surfaces are heavily triangulated maybe you can simplify them to have fewer mesh faces in Tekla. Inserting dummy objects like beams with a circular profile might actually perform the fastest…
. With this, as I have a Model Object component to select elements (Tekla Object pipeline as an option there as well), for every Run it requests the user to select elements (I was trying with Metahopper Enable/Disable object, but it did not work via GH component/ app). So, I am trying to keep the previous selection for the subsequent runs (there are a few steps to interact with calculation software) and facing some issues:
Your filter solution could be interesting if you can’t get the input/output components to work.