Yes but in different orientation it doesnt work, i dont know exactly why !
My code doesn’t have that problem. 
1 Like
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.
Door_in_wall_2023Aug31c.gh (34.8 KB)
I doubt anyone will study this code as closely as I have but there it is.
1 Like
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)
1 Like
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 
Door_in_wall_2023Aug31d.gh (40.9 KB)
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)
Door_in_wall_2023Aug31ee.gh (36.4 KB) (UPDATED)
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?
3 Likes
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?
Thanks @Joseph_Oster ,
I would like a way to figure out how to trim the door openings in a faster method. SDiff works well for this kind of case but if we were to extrapolate this to a building with say 100s of doors and one door gets moved, it would have to recalculate the SDiff component each time which would (I think?) introduce a noticeable hiccup.
I’ve messed around with projecting curves,surface splitting, lofting, building the walls from the start with the door openings considered, etc. but haven’t landed on a method I really am happy with yet. Any ideas would be appreciated! Or if you happen to have a blazingly fast SDiff script or something lying around, that would be awesome to see!
Regarding this point:
This is determined from the “Door Pivot Offset” slider in the “Control Panel”.
If you set it to 0 it will be a standard hinge door as you would typically see in most applications but I wanted to add the pivot offset in case the user wanted to have a pivot door.
While I don’t often use pivot doors in my projects, it’s nice to have the option when needed.
Rotation is set to 45 degrees but not limited. You can rotate the doors to 360 degrees if desired but I set to 45 just for the example. I did cap the slider for “Door Rotation” at 90 but you can override this value as desired and you could even do negative rotation though your door would clip the frame as currently its set to rotate “away from” the frame as a hinged door would.
I totally understand that and it’s just my preference. I’ve ended up with some laughably large prototype definitions, such as this one ~8000 components and counting (after many reductions and refactorings). And breaking it up the way I did and hiding the wires is the only way my mind can keep track of everything haha. The final code won’t be this bloated and hopefully much of it will become scripted. But for now, it is what it is; not saying it’s the right way or works for everyone but it works for me 
The horror show (only half the canvas):
Cheers!
2 Likes
Aha! I missed that slider setting.
I see the ‘Rotate’ slider limited to 45, which is why I asked. You have it set to 43.33.
YIKES Sounds like you might want to use Hops to break it up into manageable pieces?
1 Like
Oh then that’s just an error on my end.
Yes, hops is a contender to help. It’s all Rhino 8 though so I’m waiting for hops to play with R8 (I think I just saw a post it does now or is coming soon)
Longer term, for that I’ll probably need to hire someone to properly program it all but for now it’s intended to showcase functionality, ideas, and features
Ok, i didnt know the existance of entwine who look really interesting and better than merge for this.
I’m still trying to understand well each step not that easy !
thanks 
The Suirify component is superb for this. ‘Params | Util | Suirify’. It does what you expect from ‘Simplify’, which doesn’t always work as well for this purpose.
1 Like
I’ve not used suirify but will certainly check it out, thanks for sharing!
It always works when simplify doesn’t - named after a forum member who requested it: @osuire
2 Likes
Cool bit of history!
1 Like
Not that it matters to the point of this thread but I added SDiff to cut door holes in existing walls, modifying the ‘Polygon Test Geometry’ group to the left of the canvas. It passes four parameters to the right for the “main code” to work with:
- Door Lines (as before, they determine position, width and hinge / handle locations)
- raw wall
- Wall Thickness
- Wall Planes
I added the door handles, which was quite a bit more code.
Door_in_wall_2023Sep1c.gh (60.3 KB) (UPDATED again)
Doors are limited to 178 degrees rotation to prevent the handles from hitting the outside walls.
P.S. Updated to version ‘Sep1b’ due to rotation bug when ‘Door Width’ was changed.
(How does the addition of a Unitize Vector component increase file size by 10K )
P.P.S. RATS Found another bug.
On doors with hinges on the right, the handles are misaligned. 
Later - Updated to version ‘Sep1c’ to fix misaligned handles.
1 Like
I almost didn’t do this… It got so complicated I considered other methods. I finally got it though. 
The last hurdle was implementing doors that open in either direction. I made no changes to the “main code”, only the ‘Polygon Test Geometry ’ group to the left of the canvas. I added the white group at the bottom which is driven by a text panel pattern of zeroes (“in” as before) or ones (“out”). It modifies the ‘Door Lines’ (moving them inside the wall for doors going out) and the “Wall Planes” (flipping them for doors going out).
Notes:
-
Wall Planes are actually HFrames (XY planes aligned with each wall segment). There was one plane per wall segment but now there is one for each door.
-
The ‘In or Out’ pattern in the text panel repeats as needed. A pattern of zero and one will affect every other door on each wall segment, no matter how many doors. A single zero causes all doors to be “In” (swing out), a single one causes all doors to be “Out” (swing in).
Door_in_wall_2023Sep2a.gh (64.2 KB)
It’s possible this code could be simplified… 
2 Likes
Hey to you make work this i try to move the slider but its not working 