Still not rendering IfcTriangulatedFaceSet

[guenter1holzeder]

A sample wall with IfcTriangulatedFaceSet is not rendered as a shape.
But it can be converted to a XbimSolid via XbimGeometryEngine and XbimShellset correctly.

I played with several constellations develope/master but with no positive result.

IfcTriangulatedFaceSet.zip

[andyward]

Is it related to #145? There was a recent PR #151 that got merged. Have you got the very latest?

[guenter1holzeder]

I used both 5.0.163 (Master) and 5.0.169-develop

[andyward]

Thanks. 169 includes that PR, so looks like this is a bug.

[bekraft]

The main reason here is, that the implementation ignores the "PnIndex" attribute. It maps between the local index and the provided index of the IfcCartesianPointList3D given by "Coordinates". There's an argument-out-of range exception on the log

==== 13:53	5	Error
Xbim.ModelGeometry.Scene.Xbim3DModelContext
GeomScene: #48="IfcTriangulatedFaceSet" ["Failed to create shape geometry, Der Index lag außerhalb des Bereichs. Er darf nicht negativ und kleiner als die Sammlung sein.
Parametername: index"]

But somehow the given IFC model does not correspond to the latest IFC4 spec. It roughly says, that the given 2D list of normals should have the same length as the provided coordinate indices. It seems that the model exporter has written less normals than coordinates (6 vs. 8). "PnIndex" refers also to one of 6 indexes. So my guess is, that the exporter's "PnIndex" refers to the normals and maps it onto the vertices - which is indeed not the meaning of the IFC4 spec (see IfcTriangulatedFaceSet). Am I wrong? On the other hand, the way it has been exported makes more sense to me ...

[SteveLockley]

Guenter, I am not sure where the issue starts here, it looks like you have used xbim extract to strip some objects out. Do you have the original file so we can start from base zero?

[SteveLockley]

This is really odd, as Bekraft points out the PnIndex should be a L[1:?] of integers but your file has a L[1:?] L[3:3] of integers

I would have thought this just plain wrong except one of the samples on the IFC schema site does a similar thing http://www.buildingsmart-tech.org/ifc/IFC4/Add2/html/ . We build our code from the express schema and that says it should be a list of integers.
To compound things we are not even processing PnIndex in the geometry engine, other than when parsing. This is becasue it did not exist until Addendum 2 (they snook it in)
I think the best thing is that we assume the sample file above is wrong and the schema is correct. If you can fix your IFC file to comply with the schema, i.e. List of Integers that point to the the coordinate index to be used. Then we need to implement it :-)

[guenter1holzeder]

From a practical view I must say - other IFC viewers seem to have no problem with this. When you are in a B2B situation, no modification on IFC files can be done (by the end user). So it's sink or swim for them.

I think the question is, how tolerant an application should be on schema variances?

[SteveLockley]

I understand and am not trying to be fascist with this in anyway. We are in fact ignoring this data, which is most likely what other tools are doing as this was not in add1.
Wasn't sure if you were the author of the file, but I guess it is graphisoft. I will have a chat with the guys who deal with parsing and see if we can swallow some of these complaints and take a softer approach

[guenter1holzeder]

In our business we're getting only final models from different producers (CADs). If we get a dickey IFC file we have to deal with it :-)

[bekraft]

I've tried also to find some other examples. But even the IFC spec doesn't provide some for this special case. Also the figures of spec page itself are somehow inconsistent. So figure 347 refers to Add1 whilst figure 348 refers to Add2. Don't know how to handle this ... Taking to graphisoft or others might be the best (since their exporters should be certified against whatever ;-)

[SteveLockley]

Had a good look and I think the PnIndex is fundamentally defined incorrectly in the IFC standard. I think the PnIndex should be the indices of the normals not the x,y,z coordinates as described in the Ifc Docs. I will make this assumption and amend the code and inform BuildingSmart. That said the Graphisoft output is not in accordance with the schema either, one or the other will need to be fixed, but xBIM will handle the current output and the correct output.

[guenter1holzeder]

Well done