How to subtract a window sill?

[Roy_043]

At the moment it is actually hard to tell if using an ArchComponent is useful since there are some cases where a 'move with host' link does not work.

[Roy_043]

If the window sill is more detailed, then the volume to be subtracted from the wall will be larger than the sill itself. Ideally the 'subtractor' will stay connected to the sill, and the sill connected to the wall.

Using facebinders I am able to keep the subtractor and the sill connected. But I wonder if there are other, more obvious, techniques that perhaps can also be used to connect the sill to the wall?

[yorik]

I had some thoughts about sills too.. I think an interesting way could be to have the sill to be part of the window (as it happens in several revit families). We would then have, in the window sketch, an "outer" polyline, which would define the cut to be done in the wall, including the sill. Then, a rectangle that would be extruded to form the sill

Some features that could be added to make this work better:
1) Currently the biggest polyline in the sketch defines the hole. We could make that user-definable
2) Add a new "Sill" window component type

[Roy_043]

I would prefer to add the sills, lintels etc. as separate objects, but connected to the window somehow. I have been experimenting with this idea, and to some extent this is feasible with the current tools.

In the example Sketch001, the base of the Window, is attached to the Wall Sketch following a procedure demonstrated by @paullee. The WindowOutline sketch is attached in the same manner and in formulas references properties from Sketch001 (attachment) and Window (height and width). The sill and the 'subtractor' in turn are attached to the WindowOutline sketch.

All in all a bit complex, but if you create the WindowSillGroup in a separate file, you can merge it multiple times with Std MergeProjects.

One advantage is that this method will allow high LOD (level of detail) objects.

Two problems:
Subtracting (Arch Remove) SubtractorExtrude from the Wall results in a cyclic dependency.
The window is extruded in the wrong direction as a null vector is used for its Normal (discussion).

Code: Select all

OS: Windows 8.1 (6.3)
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.19.18504 (Git)
Build type: Release
Branch: master
Hash: f66023a646db4b2502bb3637897443b3525ca3c7
Python version: 3.6.8
Qt version: 5.12.1
Coin version: 4.0.0a
OCC version: 7.3.0
Locale: Dutch/Netherlands (nl_NL)

[paullee]

I would prefer to add the sills, lintels etc. as separate objects, but connected to the window somehow. I have been experimenting with this idea, and to some extent this is feasible with the current tools.

This is one issue I have been thinking and trying to see which way is better - In Stair Objects, Railing is automatically added in the Stair Object as Addition (Railing is implemented as ArchPipe). Also, when I try to implement the idea of 'multiple-segment' staircase, I make each 'segment' as individual Stairs object. Then all these Stairs 'Segment' + Railing are 'housed' inside a 'parent Stair' object.

Not sure if this is good, but it created a numbers of document objects in some way @Yorik mention more objects slow down FC. Compound grouping all the shapes inside 1 object seem more efficient in speed I was told.

E.g. For Curtain Wall, should it become an array of Mullions Window Objects + array of Glass Panes Objects?

In the example Sketch001, the base of the Window, is attached to the Wall Sketch following a procedure demonstrated by @paullee. The WindowOutline sketch is attached in the same manner and in formulas references properties from Sketch001 (attachment) and Window (height and width). The sill and the 'subtractor' in turn are attached to the WindowOutline sketch.

One problem currently is that if you map to some edge, and you edit (delete mostly) the underlying sketch edges, you end up link to 'wrong' edge. I implemented a very convoluted method to avoid this but it seem @Realthunder's branch have solution on this - yet to be merged to my understanding.

BTW, it seem you can just map your WindowOutline 'directly' by Object XY (just the object's orgin no edges, not vulnerable to editing the underlying sketch)to the Sketch001 (Window's sketch) rather than the Wall's sketch (revision attached).

Or why you created WindowOutline in addition to Sketch001 ? - Any reason why not mapping the SillOutline directly to the Window Sketch001 ?

All in all a bit complex, but if you create the WindowSillGroup in a separate file, you can merge it multiple times with Std MergeProjects.

One advantage is that this method will allow high LOD (level of detail) objects.

LOD is another issue difficult. Can you enlighten me what is this StdMergeProjects and how it works with LOD? Thanks

Two problems:
Subtracting (Arch Remove) SubtractorExtrude from the Wall results in a cyclic dependency.
The window is extruded in the wrong direction as a null vector is used for its Normal (discussion).

I do not seem to have cyclic dependency problem? See attached file.

