New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Defining Opening geometry in Window and Door Types #2474
Comments
That's a clever approach! I really like the idea of referencing the clearance geometry! |
Keep in mind that a window/door's clearance may need to also adjust to the thickness of the wall / thing. So if the wall is very thick, does that mean the user is responsible for ensuring that the clearance covers the worst case scenario? |
It feels like I'm not even abusing the Clearance representation, since the Clearance is literally the space that the Window needs to be clear of obstructions. So it should always be safe to use it for cutting openings. Yes the opening geometry needs to be drawn to account for different wall thicknesses, but since they have to be drawn manually for anything other than the simplest rectangles this is always going to be the case. The openings in the example are all extrusions in the Y direction, but it is easy to imagine more complex opening cuts for splayed reveals, boot lintels etc.. A complication would be if the same window type is used in different wall constructions in a single project (say in a stud wall and in a masonry wall), they might need different shaped openings - but actually it is hard to think of a legitimate example. |
A door built into concrete construction may use the same detail regardless of concrete wall thickness depending on the project. But yes, I think you're right it just makes sense to reuse the clearance representation. |
I guess I'm really asking if it is sane to be re-referencing the geometry 'Items' from the Type in the Opening, since this is not a conventional mapping (I can't reuse the Representation itself because all Openings have to be Body): |
To me, it's similar to how it is expected that all profile set usages are expected to reuse the profile in the swept solid extrusion. |
@brunopostle did you consider that the clearance for door geometry might be used for things like accessibility requirements / clear space in front of door swings etc? |
@Moult it's true, but the clearance geometry could do both jobs. Practically this would work fine (since there is no overlap ;) but conceptually people might not like it. It there no possibility of creating a custom subontext? This seems like something that you ought to be able to do, but the spec implies not, there are only eleven subcontexts. |
There is a possibility of creating a custom subcontext (or a custom target view of an existing subcontext), but nobody else would support it (which I guess could be fine for the time being?) |
You won't like this idea: blenderbim could check to see if the clearance geometry would actually punch a hole through the wall, otherwise it would fall back to the bounding box thing |
The opening geometry is not really a targetview level thing, as it is actual construction instructions rather than something that may or may not appear in a drawing |
IfcWindowStandardCase defines a Profile representation which includes a single 3D outer curve, which then can be used to inform the IfcOpeningElement. This would be a 2D extrusion, would that be sufficient? |
A 2d profile would be good enough for most purposes, would cover all non-rectangular windows, and shouldn't trigger anyone who dislikes mixing uses within a representation. I already started modelling openings that are different on the inside to the outside, but these types could have a profile representation too, so if anyone inserted a homemaker window in blenderbim it would mostly work. |
Here's a test with a single window type: test-profile.ifc.txt. This type has:
|
I think this is now implemented so it can be closed. |
IFC Openings can't be typed, which is a problem especially if they have complex geometry for arches etc..
This is a test where the opening geometry is stored in the Window Type as a Clearance Representation (in addition to the Body and Box Representations).
When a Window instance is placed in the Wall, the Tessellation is referenced from this Representation and used to create Openings. So the Opening geometry only exists once in the file.
Seems to work ok, I can't think of any major drawbacks from using this technique, any reasons why I shouldn't do this?
Test file: opening-test.ifc.txt
The text was updated successfully, but these errors were encountered: