I am trying to model those emergency door overhead mechanism, but I am struggling to make the lower connector (yellow) rotation based on the upper connector (blue) rotation. I tried using vector rotation, but it seems that something is missing.
Anyone know how to do this movement uppon the rotation of the upper connector geometry? I drew how the right rotation should be in yellow.
This might not be what youāre looking for. Also this GH definition is a MESS!!! but the approach is easy to explain at least. If you create circles with the radius between the hinges of the arms, you can use their intersect point(s) to get rotation. This almost works. It might work actually I think I just moved something hence the slight mis-alignment. A lot of these types of hinges have one hinge that can pivot, or an arm that can change length. They tend to bind at some point otherwise. Modeling that howeverā¦
This type of āchallengeā comes up in architecture often with the dreaded bi-folding doors. Iām not sure if this approach would work, but itās the same problem: rotating something thatās also being rotated (and/or moved). The real solution is probably a fancy trig equation. I think I did that in Revit years ago - even had the door handle move with it.
For this Iāve had to make 0.10 the minimum rotation. Youād need a switch statement to do something a little different as it approaches zero. Basically the circles thing their only intersection is their start point (I think) so it changes the point on us and the hinge goes out of place.
What many people donāt know (and this is important for āredneck modelersā) is that Math does NOT define Geometry.
The keyword here is define.
Geometry defines math.
I hate to see people feel intimidated just because they donāt master the math of GEOMETERIC problems, if you see what I mean. But even if you do master the math, it is geometry that defines math (if anyone wonders why teachers try to āillustrateā the math⦠What theyāre doing is going back to definitions.)
It really is , I am fairly new to grasshopper, if you have any advice on how could I do this less messy I am open to it
Yeah, I really need the door to be able to open fully. Maybe if the rod instead of being a block had the lenght based on the circles, the circle could be bigger and achieve the full 90 degree rotation.
I was expecting something based on linked vectors to make the translation movement.
I can clean this up and explain it better but Iāll need a few days. This at least proved the concept but a nice clean version would be nice (and much easier to understand).
Last minute I internalized all the data so who knows what it looks like on other peopleās computers.
The door will open fully (I think) if we change the number sliderās max to 90. Thatās one of the easier problems to solve. The fully-closed situation⦠Iāll have to put some thought into that.
Iāll also see if I can align those pieces better. They donāt have to be blocks once theyāre internalized. Just having them as breps might be better maybe theyāll preview nicer?
Where you have a problem like this it pays to isolate the issue you have to solve (here the movement of a linkage) from the straightforward stuff (e.g. a slab door). Just produce a geometric abstraction of the linkage and get that to work before adding all the decoration that hangs off it. That way you donāt waste time constantly finding and altering elements that are irrelevant to the problem.
HTH
Jeremy
EDIT:
By focussing on the geometry rather than the form, the linkage solution reduces to something like this:
The solution to the circle/intersection point was to find the longest length⦠in this case I just used the doorās main hinge, use that as a start point and then compare the distance from there to the intersects. Whichever one is farthest away happens to be the one we need. Works perfect in this case but might not always work for other hinge types.
This hinge is also closer to the design in the picture. The one hinge point will be attached to the door header/jamb.
Having the pivot arms not be parallel actually makes the circle-intersect solution possible (well⦠weād need another python script otherwise⦠if less thanā¦. etcā¦.). There must be a way to find the longest curve without adding like 800 nodes? This python script could really just be a few lines if it had to.
Here it is. Tested it out as well as Iām unfamiliar with internalizing data. But it appears to work as intended and it works in an empty file. Iām using the āmm Large Objectsā template but I donāt think it matters (only for scale).
I went a little overboard with this one. Partly because I needed to test out a few Grasshopper features at some point and this ended up being the perfect chance to do that. Apologies if I pulled the focus off Leoās original request/inquiry. At least you have a nice example to work with. Please ask if you have any questions (and while the script is fresh in my head).
Iām not much of a Grasshopper user (more into just programming), so any āshould have done this instead of thatā is encouraged and appreciated. Iāll be using a very similar approach in future GH definitions as my workflow is very depending on blocks. Maybe Iāll build a simple engine or something that would be fun!
Note that the definition is laggy even on my RTX 4070 laptop with a fast processor (Ryzen 9). I think that improving the preview capabilities of Grasshopper would go a long way. Maybe not ārenderedā but something that looks nice and doesnāt require huge amounts of resources.
I really needed to test out a few things: Internalizing stuff, working with blocks, previewing⦠To be honest itās a lot of work for what you get in the end. Iām sure itās not so bad if you use Grasshopper at least 2/3 times a week.
Iām impressed by the humility expressed in that statement so took a look. Unfortunately, the GH canvas is so large that when I zoom out to 100%, I can see only a very small part of it, so itās difficult for me to understand.
I tried enabling the Profiler to find the lag but failed to see it? Any idea which part is slow? (āDisplay | Canvas Widgets | Profilerā)
Yes. Creating basic geometry inside grasshopper is pretty straight forward. But as things get more complex you need to have a really really good reason to generate stuff inside grasshopper.
I do have all the linework maybe I can extract that really quickly.
What Iāve done here is āinternalized dataā - you right-click on the object to do that. In this case Iāve done this so that someone can basically just take the file and see what it does without needed a 3DM. Also, if I donāt āinternalize dataā you would have to go through the process of āsetting one pointā, āsetting one curveā, etc⦠And lastly, it makes things look cleaner - otherwise the original objects need to stay in their original positions and you donāt get that nice clean representation (you can move everything of course among other things).
Iām still figuring out the best way to use block instances. If I internalize them they donāt update when the fileās block definition is updated. If I donāt internalize them I have to place them where I want them at the start
Really nice modelling! I thought it was modelled in rhino because of such detail! Could you upload the gh file? I would like to see the reasoning behind and how you solve some geometry such as the upper mechanism curved arm and the filleted edges.
Edit: Sorry, I thought I asked if you had modelled it inside grasshopper and not oustide grasshopper.
That grasshopper file is attached to my post above - about 4 or 5 posts up now.
Iām attaching yet another version complete with Rhino file - Just the linework basically. Itāll make it easier to see what I did but āeasierā doesnāt mean itās easy to dissect a script that someone else made. Plus the way Iāve done this means that if you add/delete a single object you have to adjust all the list indexes to get the right objects going to the right places. I think it would have been better to run more operations in parallel. I think this can be improved both in the way of readability and extendibility. And for that reason I wouldnāt be too concerned about the GH file itself (but ask any questions if you have them I can explain every node) and rather just use a similar approach. Starting off as simple as possible as Jeremy has shown above might be a good plan.
The animation can be improved if no blocks are exploded after the transfromation. Orienting meshes from the block plane to a transformed plane is the main reason why it runs fasterā¦
If the data structure stys intact, the materials can be retrieved from the initial blocks so no sorting is necessary at the end of the definition.
Since this is so in my head I realized Iām being lazy by not whipping up a much clearer version. This one also helps make clear why they have an angle on the arm that stays fixed to the door jamb/header. You can adjust the angle via the number slider from 5 to 35 - you can take the minimum limit off. If you set it to less than 5 you really start to see the problem. The model still works just the speed at which the arm goes to its neutral position accelerates drastically as it approaches the fully-closed position. Not sure what this would do in real life but I see why they have some angle:
In this one Iāve just moved the geometry over 2000 so you can see just the main parts working, but left (almost) everything visible so you donāt have to unhide (un-preview) a bunch of crap to figure it out. I think this will be a better learning tool than what I posted as I both had to get my head back into Grasshopper and not get carried away with the presentation related stuff.