Mesh-type IFC-objects limited to about 23 000 faces?


We work with fairly big meshes in Rhino/Grasshopper and have noticed that on some meshes the IFC-object is missing faces. It seems that there is a limit of about 23 000 faces? Where does this limit come from, is it intentional from you, limit of IFC-standard itself or a bug?

We have tried creating the IFC-objects with components FaceBasedSurfaceModel, TessellatedFaceSet and ShellBasedSurfaceModel which all create the same result. What are the differences of these components anyway, is the geometry always the same but the IFC type different?

We are using Rhino 7 and ggRhinoIFC version from Package Manager, but the problem exists with earlier versions of ggRhinoIFC too.


There’s no constraint in size imposed by the plugin or toolkit. If you’re hitting problems, it’s relative to your computer spec, operating system etc.

If you can use IFC4 Reference view with IfcTessellated FaceSet, you might enable larger meshes as the serialization is more efficient than faceted shape representations in IFC2x3.

Is there any way of reducing the faces? If it has co-planar faces then the conversion can use ngon faces to reduce the serialization. There is interesting routines by McNeel with TriRemesh and QuadRemesh and I’ve considered enabling this in our tools but automatic control seems difficult to get reliable and acceptable results.

Let me know questions or suggestions.



Reducing the faces / simplifying the mesh is usually done to some extent always. Like you suggested, I tried using IFC4 and the TessellatedFaceSet component, which works very well now. I was able to create an IFC of a mesh with over 100 000 faces. The component also runs much faster than while using IFC2x3 (about 17ms vs 4.1s in this one case).

I think we will be using IFC4 from now on if there is not a requirement from our clients to use IFC2x3. We will still aim to simplify the meshes, but of course we must have “enough” accuracy left in the final model. One other option would be to divide the meshes to smaller pieces, but we would rather not do that.

Thanks Jon!