[Discussion] A different approach to Arch modelling (Arch Assembly?)

A forum dedicated to the Draft, Arch and BIM workbenches development.
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
paullee
Veteran
Posts: 5097
Joined: Wed May 04, 2016 3:58 pm

Re: [Discussion] A different approach to Arch modelling (Arch Assembly?)

Post by paullee »

Look forward to your further development :)
User avatar
yorik
Founder
Posts: 13640
Joined: Tue Feb 17, 2009 9:16 pm
Location: Brussels
Contact:

Re: [Discussion] A different approach to Arch modelling (Arch Assembly?)

Post by yorik »

I think using Part Attachments or any other forms of creating embeddable coordinate systems such as App Parts would be a good thing to mimmick the IFC placements system indeed. But IMHO this placements system is very overkill and in many case a counter-intuitive burden. Sometimes a simple object is placed into 3 or 4 stacked coordinate systems. But most of the time I want real coordinates for my stuff, I want the placement of a column to be the exact coordinate of the start of the column in the 3D space.

So I wouldn't welcome an automatic, hard-coded system. In many case I WANT complex IFC coordinates to be "resolved" into a simple FreeCAD placement, and be able to have a level with columns in it, period. No intermediary structure.

But we could allow an intermediary structure, for users who want it, that allow users to introduce intermediary coordinate systems. I would favor using BuildingParts for it... It could maybe be extended to be used as an App::Part?
User avatar
thomas-neemann
Veteran
Posts: 11801
Joined: Wed Jan 22, 2020 6:03 pm
Location: Osnabrück DE 🇩🇪
Contact:

Re: [Discussion] A different approach to Arch modelling (Arch Assembly?)

Post by thomas-neemann »

yorik wrote: Tue Dec 07, 2021 1:12 pm
+1
Gruß Dipl.-Ing. (FH) Thomas Neemann

https://www.youtube.com/@thomasneemann5 ... ry=freecad
paullee
Veteran
Posts: 5097
Joined: Wed May 04, 2016 3:58 pm

Re: [Discussion] A different approach to Arch modelling (Arch Assembly?)

Post by paullee »

For me, both below information that is useful

  1. 'absolute' coordinate, and
  2. the "setting-out figures" relative from a Space / Room
    - e.g. this Door is put at 100mm from this corner of Room A
    - the ceiling light electricity junction box is at the centre of the Room etc.
carlopav
Veteran
Posts: 2062
Joined: Mon Dec 31, 2018 1:49 pm
Location: Venice, Italy

Re: [Discussion] A different approach to Arch modelling (Arch Assembly?)

Post by carlopav »

Oh, it was a while since we had such interesting conversation, always a pleasure :) disclaimer, long post ahead.
I have several concerns: update Arch to take advantage of more recent FreeCAD development, remove redundant python code using what FreeCAD offers in c++ (expecially if it is more efficient and less buggy), IFC compatibility (BlenderBIM is an extremely interesting experiment), tidy tree structure for medium size projects, and, expecially, try to tackle the long term problems we have with moving a window with a wall and being able to undo it properly (this come out from time to time in the forum). And no time at the moment to code :lol: :lol: But this will change a day, so i'm trying to get ready for that day studying what I can in the few spare minutes...

yorik wrote: Tue Dec 07, 2021 1:12 pm I think using Part Attachments or any other forms of creating embeddable coordinate systems such as App Parts would be a good thing to mimmick the IFC placements system indeed. But IMHO this placements system is very overkill and in many case a counter-intuitive burden. Sometimes a simple object is placed into 3 or 4 stacked coordinate systems. But most of the time I want real coordinates for my stuff, I want the placement of a column to be the exact coordinate of the start of the column in the 3D space.

I do not have the knowledge to criticize the way an international standard was created... so I just assume that if IFC implemented it, it's not just me that find it useful, but I'm in good company :) About how to mimic it in FreeCAD, I agree that if you or anyone else wants to turn every IFC coordinates to global on import (current behavior), you should be allowed to do it, without any burded on your usability, that's out of question.
But that's exactly how Part::Attachment works, you can or you cannot use it... like the MoveWithHost property... because the absolute placement of objects is always preserved and displayed, both if you use Part::Attachment or not. So in the end I really do not understand your sentence above.

