I’m struggling to put together a Karamba cross-section table of user-defined cross-sections that can be embedded into Shapediver. Outside of Shapediver, grasshopper reads in a CSV file that contains cross-section properties for 80 different shapes which runs fine in Karamba but I’d like this data to be embedded into the file so that a Shapediver user doesn’t need to think about it. The Karamba Cross Section node only allows for the input of basic dimensions from which it calculates section properties but I would like to use my own calculated properties. I’ve translated the various items for the definition of a cross-section (around 35 parameters for each section) into a JSON file but I can only use the major dimensions in the Cross Section node. I need to use all the properties, though. Any suggestions would be useful.
I am not sure I fully understand the issue, maybe a minimal example in Grasshopper would help. As far as I understand, I think your issue revolves around accessing properties inside a JSON object, which is possible using the JSON components of the ShapeDiver plugin.
Hi Mathieu.
The problem I have is reading in a CSV file which contains structural properties of around 80 non-standard sections. In the local Grasshopper/Karamba model, this is not a problem as I use a filepath node in conjunction with a text panel to read in the location of the csv file. But when mounting the model onto Shapediver servers how to avoid the online user needing to do this? I thought it might be possible to embed the data into the model via JSON but then I encountered the problem I mentioned - the standard cross section definition in Karamba is for a range of standard shapes. Is it possible to sit the csv file on the Shapediver server and reference it in from there?
You can solve this by using the Import Text component, which supports csv file inputs. I refer you to the link for more details, but in a few words, there are two ways you can use this component:
- Store the csv file somewhere at a public url and use this url as an input for the Import Text component.
- Do not use any URL as input. After you upload the file on ShapeDiver, the Import Text component will generate an upload button where you can directly upload your file. If you do that in the “Edit” mode of the model and save it aftewards, this file will be saved with the model. You can hide the input from the end users of the application so that only you can access it in “Edit” mode, and even update the file in the future if needed.
Thanks for the comprehensive response, Mathieu. The second method seems the more attractive route. However, one small snag when uploading the gh file. See the enclosed error message. Is there a way to use the earlier version of Karamba?
@cp1 we did not yet roll out 2.2.0.13 on our systems, is there a possibility that @steve14 can get access to an installer for version 2.2.0.10 for now?
Hi @steve14, in the link below you can find the old versions of Karamba:
Hope this helps.
Hi Ezequiel,
Thanks for the link. I unistalled the version I had installed on one machine and tried to install the .10 version but got the enclosed message. I gather from the Karamba wesite that its advising to use the latest version, .13. When I open grasshopper there is no Karamba components on the ribbon.
The message says that you have Rhino 7 Service Release 8 installed, while this version of Karamba is expecting at least Service Release 12.
Yes, updated Rhino solved that problem. But it would seem that some Karamba elements are not supported. See the latest error message.
Ok, great that it works now.
Please note that these components which were denied are not supported on purpose, because they access the local filesystem, which does not make sense in the context of running Grasshopper models on ShapeDiver.
Is there anyway round this, Alexander?
I am not an expert in Karamba, but I guess you could bake the cross section information into your Grasshopper model instead of reading it from a file.
@karamba3d could you jump in here please?
Yes, it now uploads to ShapeDiver! I internalised the data that had been streaming to the crosssection component via the read file.
The basic geometry looks fine in SD but I now have to figure out how to show Karamba output such as force diagrams and utility ratios.
Alexander, Can I ask some further questions on seeing the Karamba output. If you look at the enclosed Grasshopper script (which contains both Karamba and Shapediver components) you will see I’m trying to show the utility ratios of the beams (of a simple truss) via ShapeDiverDataOutput but they don’t appear on the website. Do I need the API version of SD to allow this?
The Data Output component does not produce any display element in the platform, it is only meant to be used through the API at the moment. We will likely add a panel to display data outputs in the future. In the meantime, I suggest using text tags in your 3d scene as a workaround.
Hello @steve14,
force diagrams and rendered result meshes should be no problem since they come out as Grasshopper geometry.
Things like support-, load- and joint-symbols however get directly rendered to the Rhino canvas. In order to have them as Grasshopper geometry one needs to use Karamba3D’s parametric UI components (see here).
– Clemens
Thanks, Clemens, I’ll look into that.
In order to present the results of the analysis, I’d hit upon the idea of colouring the beams according to the value of the utility ratio given by the EC3 check, which might suit the end user better, and quickly encountered problems. The only way I could find to affect the beam colour was in the pre-processing components but of course I couldn’t feed the EC3 output ratio back into it. Am I up a dead end?
Hi Steve, you cannot input the values directly into the Karamba3D ModelView/BeamView components, however you can use the values to create your own colour mapping and then display the colours using the CustomPreview component in Grasshopper.
And what geometry to use for the CustomPreview, Matthew? I tried the Beam View/Meshes of rendered beams but the output from this is one single mesh for the whole model which results in one final colour.