Autodesk
ENH: ObjectType export value
Enhancement Description
ObjectType parameter in IFC Schema should only be used if the Predefined Type is set to "USERDEFINED" to define this custom type.
Right now Revit automatically populates ObjectType attribute in IFC with "Family and Type" parameter value resulting in noncompliant and confusing outputs and also duplicating information from default Name export.
As to comply with the schema principles and not to duplicate values it would be great to have possibility to allow export of <Empty> value of ObjectType if shared parameter "IfcObjectType" is not filled in.
Our goal is to have elements with empty value in ObjectType if predefined type is already defined by built-in parameters.
Situation now: No shared parameter loaded in Revit → ObjectType = FamilyName:TypeName Shared parameter "IfcObjectType" loaded and empty → ObjectType = FamilyName:TypeName Shared parameter "IfcObjectType" loaded and "CUSTOM_TYPE" value → ObjectType = "CUSTOM_TYPE"
Yet there is no way right now to export this without any value.
Expected bevahior: No shared parameter loaded in Revit → ObjectType = <Empty> Shared parameter "IfcObjectType" loaded and empty → ObjectType = <Empty> Shared parameter "IfcObjectType" loaded and "CUSTOM_TYPE" value → ObjectType = "CUSTOM_TYPE"
Is it possible to either add checkbox not to fill this parameter, or just don´t do it by default at all as it is completely useless and confusing right now?
Thanks!
Revit Version
2026.0.x
IFC for Revit Addon Version
26.1.0
Windows Version
11 24H2
I have similar thoughts about the Reference property in multiple Psets. There is no way to disable filling it with FamilyName:TypeName.
Hello @MisunMartin,
Thank you for reporting this issue. We have reviewed and tested the case in Revit 2026 using the latest IFC Exporter 2026.1.0.23, but we were unable to reproduce the problem on our side.
Similar issues related to the ObjectType export logic were recently addressed in previous updates. Could you please confirm whether you can still reproduce this behavior in your current environment? If the issue persists, we would appreciate it if you could share a sample RVT file along with detailed steps to reproduce — this would help us investigate further and identify the root cause more efficiently.
Since the problem cannot be reproduced with the current version, this ticket will be closed for now. If you continue to experience the same behavior, please feel free to reopen the issue and provide the requested details for additional review.
Testing environment:
- Autodesk Revit 2026 (IFC 26.1.0.23)
Hello,
strange as I have tried once again and it is still the same behavior.
Created 3 categories:
Wall - no parameter
Floor - Empty IfcObjectType
Roof - Filled-in IfcObjectType
Export results:
Wall - Basic Wall:Wall 1
Floor - Floor:Floor 1
Roof - CUSTOM_MARTIN
Even used Solibri Viewer, that is creating its own attributes in some cases. The safest way is to check it directly within .txt file or Bonsai for example.
Exporter version:
Revit version:
Nevertheless as the problem still persists I will reopen this topic providing RVT Source File and exports in IFC 2x3 // IFC 4x0 RV // IFC 4x3 ObjectType.zip
Hello @MisunMartin,
Thank you very much for the rapid response and the detailed, clear reproduction steps, screenshots, and the sample ZIP file.
Clarification on Investigation: You are absolutely correct that the behavior still persists in your environment. My sincere apologies for the confusion caused by my initial response.
Upon internal re-review, I confirmed that my preliminary test was inadvertently performed using an internal development build of the exporter (a version later than your public 26.1.0.23). In that upcoming build, this specific enhancement (preventing the automatic population of ObjectType when it should be empty) has already been addressed.
Your testing confirms that the issue is still valid and reproducible in the current public exporter version.
The fix for this behavior will be included in a future public update to the Revit IFC Exporter.
We truly appreciate you taking the time to provide such precise verification, which has allowed us to accelerate the triage process.
Tested with just released v26.4.0.0
Working perfectly!
Thank you for this fix!