So I wouldn't welcome an automatic, hard-coded system. In many case I WANT complex IFC coordinates to be "resolved" into a simple FreeCAD placement, and be able to have a level with columns in it, period. No intermediary structure.

And in fact I do not see any problem with this... Did you try to play with obj.addExtension("Part::AttachExtensionPython")? Apart the fact that current DraftTools do not change the AttachmentOffset property (but that's not difficult to extend them like I did to consider nested placements in App::Part), It looks a quite flexible structure, that does not look like an intermediary structure.

But we could allow an intermediary structure, for users who want it, that allow users to introduce intermediary coordinate systems. I would favor using BuildingParts for it... It could maybe be extended to be used as an App::Part?

Can you elaborate intermediary structure? I do not understand... expecially the App::Part reference: it's a completely different behaviour: this would break your possibility to use absolute placements for every object... Or better, you can always get absolute coordinates, but they are not displayed and stored in the object properties...

I would favor using BuildingParts for it...
Why not...

paullee wrote: Tue Dec 07, 2021 8:16 pm [*] 'absolute' coordinate, and
[*] the "setting-out figures" relative from a Space / Room
- e.g. this Door is put at 100mm from this corner of Room A
- the ceiling light electricity junction box is at the centre of the Room etc.
[/list]
for absolute coordinates, that's exactly what i was talking about, to keep the absolute placement for every object and mimic IFC Placement chain with Part::Attachment.
for the other, I do not see any problem with it, just IMHO you should check which rules you should follow when exporting to IFC, because, being a standard, you cannot expect it to be able to receive and store every information you can create in FreeCAD (or if it can, that those information will be displayed correctly by other people importing that IFC in other softwares, like BlenderBIM).
follow my experiments on BIM modelling for architecture design
paullee
Veteran
Posts: 5097
Joined: Wed May 04, 2016 3:58 pm

Re: [Discussion] A different approach to Arch modelling (Arch Assembly?)

Post by paullee »

carlopav wrote: Wed Dec 08, 2021 2:21 pm ...and, expecially, try to tackle the long term problems we have with moving a window with a wall and being able to undo it properly (this come out from time to time in the forum). And no time at the moment to code :lol: :lol: But this will change a day, so i'm trying to get ready for that day studying what I can in the few spare minutes...
It do not use that feature so "immune" from this problem :mrgreen: It's a pity peoples with coding knowledge like you are tied up at the moment, hope you have more leisure time soon :D

carlopav wrote: Wed Dec 08, 2021 2:21 pm for absolute coordinates, that's exactly what i was talking about, to keep the absolute placement for every object and mimic IFC Placement chain with Part::Attachment.
for the other, I do not see any problem with it, just IMHO you should check which rules you should follow when exporting to IFC, because, being a standard, you cannot expect it to be able to receive and store every information you can create in FreeCAD (or if it can, that those information will be displayed correctly by other people importing that IFC in other softwares, like BlenderBIM).
I have not much idea about IFC. But coordinate information about an element (door / window) 's position in relation to a space/room, is what make sense for the 'i' in BIM to me. It is usually the information surveyor needs to set out on site rather than a 'world coordinate'. Any surveyor here ? :D
User avatar
yorik
Founder
Posts: 13640
Joined: Tue Feb 17, 2009 9:16 pm
Location: Brussels
Contact:

Re: [Discussion] A different approach to Arch modelling (Arch Assembly?)

Post by yorik »

carlopav wrote: Wed Dec 08, 2021 2:21 pm And in fact I do not see any problem with this... Did you try to play with obj.addExtension("Part::AttachExtensionPython")? Apart the fact that current DraftTools do not change the AttachmentOffset property (but that's not difficult to extend them like I did to consider nested placements in App::Part), It looks a quite flexible structure, that does not look like an intermediary structure.
...
Can you elaborate intermediary structure? I do not understand... expecially the App::Part reference: it's a completely different behaviour: this would break your possibility to use absolute placements for every object... Or better, you can always get absolute coordinates, but they are not displayed and stored in the object properties...
I mean in IFC, a simple object like a column is often stacked in 4 or 5 different coordinate systems: The base profile of the column has one, then the extrusion, then the representation, then the IfcProduct itself. If we want FreeCAD to stick 100% to the IFC model, we need to recreate all of them. Otherwise, doing only the half of it doesn't make sense... This basically means complexify the FreeCAD model by an order or 4 or 5. For me it's a wrong way to go.

What I would like instead, which seems to me a much more interesting way, is to go the BlenderBIM way: In FreeCAD, we keep things simple, ie. one object per IfcProduct. But each object is "driven" by BlenderBIM (I introduced that in another thread (or is it this one?) that Arch objects could have different "engines"). The BlenderBIM structure keeps all the complex 4-placements hierarchy, and what's presented in FreeCAD is the resolved, one-object thing.

I'm not saying using local coordinate systems is not possible, I fully support that users who want it should be able to do it. Just that I personally don't, and I would not like being forced to it, I'm sure I'm not the only one.

But I don't really understand what exactly would be the benefit of adding an attachment extension to arch objects? I think it wouldn't solve the wall/window problem, because it would reintroduce a circular dependency... Could you give an example of use case?
User avatar
thomas-neemann
Veteran
Posts: 11801
Joined: Wed Jan 22, 2020 6:03 pm
Location: Osnabrück DE 🇩🇪
Contact:

Re: [Discussion] A different approach to Arch modelling (Arch Assembly?)

Post by thomas-neemann »

yorik wrote: Thu Dec 09, 2021 10:09 am

+1

i am of the opinion that the current ifc file from freecad can do everything that is needed for geometric work in a bim process.


edit

frecad is a program to create geometries
Gruß Dipl.-Ing. (FH) Thomas Neemann

https://www.youtube.com/@thomasneemann5 ... ry=freecad
User avatar
thomas-neemann
Veteran
Posts: 11801
Joined: Wed Jan 22, 2020 6:03 pm
Location: Osnabrück DE 🇩🇪
Contact:

Re: [Discussion] A different approach to Arch modelling (Arch Assembly?)

Post by thomas-neemann »

paullee wrote: Wed Dec 08, 2021 3:14 pm ... It is usually the information surveyor needs to set out on site rather than a 'world coordinate'. ...
i am not a professional surveyor. for my customers, the building is measured locally on the property. connections for drainage pipes are now often world coordinates

i am of the opinion that the current ifc file from freecad is sufficient to generate geometric data for bim processes. the architects in my clientele don't want to enter any attributes, others should do that with a program of their choice
Gruß Dipl.-Ing. (FH) Thomas Neemann

https://www.youtube.com/@thomasneemann5 ... ry=freecad
paullee
Veteran
Posts: 5097
Joined: Wed May 04, 2016 3:58 pm

Re: [Discussion] A different approach to Arch modelling (Arch Assembly?)

Post by paullee »

carlopav wrote: Tue May 19, 2020 12:56 pm ex:
the Part have Height=1200
the Binder have Height=900
if I point to the Binder.Support[0][0].WallVoid.Shape, this Part::Box will have its Height = 1200 and not 900... right?

EDIT:
Can I access the temporary linked App::Part from the Binder object (the mutated one)? This Part should have the correct WallVoid object...

In the meantime i'm imaging if I can change what was thinking to match a possible usable pattern and mix Link and SubShapeBinder, so we have a "real" varied Link that contain the right WallVoid object that I can point to from the SubShapeBinder:

Cattura.JPG

Probably also that could work... But is it good to have all those temporary documents? Do this inpact on performace if we have let's say 200 windows objects and 50 variations of them?

Inheritance asm3.FCStd

Revisiting the concept / workflow here, can you post a example model to show the workflow ? :)

The SubShaperBinder with CopyOnChange to produce variants and then App:Link to do instances? Or the other way round ?

Thanks.
Post Reply