IFC export of a link object based on an arch object

This forum section is only for IFC-related issues
DDM
Posts: 85
Joined: Tue Feb 05, 2019 9:06 am

IFC export of a link object based on an arch object

Postby DDM » Wed Apr 01, 2020 12:39 pm

Hello,

I tried to export a link object based on an arch object, but without success...

Does IFCexport support link objects? Should I set something in the Import/Export preferences?

Thanks for your answers...
Marco
paullee
Posts: 3521
Joined: Wed May 04, 2016 3:58 pm

Re: IFC export of a link object based on an arch object

Postby paullee » Wed Apr 01, 2020 3:29 pm

DDM wrote: Wed Apr 01, 2020 12:39 pm Hello,

I tried to export a link object based on an arch object, but without success...

Does IFCexport support link objects? Should I set something in the Import/Export preferences?

Thanks for your answers...
Marco
@Realthundar should have added code which help to support this, not sure if all usecases have been solved.

Check this model - the columns are made with Link.
https://forum.freecadweb.org/viewtopic. ... 6&start=20
https://forum.freecadweb.org/viewtopic.php?f=24&t=42923

Post here what is not doing correctly to help bug fix.
vocx
Posts: 5205
Joined: Thu Oct 18, 2018 9:18 pm

Re: IFC export of a link object based on an arch object

Postby vocx » Wed Apr 01, 2020 7:24 pm

DDM wrote: Wed Apr 01, 2020 12:39 pm ...
Does IFCexport support link objects? Should I set something in the Import/Export preferences?
...
I don't think most of Draft and Arch has been upgraded to use App Link objects.

What is essentially used by different functions is the Shape attribute of an object. But in different cases the code doesn't test for this Shape correctly. Why? Because it assumes that they are Part Features. App Links aren't Part Features, but do have Shapes, so the code needs to check appropriately for the existence of a Shape, and not only whether it's a Part Feature or not.

So, we need more time to debug and test more usecases. If you can provide things that work and things that don't work, we could investigate.
Always add the important information to your posts if you need help. Also see Tutorials and Video tutorials.
To support the documentation effort, and code development, your donation is appreciated: liberapay.com/FreeCAD.
User avatar
bernd
Posts: 11667
Joined: Sun Sep 08, 2013 8:07 pm
Location: Zürich, Switzerland

Re: IFC export of a link object based on an arch object

Postby bernd » Wed Apr 01, 2020 9:23 pm

moved to ifc and agree with vocx.
User avatar
yorik
Site Admin
Posts: 12229
Joined: Tue Feb 17, 2009 9:16 pm
Location: Brussels, Belgium
Contact:

Re: IFC export of a link object based on an arch object

Postby yorik » Thu Apr 02, 2020 10:46 am

The thing here is that there is a difference of opinions among some people... And it difficults also things in Arch. Originally, any object that had a shape would be derived from Part::Feature. This would ensure an absolute, programmers way to know if an object had a shape. If it is derived from Part::Feature, it's a shape. Otherwise not. Now, with the merges from realthunder, the situation has become much more difficult to assess. Several objects that are not a Part::Feature anymore have a shape. Even groups! And it's not clear anymore what the "Shape" property of an object is meant to be.

And it's often tricky: Should you consider a group as a shape-based object or not?

Until now the IFC exporter works the classical way: If an object is Shape-based (derived from Part::Feature), it is exported as an IFC object. If not, unless it's a known Arch container (BuildingPart, Building,...), it is discarded.

We should add support for App Links of course. But it is not fully clear to me how they should be treated yet...
carlopav
Posts: 1748
Joined: Mon Dec 31, 2018 1:49 pm
Location: Venice, Italy

Re: IFC export of a link object based on an arch object

Postby carlopav » Sat Apr 04, 2020 9:49 am

yorik wrote: Thu Apr 02, 2020 10:46 am And it's often tricky: Should you consider a group as a shape-based object or not?
This is not the only problem: links also affect heavily the position of objects.
The same object can be represented in the scene not only one time, but several times.
So if you ask the object about its Placement, you have to be sure about which instance of the object you are asking too... You can't anymore just ask obj.getGlobalPlacement(), because if there is a link in the object tree, the result will be wrong.

