We have an assignment to create a joint that can become parametric. On the ends of the joint i want some wooden beams (1000 x 50 x 100).
They should look like this when connected
I have tried making the joint and beams in grasshopper, but I am having a hard time making the components rotate and move together, and especially when I am moving and rotating the joint, the beams should follow, which they are not. Are there any plugins or ideas you guys might have?
Hi and welcome to the forum. We know how to rotate stuff, but we don’t know what causes your problem since you didn’t provide the GH file.
If you simplify your geometry and strip out all the irrelevant stuff (irrelevant to the rotation problem), keeping the setup you have for the rotations, then someone can take look at point out what went wrong.
Based on your wording, it seems as though you are trying to create a joint like in Solidworks or Autodesk Inventor. I don’t believe Rhino has that sort of functionality or plugin. Nor do I believe there is a plugin for it.
If you move 1 part, you can take the transform component and transform the rest of the part.
Okay, I kind of moved forward today. But now I have another problem.
I have attached a .gh file and the .3dm file that I am currently using. I have made the joint rotate around 3 axises (planes), but when I move one of the sliders (that rotate the joint) the beam that I have made acts weird.
The “joint” itself appears to be a static, fixed brep created in Rhino, not parametric at all? So why not just group the beam and joint and rotate them together?
I want to be able to create several of these “joints” with different lengths on the beams. If I group them together, I can’t create another joint with another beam on the top for example.
Rasmush,
I am not 100% sure I understand your question, however this looks like something that grasshopper can do. So a couple of thoughts…for me it’s all about organizing the relationships within the drawing. And organizing the GH definition. (Labels, grouping components, scribble notes etc.) You could for example model the connector. Then “extract” (explode BREP_ list item) a vertex ( or an edge or a surface which ever makes sense). then use that item as the “base object” for one of the beams. The relationship works because if you move the “base object” the beam also moves. The relationship there has to be that the “beam base object” only moves with it’s parent connector. And the move can be a variety of moves including rotate. The size of the beam needs to be independent of that base object. In other words if the beam gets longer it gets longer with “base object” being the anchor. Repeat for each of your beams, again using the salient object as the starter point for your beams. Getting it modeled, then rotating it should be straight forward.
It gets quite interesting if you want to set it all up, rotate it and then add more beams and connectors. In my mind the problem then becomes how to set up all of the relationships, in a robust manner, more so then a problem of GH components. In my studies of GH those are the discussions that are missing. I would love to hear, read, study how others think about this. And I believe it is a challenge with any kind of programming. What the relationships are, and how to build a robust solution.
One final thought would be to model a simple connector( the simpler the better), model a simple beam or BREP and play around with the relationships. BTW the relationships are sequence dependent. i.e. is the beam “attached” to the connector before or after the connector is rotated. Grasshopper is endlessly fascinating with many “right” solutions, many many wrong solutions and but a few elegant solutions. Good luck
Bill
