Geometry gym export ifc using usertext data as ifcProperties

Hi @jonm I have a bunch of rhino meshes with user text associated to them (well, to the ObjectAttributes.UserText ) as key-value properties and I need to create an ifc with properties from here…

What would be the easiest way to use this data to create an IFC using GeometryGym? How can I convert usertText key-value data to ifc properties of ifcElements using GeometryGym?


Hi Aitor,

You can use the RhinoIFCLayer functionality to do this. The below provides some guidance on how to set it up.

By default, the user text properties will be exported as a simple value. Although it’s better to configure the export with a property template in rhino to get a higher quality ifc file (than just a number) as some properties might be areas, lengths etc. The above link also provides guidance on how to do this as well under the under Assigning a property set to specific IFC classes heading.

The other option is to use grasshopper to assign the properties how you want. This may be the best option if you are familiar with Grasshopper.

Let us know if you have any issues.


1 Like

Hi @jonm , @NathanGG , I thought geometryGym is capable of creating IFC files with properties using Rhino interface.
I already have geometry in rhino with their corresponding properties, but once exported none of the properties are exported (they dont appear even in the txt file)

I usually use GH for generating IFC but this time, for some reason, its generating garbage geometry (missing geometry, et al)
exported from Rhino geometry is perfect and so I am.

Why it’s not exporting the properties? Am I missing something?

Hi @jonm , @NathanGG, other question: why GH get soooooooo slow when working with GeometryGym? Can I do something to avoid geometry gym component working on the background even when they are “disabled”? I have quite a decent experience in GH/Rhinocommon, but geometrygym processing behaviour in relation to GH remains a mistery difficult to distangle to me.

working with a geometry about 100.000 vertices, its big, but not that big… two meshes circa 50.000 vertex each, 10 properties each. No more.

Hi Aitor,

Sorry you are experiencing issues. Have you updated to the latest builds using package manager?
I’m not aware of any other users reporting an adverse performance in Grasshopper (we have worked pretty hard to achieve as high performance as possible). Maybe it’s something unique to your script or model? Is the model remote from origin? This will certainly slow down lots of geometry calculations and it’s better to work in local coordinates and set georeferenced coordinates in the resulting export. This isn’t always ideal as there is no basepoint concept in Rhino and if you’re referencing CAD or other other models, you might need to apply a transform.

If you can share (privately is fine) any sample script of model that demonstrates the issues, we will trace the code and look for improvements. If this isn’t possible, we will have to consider some sort of diagnostic build.



One more misterious behaviour in gh/gg is that I noticed that the “apparently” the same ifc file get bigger and bigger each time i saved. By casualty I noticed, by casualty, that when selecting components of ifcEntities of interest in the export and saving by right clicking and using “save selected components” ifc remains thin and consistent in size on each save

Some more thoughts. A likely reason for slowdown, is likely if you are trying to preview the geometry (and products) in grasshopper from the IFC. The process to convert a large mesh to ifc and then convert it back to a rhinocommon mesh (or worse brep) does take time (especially when geometry is remote). It’s better to disable IFC component preview.

The file size increasing is strange. The file is written anew each bake (not revised). So it suggests either more data/objects are being added. There might be a small increase if tracking “obsolete” objects (which is really only recognized by our revit ifc importer). Refer attached image, try also disabling this. Perhaps an online meeting will help if we can’t resolve with shared files.

My intuition was telling me that some how geometry gym is stacking in memory ifc entities, so as work progress and changes are made to the properties/geometries ifc entities are added and addeD (taking memory space/process time) instead of replacing the old ones. And so, my intution is telling that when for some unknown implementation reason, when using “bake ifc” component, output files gets bigger and bigger. Just a theory of an actual fact : )

It’s possible something isn’t expiring correctly as the script recalculates. One test of this would be to save the script, close it, open and bake and see if the file size reduces back. This forces a fresh ifc dataset with no chance of retention.