IFC export of a link object based on an arch object

[DDM]

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]

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]

...
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.

[bernd]

moved to ifc and agree with vocx.

[yorik]

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]

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)

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)

[paullee]

@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)

[yorik]

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]

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 (397.57 KiB) Viewed 4529 times

Screenshot from 2020-04-08 19-41-59.png (203.66 KiB) Viewed 4529 times

EDIT
- revised screencapture shown IfcBuildingElementProxy

Screenshot from 2020-04-08 19-59-10.png (94.48 KiB) Viewed 4523 times

[yorik]

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 (62.58 KiB) Viewed 4500 times

Let's see if this behaves well, then we can look further into other structures