Big rewrite of extrusion-based Arch objects and IFC export

This forum section is only for IFC-related issues
Post Reply
User avatar
yorik
Founder
Posts: 13640
Joined: Tue Feb 17, 2009 9:16 pm
Location: Brussels
Contact:

Big rewrite of extrusion-based Arch objects and IFC export

Post by yorik »

I pushed today git commit 65aaf16 which redefines a lot of things inside the Arch workbench. I did quite intense testing, but there might still be issues here and there. Symptoms would be Arch objects that are based on extrusion (walls, structures and panels) that behave differently, or that might have "jumped" out of place when opening an old file. Hopefully there won't be many. If you see something, report back and I'll try to fix ASAP.

These changes are basically to behave more like IFC wants, so the export to IFC became better. While, in FreeCAD, we don't care much if a particular object is an extrusion or not, for other apps like Revit it is crucial. So this now allows many more objects to be exported as extrusions.

The problem was that IFC wants extrusions to be done in a very specific manner: The profile must be on the XY plane, and rotated/moved into place only after it was extruded. That is the main reason for the changes below.

What has changed:

- All Arch objects now have a getExtrusionData() method, that returns a (2dprofile, extrusionVector, placement) tuple, or None if this object is not an extrusion. The 2D profile is ALWAYS in the XY plane, and centered on the origin point. The placement must be applied to both the profile and the extrusion vector, before extruding, in order to produce the final shape. By default, it returns an empty tuple, unless this object is a clone of an extruded object, or if its base object is a Part Extrusion.

- The getExtrusionData() is meant to be reimplemented by all Arch objects that perform such extrusions. So far only walls and structures have one. The execute() function makes

- The IFC exporter now uses this system, and is -as far as i tested- able to export any extruded object correctly. Additionally, this can also save quite a lot of filesize, since profiles are now stored and shared between the different extrusions.
User avatar
bernd
Veteran
Posts: 12849
Joined: Sun Sep 08, 2013 8:07 pm
Location: Zürich, Switzerland
Contact:

Re: Big rewrite of extrusion-based Arch objects and IFC export

Post by bernd »

wow cool. Since I use export of ifc quite often and use latest master for this I will keep an eye on this.
User avatar
saso
Veteran
Posts: 1920
Joined: Fri May 16, 2014 1:14 pm
Contact:

Re: Big rewrite of extrusion-based Arch objects and IFC export

Post by saso »

Sounds very promising and after a few quick tests I also did not find any issues... Again, Thank you! :)
User avatar
yorik
Founder
Posts: 13640
Joined: Tue Feb 17, 2009 9:16 pm
Location: Brussels
Contact:

Re: Big rewrite of extrusion-based Arch objects and IFC export

Post by yorik »

We now have several ways to put some "parametricism" into an IFC file:
- using clones (this uses an IfcMappedRepresentation, the IFC way to share shapes
- basing several elements on a same profile

One thing I tried to do but didn't succeed, is this: Some objects are based on extrusions, some not. For example, several Arch structures based on a Part Box. The ideal would be to export the box geometry representation once, and have the different structure objects use the same representation. Unfortunately that didn't seem to work well in my tests (the IFC object can apparently not have a different placement than its representation).

So a further step would be to detect such objects and make them IfcMappedRepresentations too.

But I'm also interested in the new serializer that IfcOpenShell has, the export is really fast! Unfortunately only IfcOpenShell seems to support the IfcAdvancedBrep object :D I can't test anywhere!
User avatar
bernd
Veteran
Posts: 12849
Joined: Sun Sep 08, 2013 8:07 pm
Location: Zürich, Switzerland
Contact:

Re: Big rewrite of extrusion-based Arch objects and IFC export

Post by bernd »

Could you post an example? Allplan has a BIM cloud supporting IFC4 import already. They may support the IfcAdvancedBrep. AFAIK IfcAdvancedBrep was introduced with IFC2x4 but most CAD only support IFC2x3
paullee
Veteran
Posts: 5098
Joined: Wed May 04, 2016 3:58 pm

Re: Big rewrite of extrusion-based Arch objects and IFC export

Post by paullee »

yorik wrote:I pushed today git commit 65aaf16 which redefines a lot of things inside the Arch workbench. I did quite intense testing, but there might still be issues here and there. Symptoms would be Arch objects that are based on extrusion (walls, structures and panels) that behave differently, or that might have "jumped" out of place when opening an old file. Hopefully there won't be many. If you see something, report back and I'll try to fix ASAP.

These changes are basically to behave more like IFC wants, so the export to IFC became better. While, in FreeCAD, we don't care much if a particular object is an extrusion or not, for other apps like Revit it is crucial. So this now allows many more objects to be exported as extrusions.
...
Hi, I am not sure if i am suffering from some bug related to this.

I have been struggling fixing the normal axis of projections (window head, cill etc.) on a facade... [In fact, I had problem of understanding the Normal Axis is global or Local in fact...]. The current problem is:-

I have many facades (supposed to be) look like this with window head, cill, other projections in Image 1.
(Image 1)

But now it look like this in Image 2 - the window head and two side projection go opposite direction.
(Image 2)
(Image 3)


In fact, the full story is longer and way back earlier -
i worked out this and other facades in FC 0.16. Default normal for all these projections (Arch Structure based on Sketch) is 0,0,0; after some while saving, re-opening, editing, some projections go in 'wrong directions' (randomly?) and I had, some of these projections in these direction Normal 'fixed' to x=-1 - the 'absolute' 'global coordinates' I thought, then they go in the 'correct' direction 'supposed to be' as shown in Image 1)