And yes, it seem the underlying Window sketch is not attached properly - ah - you have in Window Outline Attachment Angle input 1 deg. Not about Normal.

Screenshot from 2019-10-12 05-00-56.png (142.74 KiB) Viewed 1080 times

Screenshot from 2019-10-12 05-23-31.png (186.92 KiB) Viewed 1080 times

Screenshot from 2019-10-12 05-25-53.png (190.27 KiB) Viewed 1080 times

Screenshot from 2019-10-12 05-26-39.png (197.5 KiB) Viewed 1080 times

[Roy_043]

Compound grouping all the shapes inside 1 object seem more efficient in speed I was told.

In the case of window details there is a logical reason for creating separate objects: details can vary per window. The left and right horizontal details can even be different for a single window.

... you edit (delete mostly) the underlying sketch edges, you end up link to 'wrong' edge.

That risk is there. But it can be reduced if you attach to a schematic master sketch which is less likely to change.

revision attached

Thanks. I'll look at that later.

Or why you created WindowOutline in addition to Sketch001 ?

The idea is that the WindowSillGroup is created once in a separate file and in that file Sketch001 does not exist.

Can you enlighten me what is this StdMergeProjects and how it works with LOD?

The way that windows are implemented (nested wires) is quite clever, but does not allow for high LOD results. For a high LOD window (or window sill) you would need some sort of container that can hold the detailed solid(s) but also a separate subtractor to define the hole. This container would then need to be attachable to a wall. I am using a group as the container and the StdMergeProjects command to "insert" it.

Angle input 1 deg

I have had a quick look at my file but don't see a 1 degree angle.

[paullee]

Thanks for the feedback, lots of issues to think about

Angle input 1 deg

I have had a quick look at my file but don't see a 1 degree angle.

Check the 3rd screencapture in my last post - there is 1 degree in the WindowOutline Sketch; in fact 1mm also in Y-placement.

Sometime i find scroll the the mouse over the task panel change some of values in these input boxes.

[Roy_043]

BTW, it seem you can just map your WindowOutline 'directly' by Object XY (just the object's orgin no edges, not vulnerable to editing the underlying sketch)to the Sketch001 (Window's sketch) rather than the Wall's sketch (revision attached).

This is a much better solution than what I have attempted. Thank you. I am getting a better idea of the attachment options but still have a lot to learn.

I do not seem to have cyclic dependency problem? See attached file.

You are right. After the Arch Remove operation I get a "dependecy cycles" warning when I recompute the document. I have misread that warning. I believe this warning is related to another issue that is already being discussed:
0 <App> Document.cpp(2849): The graph must be a DAG.
0.39121 <App> Document.cpp(3202): WindowSill_001a#Sketch002 still touched after recompute
14.2878 <App> Document.cpp(2816): Dependency cycles:
14.2879 <App> Document.cpp(2846):
WindowSill_001a#Wall, WindowSill_001a#Extrude001, WindowSill_001a#Sketch004, WindowSill_001a#Sketch002, WindowSill_001a#Window,
<Exception> Document.cpp(2847): The graph must be a DAG.
16.2902 <App> Document.cpp(2849): The graph must be a DAG.
17.0536 <App> Document.cpp(3202): WindowSill_001a#Sketch004 still touched after recompute
17.0536 <App> Document.cpp(3202): WindowSill_001a#Sketch002 still touched after recompute
17.0537 <App> Document.cpp(3202): WindowSill_001a#Window still touched after recompute
17.0537 <App> Document.cpp(3202): WindowSill_001a#Wall still touched after recompute


In your file the SubtractorExtrude solid is one of the Subtractions of the Wall, but still (also) part of the WindowSillGroup. This is not what you get when you use the Arch Remove command. You get this result if you double-click the wall and change the Subtractions list in the task panel. I don't understand why Arch Remove has a different result.


@paullee, thank you very much for your help.

[jahwobble]

WinWithCill.FCStd

(27.98 KiB) Downloaded 25 times

SimpleWinRectCill.FCStd

(15.5 KiB) Downloaded 20 times

Here's my work-around. I've created a sketch wire for the cill with a 0.1mm offset from the outer wire. Not perfect but it cuts the wall and the gap is not noticeable except with a magnifying glass. Not good for the higher LOD stuff, of course, but workable for simpler models.

[Roy_043]

@jahwobble: Thanks for sharing.
The idea to include the sill in the window was already discussed. It can work, but is not necessarily logical. A window and a sill are usually separate objects and modeling them as such makes more sense IMO.
In your solution the window frame and the sill intersect.

Edit: spelling.