Parametric Arch modelling

A forum dedicated to the Draft, Arch and BIM workbenches development.
lambda
Posts: 34
Joined: Sat Feb 25, 2017 3:10 pm
Contact:

Parametric Arch modelling

Postby lambda » Mon Oct 30, 2017 5:35 pm

Hi,

this post is a combination of giving feedback, asking for feedback/review and exploring some ideas about future Arch tools. One of the reasons I'm writing this, is because this sentence in the Arch roadmap kind of provoked me. I hope this turns into a useful discussion:
Mech engineering parametric design is usually based on changes history and constraint solving. Those two concept have much less importance in building design, since you rarely want to crawl back in the steps you did (they are usually very simple), and keeping constraints like horizontality, angle, or distance, even if they are useful, is not as important as in mech design.
I should metion that I'm not a CAD designer, but a programmer who accidentally happens to deal with buildings a lot recently. I guess that makes me very poor at drawing things and love parametric design for the sake of it. I sure am biased.

The current Arch workflow seems to be more about automated drawing than about parametric design. I guess this works well if
  • the user is experienced drawing (ie knows how to copy and rotate objects, so they end up in the proper place)
  • the building has a rectangular shape, so it's easy to use the grid or just plainly type coordinates
  • the building is modelled from scratch or based on high quality drawings
Alas, neither is true for my use case: The building I'm working with ATM is from the 1960s, has a symmetric but not-rectangular shape and the only plan available is a scan of a paper copy of a paper copy of a paper plan. That is, lot's of distortions. Also it seems that the plan really only was used as a guilde line by the construction firm, so ultimately the building doesn't match the plan closely. Also the building is undergoing refurbishment, so things are changeing even more.

In an ideal world I would print a copy of the original plan, visit the building and note everything that's wrong in the plan and then start modelling in FreeCAD. However many wrong details are only noticed during refurbishments, which are based on the plan I'm supposed to create. So there is a need to edit the modell history.

So this is my current FreeCAD workflow:
  • draw the circumference of the building in the sketcher
  • create a second sketch and map it to the first and import the first as external geometry
  • draw the thick interior walls in the second sketch
  • create a compound of both sketches and map a third sketch to it and import most edges as external geometry again
  • draw the thin interior walls in the third sketch
  • use the three sketches as base objects for three types of Arch Walls.
This works mostly well. The references to external geometry break, when I'm adding or deleting new edges to the earlier sketches. I guess this could be fixed (without solving topological naming), but it is rarely necessary and easy to clean up after the fact. I can do things like changes that angle from 60° to 58.55° after better data becomes available and everything shifts in place nicely. (Most of the time when working with fully constrained sketches at least.)

The next thing is doors and windows. This is where the trouble starts: Windows are not really parametric objects in the way I'd need them. There is a MoveWithHost feature, but it only works when manually drawing, not when changeing constraints in the sketches of the walls. I tried several workflows so far:

1. Creating each window on its own
pros:
  • quite easy to place each window where I want it to be
  • robust against topological nameing issues (unless I attach the sketch to the face of the wall)
