Duplicate Points in extrusions of ifc files

[bernd]

This thread is due to a problem with importIFC and IfcOpenShell I have been faceing quite a few times now. If a Polyline of an extrusion in the ifc file has points which are near together the shape gets importat as invalid shape.

It would be interested to know if the problem is allready in the brep data string of OpenCascade (the problem would be ifcOpenShell related then) or if FreeCAD has problems to create the solids from the OpenCascade brep string.

I'm gone make another posts including the examples.

[bernd]

The first example has allready been disscussed. (viewtopic.php?f=23&t=7222&start=10#p65092)

What's the problem?
Points #93 and #95 are nearly identical. One needs to be removed and the file is imported fine.

Code: Select all

/*#81= IFCPOLYLINE((#83,#85,#87,#89,#91,#93,#95,#97,#83));*/
#81= IFCPOLYLINE((#83,#85,#87,#89,#91,#95,#97,#83));
...
/*#93= IFCCARTESIANPOINT((2.874999999916396,1.645261174599404));*/
#95= IFCCARTESIANPOINT((2.874999999916396,1.644797474203855));

How to reproduce the import problem with python.

Code: Select all

import ifc_wrapper
import Part
i=ifc_wrapper.open("/media/sf_vmaustausch/errorkoerper/invalid--shape--import1/invalid-shape.ifc")
ss=ifc_wrapper.create_shape(i.by_id(151))
ss
s=Part.Shape()
s.importBrepFromString(ss)
Part.show(s)

The compound is shown, but has errors. See Part --> check geometry
If in Draft a downgrade is made and all faces accept 004, 005, 006 are deaktivated the problem is visible.

[bernd]

Since i have had some of this duplicate point problems lately I have made an example myself to play a bit.

What's the problem?
Points #85 and #87 are nearly identical. In the entity point #87 it is easy to change the y-Value from E-6 to E-5 an the file gets imported.

Code: Select all

#85= IFCCARTESIANPOINT((7.,0.));
#87= IFCCARTESIANPOINT((7.,2.000000000000000E-6));

How to reproduce the import problem with python.

Code: Select all

import ifc_wrapper
import Part
i=ifc_wrapper.open("/media/sf_vmaustausch/errorkoerper/invalid--shape--import3/invalid-shape3.ifc")
ss=ifc_wrapper.create_shape(i.by_id(147))
ss
s=Part.Shape()
s.importBrepFromString(ss)
Part.show(s)

Important question would be again if the openCascade brep string data allready has the error faces?

EDIT:
tried if it has to do with the units. Attached the same file in mm, but same problem, invalid shape. If y-Value of entity #87 is changed from 0.002 Millimeter = 2.0E-6 Meter to 0.02 Millimeter = 2.0E-5 Meter the file gets imported properly.

[bernd]

Ahh forgot something:

OS: Ubuntu 14.04.1 LTS
Word size of OS: 32-bit
Word size of FreeCAD: 32-bit
Version: 0.15.4159 (Git)
Branch: master
Hash: fa3a2a0d3a7a0a619ab6323e236376bb43636e79
Python version: 2.7.6
Qt version: 4.8.6
Coin version: 4.0.0a
OCC version: 6.7.1


IfcOpenShell:
https://github.com/aothms/IfcOpenShell
branch master, commit 214 from July 30. 2014

[yorik]

Hi Bernd,

I think 95% of our problems with ifcopenshell are related to tolerance and precision. One main issue that needs to be solved in ifcopenshell is that it currently doesn't adapt to ifc units. Internally, everything is assumed to be meters, and the tolerance values are all hard-coded with meters in mind. And add to that the fact that opencascade can work with gaps, and produce shapes even if they are not correctly sewed (but of course that can cause problems later), and things become pretty hard to debug.

What I do here that often solves many tolerance-related problems, is to play a bit with the default tolerance values in ifcgeom/IfcGeomFunctions.cpp at line 449. You have there a series of default settings. Lowering or raising some values can solve many problems, especiually if you are working in millimeters (all the small values can be multiplied by 1000).

Ideally those values should be settable from outside of IfcOpenShell.. We should talk about that with TK one day