Component definitions in ifc files

[Odd_Haakon_Byberg]

so I ask chatgpt this:

“is components, the storage of identical elements as just instanses of the same geometry, a part of the ifc file format or will ifc inherently make all components stored as unique?”

and gpt says:

In the IFC (Industry Foundation Classes) file format, components can indeed be stored as instances of the same geometry, rather than as unique entities. This is achieved through the concept of “IfcProduct” and “IfcObjectDefinition” within the IFC schema.

In IFC, an IfcProduct represents any object within the building model, such as walls, doors, windows, etc. Each IfcProduct can have one or more representations, which describe its geometry. When multiple instances of the same geometry are used within the building model, they can be represented as instances of the same IfcProduct.

For example, if you have multiple identical doors in a building, you don’t need to define each door separately in the IFC file. Instead, you define one IfcProduct representing the door, and then you can create instances of that product wherever the door appears in the building.

This approach allows for efficient representation of building elements and promotes data consistency within the model. It also helps reduce file size by avoiding redundant geometry definitions.

So, to answer your question, yes, in the IFC file format, components can be stored as instances of the same geometry, rather than as unique entities, by utilizing IfcProduct instances effectively.

Anyone tried this? It it correct? How would you go about achieving this to export better ifc files?

[Odd_Haakon_Byberg]

So for a door element one would think that the ifc class of ifcDoor was the correct classification. I dont see a way to also class it as “IfcObjectDefinition” or “ifcProduct”

gpt says:
Yes, it is possible for an object in the IFC format to belong to multiple classes simultaneously. This is achieved through the use of inheritance and relationships defined in the IFC schema.

In the case you mentioned, a door could be represented both as an IfcDoor and as an IfcProduct. This is because IfcDoor is a subtype of IfcProduct in the IFC schema. In object-oriented programming terms, this is similar to a subclass inheriting properties and behaviors from a superclass.

[paddyclown]

Hi, as far as I know in Su components (or groups) can only have one ifcClass at a time…
But is that a problem as you can make a component of a door, classify it as ifcDoor and place many instances of the same door in you model…
Obviously you know this, so maybe I’ve not really understood what you’re trying to achieve, sorry.
Maybe @rtches can give you a good answer ?

[Odd_Haakon_Byberg]

thanks
This is my understanding as well, that sketchup only gives the option of one class.

If I make an ifc of my own project, and import that ifc into sketchup again, then all instances of a component are made unique, which ballons the file size and make the file less useable.

Not that I need to import ifc of my own work, but this happens for others that get my ifc, and for ifc´s that I receive as well.

I dont know If what chatgpt says is true, about the double classifications that would make components possible.

[paddyclown]

Hmm, good question. From the ifc files that we’ve had from others coming from Revit or Archicad I don’t remember seeing any double classifications !
I guess you could classify differently from one schema to another - ifc2x3 & ifc4, but since one would only ever export one or the other of these two, it’s wouldn’t be very useful !
I don’t know if anyone from BuildingSmart is on here & could tell us ?
Basically it’s another mystery to add to the already quite long list of BIM related issues that need addressing by the Dev team.
I have more confidence than I used to that they are genuinely going to try & fix at least the basics, but in what timeframe, I have no idea, and that’s the worry. I don’t know about where you are, but here in France, BIM is starting to really become unavoidable even for medium sized projects, so we need better BIM from SU sooner than later !

[rtches]

An IfcDoor inherit properties from IfcProduct.
There are no two classifications, it simply inherits from the parent one. See the image

Attributes from 1 to 8 are inherited…

[Odd_Haakon_Byberg]

but how would one practically go about defining the door component so that this works?
is it nested components where the ifc door component is inside a ifcProduct component as the hierarchy in the table says?

[rtches]

You only need to classify a component as a Ifcdoor.
With Ifc manager you will have all attributes needed. However with Sketchup you will not have them by default.

[paddyclown]

Thanks @rtches I knew you’d know !

[MikeWayzovski]

While it is possible to assign more than one classification tag to a SketchUp Component inside SketchUp, it is restricted to one type per classification (.skc) only.

It requires to load the appropriate Classification file in the model via Model Info > Classifications.

From the +600 main types in IFC and +11.000 subtypes, SketchUp’s importer (and exporter) maps to the 27 main predefined types (IFCBeam,IFCWall, etc)

According to the KISS-principle:)