Recently, when I edit these facades in FC0.17, they go in wrong directions again. Now it seems the Normal of these projection needs to become 'Local Coordinates'.
I struggle 'fixing' all projections (many other not included in the *.fcstd below) Normal z=1 (the 'Local Coordinates'?)
[Image 4 - examples of projections highlighted with z=1]

However, whilst all other projections direction 'fixed' by setting z=1, this particular projection on this particular facade do not fix with z=1 but z=-1!?
(Note in the Image 1 'Opposed to be', in fact I had this projection Normal z set to -1 to 'falsify' this 'supposed to be' image for this post)

I have checked the underlying sketch seem have the normal on the 'correct' direction.

I have tested with Version: 0.17.9747 & Version: 0.17.10236 but no luck, same result.

p.s.
The 2 windows transparency were set to 85, but sometime it doen't work as shown in Imag3.

Any idea? Thanks!


[Image 1 - Supposed to be]
Screenshot from 2017-02-24 03-09-46.png
Screenshot from 2017-02-24 03-09-46.png (198.8 KiB) Viewed 3029 times
[Image 2 - Now it is - - - had all projections Normal 'fixed' to z=1, used to be x=-1 to work]
Screenshot from 2017-02-24 02-26-51.png
Screenshot from 2017-02-24 02-26-51.png (213.04 KiB) Viewed 3029 times
[Image 3 - the particular projection go in 'opposite' direction?]
Screenshot from 2017-02-24 02-52-20.png
Screenshot from 2017-02-24 02-52-20.png (240 KiB) Viewed 3029 times
[Image 4 - some examples of projections Normal 'fixed' to z=1, used to be x=-1 to work]
Screenshot from 2017-02-24 02-27-47.png
Screenshot from 2017-02-24 02-27-47.png (231.35 KiB) Viewed 3029 times

OS: Linux
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.17.9747 (Git)
Build type: None
Branch: master
Hash: f5c0f579cbd7ce668727f8835946e4e9abc0eec6
Python version: 2.7.6
Qt version: 4.8.6
Coin version: 4.0.0a
OCC version: 6.8.0.oce-0.17






OS: Linux
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.17.10236 (Git)
Build type: Unknown
Branch: master
Hash: dd20ba3d068c4a0903417d93144f8ac7fed068e9
Python version: 2.7.13
Qt version: 4.8.7
Coin version: 3.1.3
OCC version: 6.8.0.oce-0.17
hattt
Posts: 2
Joined: Mon Aug 07, 2017 4:58 am

Re: Big rewrite of extrusion-based Arch objects and IFC export

Post by hattt »

HI,
I got problem with changing coordinates when export Arch Objects to IFC file.
In this first Figure, the z- coordinate of the selected point is at ~-613. However, after export this wall to IFC file and then reload the IFC file, the z-coordinate of the selected point is now set to 0.000. (As you can see in the marked red boxes)

Could anyone kindly tell me how to keep the same coordinates for geometry elements when exporting them to IFC file?
Thank you!
Cheers,
H
Attachments
211.png
211.png (104.96 KiB) Viewed 2697 times
21.png
21.png (108.25 KiB) Viewed 2697 times
User avatar
yorik
Founder
Posts: 13640
Joined: Tue Feb 17, 2009 9:16 pm
Location: Brussels
Contact:

Re: Big rewrite of extrusion-based Arch objects and IFC export

Post by yorik »

It is apparently a bug, but it's hard to tell what's wrong without seeing the file... Mind to share the fcstd file? (the one used to generate the ifc file).
hattt
Posts: 2
Joined: Mon Aug 07, 2017 4:58 am

Re: Big rewrite of extrusion-based Arch objects and IFC export

Post by hattt »

yorik wrote: Mon Aug 07, 2017 1:54 pm It is apparently a bug, but it's hard to tell what's wrong without seeing the file... Mind to share the fcstd file? (the one used to generate the ifc file).
Thanks for your response. I attached here the fcstd file for exporting the ifc file. Currently, I change the z position in Placement [Base] to get correct coordinates of objects in ifc model.
Attachments
_Wall.FCStd
(5.58 KiB) Downloaded 50 times
User avatar
yorik
Founder
Posts: 13640
Joined: Tue Feb 17, 2009 9:16 pm
Location: Brussels
Contact:

Re: Big rewrite of extrusion-based Arch objects and IFC export

Post by yorik »

Everything seems normal to me...
See the attached file, the base of the wall is at the coordinate given in #30, which seems correct.
Attachments
_Wall.ifc
(2.91 KiB) Downloaded 55 times
Post Reply