cons:
  • doesn't move with the host wall most of the time
  • a chore to enter parameters all the time without scripting (reading the code it seems it should be possible to use an existing window as a blue-print for the new one, but no matter which compination of windows and wall-faces I select, it doesn't work for me)
  • impractical to change the windows later without a custom macro
2. Creating one window object per window type, then cloning
pros:
  • robust against TN
  • Some parameters are easily updated globally, with others (like changing the glass into a panel) I couldn't force a recompute propagating the changes
cons:
  • difficult to move the clones in the right place without good drawing skills (again maybe there is a feature in the window-button, that I couldn't get to work yet)
  • doesn't move with the host wall most of the time
  • no way to attach windows to wall-faces AFAIK
3. Creating one window (or sketch), then cloning the sketch for each window, mapping (without referencing) the sketch to a face and creating a window on top of it
pros:
  • robost against TN (I think)
  • parameters stored in the sketch are easily updated globally
  • easy to place with the tools I know
cons:
  • still doesn't move with the host wall (but reattaching is somewhat easier I expect)
  • parameters stored in obj.WindowParts are not copied updated across objects (BTW: The Window Parts property is only visible in the properties editor after saving/reloading the document)
4. Like (3) but actually referencing the wall-face from sketch-attachment
pros:
  • finally moves with host wall
  • possible to place constraints with external geometry (but expect even more TN problems)
  • see (3)
cons:
  • suffers from TN (since each new window changes topology of the wall, probably badly so)
  • see (3)
5. This is still ongoing experimentation: Like (4) but try to reference the base shape of the wall instead of the shape of the wall itself.

In trying to solve this, I also read about Facebinder objects. However from reading the documentation in the wiki it wasn't clear to me, what they are for nor what they do. I guess this is unrelated, but just feedback that the documentation is somewhat unclear about them.
triplus
Posts: 8415
Joined: Mon Dec 12, 2011 4:45 pm

Re: Parametric Arch modelling

Postby triplus » Mon Oct 30, 2017 8:15 pm

Hi @lambda.

Note that FreeCAD doesn't say you should use Arch workbench to do Arch related work. If you would like to use more "mechanical" approach you can do just that. But on that front likely the lack of robust Assembly capability gets in the way ATM a bit.

P.S. Then again looking for some reference i am guessing Arch workbench in its current form definitely represents a viable option for such work:

https://forum.freecadweb.org/viewtopic. ... 70#p197270
User avatar
yorik
Site Admin
Posts: 11371
Joined: Tue Feb 17, 2009 9:16 pm
Location: São Paulo, Brazil
Contact:

Re: Parametric Arch modelling

Postby yorik » Tue Oct 31, 2017 1:37 pm

This is a great sum up...

I would say indeed you are digging up many of the problems and inconsistencies of the whole windows system. Honestly I haven't found a clear path to solve them all at once yet. The main issue I always wanted to address first is flexibility: That you would be able to simply do ANY kind of window that your wicked mind would imagine. I believe that's really what's working best now.

The issue of duplicating windows is another tricky thing. In other BIM apps like Revit, where everything is a family, there is no such thing as a "standalone object". In FreeCAD, it's the contrary, everything is a standalone object, although they can have links. This makes it a bit unclear (at least to me) how to best address when you want separate objects to behave as "one".

My own "preferred" way would be the cloning behaviour. You define one window, then others are clones of it. They can be moved and rotated around, but that's it. All the other properties would be from the original object. This in fact works most closely to a revit family. All Arch objects have this cloning capability, so more or less they can all become "a family".

It is true that the clone window cannot be moved the same way as a sketch-based one. I personally mostly use Draft snapping to move these things around, so it doesn't make much difference, but we might think of something better there...

Someone else also reported problems with the "move with host" feature. And in any case I'm far from happy with it yet, it only works with Draft Move, etc. So it needs a bit of work, I'll look at it ASAP.
User avatar
bernd
Posts: 8018
Joined: Sun Sep 08, 2013 8:07 pm
Location: Zürich, Switzerland

Re: Parametric Arch modelling

Postby bernd » Wed Nov 01, 2017 10:33 am

lambda wrote:
Mon Oct 30, 2017 5:35 pm
So this is my current FreeCAD workflow:
  • draw the circumference of the building in the sketcher
  • create a second sketch and map it to the first and import the first as external geometry
  • draw the thick interior walls in the second sketch
  • create a compound of both sketches and map a third sketch to it and import most edges as external geometry again
  • draw the thin interior walls in the third sketch
  • use the three sketches as base objects for three types of Arch Walls.
I need separate wall objects for every thickness or different material, because walls have some BIM attributes
  • draw a sketch of lines
  • copy sketch (no parametric!)
  • convert sketch to wires
  • use this wires to build up walls
if something changes
  • change the sketch
  • move the wires the walls are based on around
  • the walls changes too
once if the topological naming problem would be solved in a few years ... :mrgreen: there would be no need to convert the sketch to wires anymore.

bernd
lambda
Posts: 34
Joined: Sat Feb 25, 2017 3:10 pm
Contact:

Re: Parametric Arch modelling

Postby lambda » Thu Nov 02, 2017 5:01 pm

@triplus: Yes, I know that I don't have to use the Arch workbench, but it does offer lot's of good stuff, so better pondering how to improve it than to bypass it completely...

@bernd do I understand you correctly: You are drawing the entire wall plan (of one floor) in one sketch, then convert to drawing and then use selected edges/wires from the drawing to raise the walls? When your sketch changes, then you manually adjust the drawing to fit the sketch? I guess with snapping this can work.

I agree that lots of the issues discussed in this thread come from working around TN issues. Having at least a partial solution (like robust references to edges drawn by the user directly) would already help a lot.
The issue of duplicating windows is another tricky thing. In other BIM apps like Revit, where everything is a family, there is no such thing as a "standalone object". In FreeCAD, it's the contrary, everything is a standalone object, although they can have links. This makes it a bit unclear (at least to me) how to best address when you want separate objects to behave as "one".
I think the FreeCAD way would be to have something like a local (per document) object library, where the user can define objects to reference them from other objects in the same document. I guess PDN/assembly will provide that, so maybe there isn't much to do on the Arch side of things. Though we will need to figure out how to get the metadata for BIM into this system.
It is true that the clone window cannot be moved the same way as a sketch-based one. I personally mostly use Draft snapping to move these things around, so it doesn't make much difference, but we might think of something better there...
And it isn't just about windows either. I'd like to attach a lot of (not jet implemented) objects too: Heaters, power outlets, switches... anything that is fixed to a wall and is relevant.

But back to the current issue of windows: I did some experiments with option (5) above and it kind of works: I can clone the sketch of a wall, attach it to an edge plus a vertex of the base shape of the wall in NormalPlane mode. Then I copy the WindowParts property over in the python console as well as a few others and manually set the Host (currently it get's set to the base sketch of the Wall by default).

This mostly works (not entirely reliable, but I haven't narrowed it down yet), but there is one strange issue. When I add these Windows to a Section, then I get an error from the corresponding ArchView:

Code: Select all

App::Document::_RecomputeFeatuer(): Unknown exception in Feature "ArchView" thrown
I'm quite surprised and don't know how to debug this ATM.

Here is the model, in case somebody wants to have a look:
http://friends.ccbib.org/lambda/B12-real.fcstd

However after reflecting the tinkering with this I think, that it should be possible to write some better attachment properties for Arch objects. The attachment of the sketcher objects suffers from being very general. But in Arch most of the time (ie when a wall get's risen on a base wire) we know (or at least could know) the direction of extrusion of the wall. I don't know how easy it would be to get the base edge of a wall face, but it the user selects the right edge, it should be possible for a wall object to provide the direction of extrusion as the necessary second vector to construct a local coordinate system. This should be enough to move objects with the host, ie attach them.

I'm not sure if in the end I will have the time, but if you think this idea is feasable I might try to implement an AttachedComponent class on the above principles. This could then be used to derive other classes from it.
User avatar
bernd
Posts: 8018
Joined: Sun Sep 08, 2013 8:07 pm
Location: Zürich, Switzerland

Re: Parametric Arch modelling

Postby bernd » Fri Nov 03, 2017 6:42 am

lambda wrote:
Thu Nov 02, 2017 5:01 pm
@bernd do I understand you correctly: You are drawing the entire wall plan (of one floor) in one sketch, then convert to drawing and then use selected edges/wires from the drawing to raise the walls? When your sketch changes, then you manually adjust the drawing to fit the sketch? I guess with snapping this can work.
Exactly. but make a copy before convert the sketch. If later something changes I adapt the sketch an move around the edges my walls are based on with moving tools and snap to the adjusted sketch. I'm not 100 % sure this is best but I do not know any better ATM.
lambda
Posts: 34
Joined: Sat Feb 25, 2017 3:10 pm
Contact:

Re: Parametric Arch modelling

Postby lambda » Fri Nov 03, 2017 11:34 am

lambda wrote:
Thu Nov 02, 2017 5:01 pm
When I add these Windows to a Section, then I get an error from the corresponding ArchView:

Code: Select all

App::Document::_RecomputeFeatuer(): Unknown exception in Feature "ArchView" thrown
I'm quite surprised and don't know how to debug this ATM.
I have been able to narrow this down now: The problem is triggered by selecting "Opening mode" as "Arc 90" or "Arc 45". There is no problem with "Arc 90 inv" or "Arc 45 inv". I guess this is just a bug in the ArchView. However since I only get the exception without backtrace and line numbers, I don't know where to look for the error.
lambda
Posts: 34
Joined: Sat Feb 25, 2017 3:10 pm
Contact:

Re: Parametric Arch modelling

Postby lambda » Fri Nov 03, 2017 6:25 pm

Searching the forum for the error message suggests, that this might be caused by old OCC (newest OCE actually), so I will try updateing this.

Edit: With OCC the problem is indeed gone.
paullee
Posts: 1588
Joined: Wed May 04, 2016 3:58 pm

Re: Parametric Arch modelling

Postby paullee » Sun Nov 05, 2017 3:51 am

lambda wrote:
Mon Oct 30, 2017 5:35 pm

In an ideal world I would print a copy of the original plan, visit the building and note everything that's wrong in the plan and then start modelling in FreeCAD. However many wrong details are only noticed during refurbishments, which are based on the plan I'm supposed to create. So there is a need to edit the modell history.

So this is my current FreeCAD workflow:
  • create a second sketch and map it to the first and import the first as external geometry
  • create a compound of both sketches and map a third sketch to it and import most edges as external geometry again
This works mostly well. The references to external geometry break, when I'm adding or deleting new edges to the earlier sketches. I guess this could be fixed (without solving topological naming), but it is rarely necessary and easy to clean up after the fact.

My experience is that Link to external geometry is big problem that I avoid myself from using it ever again. It just prevent design development - any need to change the underlying sketch will break the parents geometries / models definitely! I have suffered a lot from that.

If there is a fixed plan to build a model from, link to external geometry has less problem.

I spend quite sooome time experimenting using sketches + learning python script to build walls on sketches recently (and going through previous post here -far from finish), trying to link sketches in 'low-tech' way but never use link to external geometry. Using sketch, i find in the interim, have some pros but issues in maintaining (I just know very basic of FC and python script) - hope somebody had done something with this workflow and share experience if it works or not.
paullee
Posts: 1588
Joined: Wed May 04, 2016 3:58 pm

Re: Parametric Arch modelling

Postby paullee » Sun Nov 05, 2017 4:00 am

lambda wrote:
Fri Nov 03, 2017 11:34 am
lambda wrote:
Thu Nov 02, 2017 5:01 pm
When I add these Windows to a Section, then I get an error from the corresponding ArchView:

Code: Select all

App::Document::_RecomputeFeatuer(): Unknown exception in Feature "ArchView" thrown
I'm quite surprised and don't know how to debug this ATM.
I have been able to narrow this down now: The problem is triggered by selecting "Opening mode" as "Arc 90" or "Arc 45". There is no problem with "Arc 90 inv" or "Arc 45 inv". I guess this is just a bug in the ArchView. However since I only get the exception without backtrace and line numbers, I don't know where to look for the error.
lambda wrote:
Fri Nov 03, 2017 6:25 pm
Searching the forum for the error message suggests, that this might be caused by old OCC (newest OCE actually), so I will try updateing this.

Edit: With OCC the problem is indeed gone.
Just curious if you are using OCC7.10, AppImage or whatwever to have problem solved?

I am on Fedora which has OCE 0.6.8 only - Przemof had tried to help me to built a rpm of latest OCC for Fedora, but i have too little knowledge (+ time) to make it.

paullee wrote:
Sat Aug 26, 2017 5:05 pm
Thanks for Regis test above, and Triplus hint to use AppImage for FC0.17_pre which included OCC7.1.0. i have posted test results for other 2 recent 'bugs' I reported separately.

Seem combination of FC0.17_pre + OCC7.1.0 in AppImage has 'solved' most problem- those that FC0.17_pre + OCE6.8.0 on Fedora 25 have.


Similarly, the problems reported here are 'solved'.

As I share my thought in this thread https://forum.freecadweb.org/viewtopic. ... 19#p188219, I think it would be better if some well-known repository if not Fedora itself (if afterall OCC7.1.0 or otherwise is the 'cure') would better build the OCC7.1.0 update for Fedora 25 (and other versions) so that all users have consistent result. Even more ideal if FC 0.17_pre could accommodate OCE6.8.0 to enable a consistent be generated.

Hope it helps.