Hello, I’m trying to make progress in Grasshopper, but there are still some shadowy areas that I haven’t mastered yet. I’ve created this entire script to generate carpentry and door elements, but it only works with a single line. As soon as I attempt to apply the operation to multiple lines, it stops working. Do you know how to resolve this?
Thank you very much.
The white solid preview in arctic mode makes it difficult to see anything but reading the code is the real problem. Spaghetti anyone? This is a case where overuse of clusters obscures what the code is doing.
P.S. This code is too spread out and obfuscated for me to wade through. I think it could be much simpler. Even for only one door in the wall, it’s quite complicated. This is the result with only one door:
Taking a look but immediately I see a grafting issue on your Sweep1 component.
When sweeping multiple profiles and rails, always make sure both inputs are grafted or matching their data structure.
In this case, a single graft of the S input will work since the R input is already grafted.
I typically graft both to make sure:
Graph Space:
Model Space:
I’ll check your boolean/wall subtraction in a moment.
Also, you don’t need the Move To Point component from Pufferfish, you can just use the native move component and feed a Vector 2pt component into it.
Native, MoveToPoint:
Your boolean fails because you are lofting two curves that was working previously with a flattened list, now that your doors are grafted in general you need to work within the data trees and should “almost never” flatten anything anymore.
Model Space:
Graph Space (Unflatten this):
Flatten your B input on your Solid Difference to ensure ALL cutters cut your wall regardless of data structure. (keep in mind if you have close walls to each other you would want to ensure it stays grafted as well so that a door cutter of one wall doesn’t cut a neighboring wall also) Think of data matching being buckets containing data/operations/logic. You get to choose when one bucket spills into another. With flattening a list/data tree, all buckets get dumped into the same area (sometimes good… mostly not)
Model Space:
You get an odd inverted door trim surface when you add another line… taking a look at why
The flipped surface normal of the door frame is coming from the Merge Faces and Cap component result:
Bypassing the Cap Holes component prevents the flipped surface. I think this may potentially be a bug with the component itself though I’m not sure.
“Behind Door Number One!”
Your updated grasshopper script
“Behind Door Number Two!”
???
“Behind Door Number Three!”
???
Also I wouldn’t use merge unless your data tree paths are exactly matching, it creates a mess otherwise.
If you want to combined multiple data streams into a new Data tree with simplified branch structure you can use the Entwine component set to Flatten or Graft (depending on what is needed)
I do agree with @Joseph_Oster that much of this can be simplified. Part of the fun is pouring over working code and looking at how you can reduce it to its most simple form but this should get you going for now!
Hope this helps you @Julien_B
20230831_Door_Response_01a.gh (40.8 KB)
The premise of using SDiff to makes holes in the wall is faulty, especially when the wall thickness is obtained from a slider: ‘Epaisseur Mur’ (Wall Thickness).
This is true yes, and becomes a problem if you have a building full of said walls and doors, as the boolean solver starts bottlenecking.
This doesn’t have all your door details, but it could. The important things to note about this are:
Simplicity 
(which is also readability)
Geometry inputs (internalized) are organized by wall (data trees!).
Added the door trim in three groups at the bottom. It got a little complex but still fits on one screen! 
I noticed a detail I hadn’t seen before… Your doors are hinged half way through the wall, which means they can’t open more than 90 degrees? That’s unusual, eh?
Thank you so much for your advise ! Yes its not perfect perfect my script i’m still learning ! 
but thank you so much ! but yes when you are beginner i think you could way more simple !!!
Thank you so much !!! Love it i will study all what you took time to explain for me to progress !
thanks 
@michaelvollrath’s code works for me.
Yes but in different orientation it doesnt work, i dont know exactly why !
My code doesn’t have that problem. 
Working on my end as well but just for fun I’m working on some logic that will let you work with multiple walls/angled walls/whatever walls easier.
I’ll post back here in a bit!
To be fair, my impression is that Paul’s code is mostly your code with a couple of fixes?
When I wrote mine from scratch, I saw no reason to graft the list of lines that mark doors. With only one wall, multiple “door lines” work fine. With multiple walls, however, data trees are natural as there is one wall (branch) for each list of doors (also branched). There are subtle details like what happens if start/end of the “door lines” are flipped - or if one is flipped and the other is not?
Code doesn’t read minds.
P.S. Oh yeah, without posting code, I can’t see this:
I looked into these issues by experimenting… It quickly gets complicated! One thing I realized is that, for several reasons, I needed a single “normal” vector for each wall. And that because of how I created my walls, one faced “in” and the other faced “out”. So I fixed that by flipping one of the “wall curves” (which flips its surface normal vector). Then I messed around… but finally settled for only one other change, which is the addition of a ‘offset HFrame pivot (hinge)’ group so the doors can open 180 degrees without interference from the trim. Of course, with doors so close to each other, the door on the right covers the opening for the door on the left. 
I gave up for now having one door hinged on the left and the other hinged on the right, though that is a realistic scenario that should work.
I doubt anyone will study this code as closely as I have but there it is.
Hi @Julien_B ,
Here’s an alternative approach using points instead of lines.
-place a point near a wall
-the point snaps/orients to said wall and creates the door frames/slabs/etc at those locations.
-by moving the point to the other side of the wall you can effectively “flip” the orientation of the door swing direction
-I ran out of time in adding in your “door flipping” logic (left to right) and hardware logic but the rest is there to get you started and there are multiple properly oriented planes to play around with creating things at different locations/offsets
-you can set the door pivot offset
-this should work with unique parameters per instance (provided your data structure matches)
-per instance parameters could include height, width, thickness, frame profile choice, pivot offset, rotation etc.
-it SHOULD work with walls with variable thicknesses (though i’ve not tested)
Graph Space (Logic broken up into “function groups” left to right, top to bottom is the data flow):
Model Space:
Draw your frame profile in 2D (set the “stretch line” and it will adjust the frame depth to your wall depth):
Have fun and let me know if you have any questions!
20230831_Door_Response_01b.gh (91.9 KB)
Thanks to both of you i will read in details all of this tomorrow and learn a lot from your different advise ! Thank you so much guys !
Hope to be able one day to be able to help people as you do.
Ignore all my previous versions, this handles hinges on either side (left or right), depending on the direction of the “door lines”. There is a Value List called ‘Hinge’ in the rectangular cyan group that switches between examples of “Same” or “Opposite”. CRAZY
There were many complications so the code got a little messy. One of them was the blue “Blob” group that sets ±rotation angles as appropriate. As before, these doors open 180 degrees without colliding with door trim, though as you can see, the doors near the corner will collide with each other.
P.S. I added a pentagonal test feature off to the left of the canvas: (no other changes)
Odd that the GH file has gotten smaller despite the extra code 
Oh, I removed two sets of internalized “door lines”, the Value List and Stream Filter - but still?
I finally looked at your 20230831_Door_Response_01b.gh file - an impressive piece of work! I can see good reasons for using SDiff to cut door holes in existing walls, despite what I said early in this thread. My method of extruding walls causes headaches where adjacent walls meet and overlap.
Your code is a little too much for me to examine in much depth, though I can see some good ideas and may come back to it later if this thread “has legs” (continues). I’m not a fan of invisible wires or having to scroll the canvas frequently to read code.
This image (below) begs a question that a cursory examination of your code didn’t answer: the pivot point (plane) for door rotation is far from its edge, reducing the effective width of the opening. Why?
And why is rotation limited to 45 degrees?
