Adjust the Doors function to the changes in the Door class #56
Conversation
It is done because of the following two reasons: 1) StandardWall is in the Elements and Door is to be moved to Elements. 2) StandardWall contains info about openings when WallCandidate does not. Wall CenterLine is used for the mapping because id's in "Wall Candidate" additional property of StandardWall don't correspond to any WallCandidate's id's for some reason.
There was a problem hiding this comment.
Reviewed all commit messages.
Reviewable status: 0 of 1 approvals obtained, 1 unresolved discussion (waiting on @anthonie-kramer and @srudenkoamc)
LayoutFunctions/Doors/hypar.json line 66 at r1 (raw file):
"$hyparOrder": 2, "enum": [ "SingleSwing",
These enums are user facing stings, I think whey should have spaces.
There was a problem hiding this comment.
Reviewable status: 0 of 1 approvals obtained, 2 unresolved discussions (waiting on @anthonie-kramer and @srudenkoamc)
LayoutFunctions/Doors/dependencies/Door.cs line 51 at r1 (raw file):
Transform = GetDoorTransform(currentPosition, wallLine, flip); Representation = new Representation(new List<SolidOperation>() { }); Opening = new Opening(Polygon.Rectangle(width, height), depthFront, depthBack, GetOpeningTransform(wallLine.Direction()));
Door transform should be already set up then Opening is created. I think GetOpeningTransform should have no parameters and fully use Door data.
Fixed at 60834bd |
Fixed at c2d26d9 |
There was a problem hiding this comment.
Do we have a workflow where we are testing the updated Doors function?
Reviewed 4 of 9 files at r1, 5 of 5 files at r2, all commit messages.
Reviewable status: 1 of 1 approvals obtained, 2 unresolved discussions (waiting on @DmytroMuravskyi)
I don't think we do. |
- Updated version of Elements to one that contains Door class; - Removed Door class, DoorOpeningSide and DoorOpeningType enums
…LayoutFunctionCommon
srudenkoamc
changed the title
There was a problem hiding this comment.
I think we can pause the work on the Doors function, since we are likely changing the strategy to have the Door created as part of the SpaceBoundary and Wall definitions. Let's just focus on improving the Door class and prepare it to have a relationship with the Wall
Reviewed 6 of 9 files at r3, 2 of 2 files at r4, 2 of 2 files at r5, all commit messages.
Reviewable status: 1 change requests, 0 of 1 approvals obtained, 3 unresolved discussions (waiting on @DmytroMuravskyi and @srudenkoamc)
LayoutFunctions/Doors/src/DoorOpeningEnumsHelper.cs line 5 at r5 (raw file):
namespace Doors { internal static class DoorOpeningEnumsHelper
There aren't many who use the Doors function, so we can change it however we want... In this case, we should just change the override definitions in hypar.json to conform to what we need.
There was a problem hiding this comment.
@srudenkoamc Disregard the comment above, I think we will use the Doors function as a starting place for the functionality that we want... I will probably try to test this out tomorrow with the updated Door class changes...
I think we will still want to generate Doors initially using the WallCandidate, and then allow for overrides to change location, and place the Door on the closest wall, and cut out an opening... This will probably happen in Interior Partitions which means I will makeDoors a dependency for Interior Partitions... I can handle the Wall stuff if you want to get the Door stuff in a good place for me to work with.
Reviewable status: 1 change requests, 0 of 1 approvals obtained, 3 unresolved discussions (waiting on @DmytroMuravskyi and @srudenkoamc)
BACKGROUND
DESCRIPTION
This change is