Not sure if it would be possible to have the same import mapping from Revit, where it is easier to map instances of the same family type to instances of one SketchUp Component definition.

The authoring tool where the ifc is created must map the instances from the same ‘Family’ to IfcRelDefinesByType, then define the localplacement (and rotation).
Revit does it, don’t know about Archicad.

Then, it should be possible to map multiple instances to the component definition upon import.

The second (or first?) thing to do is map the export as well this way which would require to add more data to the components.

[Odd_Haakon_Byberg]

@MikeWayzovski

Then, it should be possible to map multiple instances to the component definition upon import.

I have never been able to import with component instances intact, but as I understand it, what you are saying is that components instances is possible, but that the sketchup importer does not do it.

Ifc Manager uses the native importer and then does not do it either.

Converting ifc to TrimBim and importing that does not help, which is strange. It could be that TrimBim does not support instances, that would be #&%!, or it could be that the TrimBim importer in sketchup does not do it.

[Anssi]

What applications are you using to create the IFC files you import? I have exported from Revit and Archicad, and both export all objects as unique, including identical doors and windows, with insertion points at the project origin.

[Odd_Haakon_Byberg]

@Anssi

What applications are you using to create the IFC files you import

I only import ifc´s that other people make, in Trimble Tekla (steel engineers software), Revit and Archicad.

I have the same experience as you. Only unique components, also when importing through TrimBim.

But according to MikeWayzovski, in this thread (as I understand it ) it should be possible if the importers supported it.

[Odd_Haakon_Byberg]

In this example someone else distributed the collected ifc from all work group members to a file of 4mB, and the next time I was asked to do it, resulting in 55mB

The text " ble litt stor fil " is me apologising to the group.

[paddyclown]

I just did a test, exporting an ifc using ifc manager from su2023 & then reimporting it to a blank file &…
Yes, it appears that SU imports the ifc & populates the “instance” field with the same value for two identical components, but then populates the “definition” field with a unique ID for each.

This seems like another issue to discuss with the dev team working on ifc handling at Trimble…

[rtches]

I think it is correct that each entity is unique in an IFC file, both when importing and exporting. You have to take into account that each object receives a unique identifier that has to distinguish it from the rest. Other modelers or viewers do not know what a SketchUp component is.

SketchUp in fact generates a unique identifier for each object even if we see that there are n equal units in the model.

An example could be a car, as soon as it leaves the factory it is unique, it has an identifier that distinguishes it from the same cars of the same manufacturer and the same model.

I would not worry about them being unique, if you want to see how many units are the same you can make filters by name or by any of its attributes in any Ifc specific software. (Trimble Connect, BimCollab, Bim Vision, etc.)

SketchUp must respect the information that is imported and exported so that it can be seen in other modelers, that is what you should pay attention to.

[Odd_Haakon_Byberg]

@rtches

I think it is correct that each entity is unique in an IFC file

well I dont agree with this. Sure, in sketchup, you can give each instance of a component an instance name that is unique. That does not mean the component definition is broken.
Most CAD/BIM software has their own version of components, like “blocks” in autocad.

If the ifc file actually contains information about identical geometry identified as such in the ifc file, then not importing this is not to respect the information given to you, it is rather the opposite.

When the Toyota Corolla leaves the factory it gets a individual unique number, but it is still a Corolla and not a Ford.

[paddyclown]

Even if I’m a vintage car lover I’m not going to add to that thread of ideas as I’ve never seen two cars “identical”
But what I suspect is happening is that in fact Su is swapping Definition for Instance, no ?
As in, the Definition should stay identical, and Instance should be the Unique ID that @rtches mentions, which is indeed common to all modelling software and the ifc Schema. What we are seeing is that the inverse is being generated from SU, either on import or export, but I suspect import only since it sounds as if that happens from all sources of ifc, Su or other (Archicad, Revit, Tekla etc…)…

[rtches]

@Odd_Haakon_Byberg

When the Toyota Corolla leaves the factory it gets a individual unique number, but it is still a Corolla and not a Ford.

I agree, When you import a Window is still an IfcWindow and not an IfcDoor, its name is the same as the moment it was created and their info is the same as other identical window but it has its unique identifier.

[paddyclown]

Exactly, but it would appear that the fields are being populated inversely to how one would expect !
As I understand English, a Definition defines, and an Instance can be an alpha-numerical identifier like the VIN number of the cars @rtches is talking about
The trouble is, these two fields are getting swapped on import, no ?