At the moment the only thing that almost fully support link is Draft Autogroup function. (not fully because if the link is scaled, the function is skipped)
yorik wrote: Thu Apr 02, 2020 10:46 am We should add support for App Links of course. But it is not fully clear to me how they should be treated yet...
PS. why don't we open a thread and ping it to the top about Link integration in Draft/Arch/Bim? (It should also concern App::Part to me, because neither that is supported)
follow my experiments on BIM modelling for architecture design
paullee
Posts: 3521
Joined: Wed May 04, 2016 3:58 pm

Re: IFC export of a link object based on an arch object

Postby paullee » Sat Apr 04, 2020 10:40 am

@Realthunder had done something in ArchWB to make it aware of Link.... I forget what exactly and where it is...

[EDIT]

e.g.

LinkArray
https://forum.freecadweb.org/viewtopic. ... 20#p349057

Yet to test if it directly output to IFC ( for IFC attribute reason, I encapsulate it in ArchWall / Structure and it export, probably as BRep)
User avatar
yorik
Site Admin
Posts: 12229
Joined: Tue Feb 17, 2009 9:16 pm
Location: Brussels, Belgium
Contact:

Re: IFC export of a link object based on an arch object

Postby yorik » Wed Apr 08, 2020 10:34 am

Ok it is also a problem for Arch Refs. I think no need to start a new thread because this one is really about it.

Right now in IFC you have a structure called MappedRepresentation: One object can be used by several "instances". A bit like an AutoCAD block. We use that for ex. with clones. This can be used too for links. Obtaining the global placement is easy.

So the big question is: How to treat objects that contain or reference or link to potentially many other objects?

There is no proper structure in IFC to define a "reusable component" that would be made of several other objects. The closest thing is an IfcElementAssembly. But it's not used much and for ex. Revit will render an IfcElementAssembly as one big object, and won't allow to access its subelements.

The most "compatible" way would be to create objects/clones/mapped items of all individual objects inside the reference/link. But I find this pretty messy... It will undo all your careful model organization.

Maybe it's not our problem what Revit wants, and we should use an IfcElementAssembly for all these? Best of the best would of course allow uers to choose between both ways.

Maybe the best would be to start building a couple of simple test files...
paullee
Posts: 3521
Joined: Wed May 04, 2016 3:58 pm

Re: IFC export of a link object based on an arch object

Postby paullee » Wed Apr 08, 2020 11:48 am

Somehow, tested below:-
  1. 2 Link Array of Structure (extrusion of circle) as columns
  2. Exported to IFC
  3. Both Array re-imported into FC as dummy objects, seems no one columns less
  4. The same is opened in Ifc++ (Bernard repo) on fedora 31
Screenshot from 2020-04-08 19-42-24.png
Screenshot from 2020-04-08 19-42-24.png (397.57 KiB) Viewed 906 times
Screenshot from 2020-04-08 19-41-59.png
Screenshot from 2020-04-08 19-41-59.png (203.66 KiB) Viewed 906 times
EDIT
- revised screencapture shown IfcBuildingElementProxy
Screenshot from 2020-04-08 19-59-10.png
Screenshot from 2020-04-08 19-59-10.png (94.48 KiB) Viewed 900 times
Attachments
Test_LinkArrary_01.ifc
(308.27 KiB) Downloaded 21 times
User avatar
yorik
Site Admin
Posts: 12229
Joined: Tue Feb 17, 2009 9:16 pm
Location: Brussels, Belgium
Contact:

Re: IFC export of a link object based on an arch object

Postby yorik » Fri Apr 10, 2020 12:34 pm

Okay with git commit aed8c9140 ortho arrays are now exported as IfcElementAssemblies with, inside, cloned elements:
Screenshot from 2020-04-10 14-30-49.png
Screenshot from 2020-04-10 14-30-49.png (62.58 KiB) Viewed 877 times
Let's see if this behaves well, then we can look further into other structures