I am interested in this too. I am structural engineer too and misse lots of ifc classes and attributes for all kind of objects we put inside the concrete 
We coul start a disscussion about this in a separate topic specially dedicated to the rebar attributes. Heappily a class for them exists already.
Yes that would be a good idea. 
A tru ‘pouring reinforced concrete’ discussion
I tested the 2017 ifc2x3 (old Allplan) model but it shows no color as expected.
Indicated that it the color is either improved on the Allplan export side or IFC 4 fileformat…
May be it is the software you use to display the ifc. It seams lot of BIMtools and BIMCloudplattforms are not used by Allplanusers which usre reinforcements. Most of the time I start with a new plattform and try an Allplan ifc with reinforcement I sent them the ifc because the plattform or viewer does not support the Allplan reinforcement colors … !
Reinforcement exported to IFC2x3 in Allplan 2018.1 with new exporter.
BTW, how do you get inline pics?
Hans, can you send me a test file so that I can make sure your colours come through in BlenderBIM?
IFC coloring should be an certified aspect!! It can be important. To make a bold statement here: it’s not good enough ‘fixed down’ Make it like DXF , DWG behaviour. Or some other mechanism. why not??
I just upload images using it rhe button above the textbox bernd. Cheers.
It might be certified but Allplan, as well as ArchiCAD as well as VectorWorks (I have not tested others) do write the color into the object AND into the material of the object. But these programm write different colors for the object and for the materials. For sure for Allplan the problem is NOT between stair and keyboard. If have found the problem and the ifc management knows the problem. I can not speak for others since I do not use ArchiCAD and VektorWorks but I recive IFC with this problem on a weekly basis and from different Architects.
cheers bernd
@jwouellette I have a similar experience as @bernd and @Hans_Lammerts. I also receive IFCs on a weekly basis with these issues. Allow me to give one example. Here is the source scene, exported from BlenderBIM - two IfcWall objects - one red, one green. The red is assigned the surface colour directly to the object’s representation via styled item, and the green is assigned via IfcMaterial with IfcMaterialDefinitionRepresentation.
Solibri opens and shows both colours without any issue - great job, Solibri!
In Revit, it also works as shown below…
… but, it only works in Revit with a few considerations. And it is these considerations which, I believe, result in a poor user experience.
Here is one scenario of the exact same file except that the geometry is an IfcFacetedBrep, instead of an IfcExtrudedAreaSolid. You can see that the green colour no longer shows. This is the most common reason, I find, for colours not showing. Logically, shape representation should not affect colour display. In this case, I believe it affects it because of the way Revit tries to parse an IfcWall, but since Revit is a black box, I cannot say for sure.
The additional quirk is that the red cube actually creates a new material in Revit called “red”, even though there is no such IfcMaterial('red' ... in the source IFC file. This misleads people into thinking that materials are being imported or exported, where in fact, Revit is actually reading the Name attribute of the IfcSurfaceStyle entity, and seems to completely ignore the Name attribute of the IfcMaterial entity, which, you’d hope, is where it actually picks up materials from.
Given that Revit is certified, I find it strange that these issues exist.
A third quirk is that the IfcStyledItem has this little deprecation notice:
NOTE Only the select item IfcPresentationStyle shall be used from IFC4 onwards, the IfcPresentationStyleAssignment has been deprecated.
This means that for IFC4 files (yes, I know, in theory Revit is not yet certified for IFC4 import), since Revit only supports IfcPresentationStyleAssignment, colours will not show up. Because Revit isn’t certified for this, we can’t exactly fault them, but it certainly causes users problems nonetheless. Even worse, it gives people a bad impression of IFC as a file format they can’t trust.
This short case study into Revit (2019 - maybe fixed in 2020?) is just one example you can see that XBim displays the file like this - it ignores the green material, but applies the red object style. There are quite a few other vendors that also have this issue.
Excellent observation and writing.
Hi @Moult - also thanks for your report. A few general remarks:
yes, in IFC you can color elements either by the material (via IfcMaterialDefinitionRepresentation), or by the color assiged to the geometry (via IfcShapeRepresentation). If both are provided for the same element, the color provided by the geometry takes presedence.
see also here.
The assignment of the color in both cases is agnostic to the type of geometry (extrusion, brep, etc.). So if a software, like Revit or XBIM, shows color differently by geometry type, then this is an import bug.
regarding the deprecation note: in IFC4 we streamlined the way to attach styled items (compared with the way in IFC2x3, which was taken from STEP). So it is not a change in functionality, but only a way to reduce the number of instances you need.
Thanks @TLiebich
Correct, both can be provided, and geometry takes precedence - but because programs like Revit only listen to the shape representation, and ignore the material, I have created workarounds in BlenderBIM to allow people to automatically export materials as both assigned to material and the geometry:
Correct - the assignment of colour should be agnostic to shape, which is why I highlighted the strange behaviour in Revit above. I think this is Revit specific, other programs seem to correctly be shape agnostic.
Agreed that the deprecation note allows IFC4 to be streamlined. It is a very good change! I merely observed that Revit does not parse this “streamlined” assignment, resulting in no colours showing up. No fault to buildingSmart, since they are not certified yet, but annoying for users nonetheless.
Thank you @TLiebich… We must have been writing at the same time.
Now for my typically more verbose answer…
For IFC2x3 CV2.0, both/either condition were allowed, for greatest flexibility. If both were present, then the color of the geometry has priority over the color of material. Reason? The emphasis on IFC2x3 Coordination View 2.0 is on design coordination between disciplines, where color-coding of domain elements and systems was a higher priority over visual rendering of materials. It was also assumed that a receiving application, whether a modeler or viewer, would allow the user some type of control over which option to use if both were present, if the application was able to handle both. The PDF certification documentation for each application should be clear about what is supported and what isn’t.
For IFC4 RV1.2, only color of geometry is acceptable. Again, the priority of the Reference View 1.2 is on providing model information at a basic level, primarily for design coordination, but also other workflows where referencing of the source model data is prioritized over transfer and translation of source model data to the receiving application’s native objects. It is a stricter requirement that negates flexibility over predictability, which seems to be the concern here.
There are some well-known and widely used applications that struggle with color support. They may not have the level of flexibility that IFC allows and other applications may have. In IFC2x3 certification, we tried to find the best compromise to allow certification of many apps, within pragmatic reason. For IFC4, we have tried to be stricter, but some apps face a significant challenge.
I think it behooves the end users to address these requirements clearly to their respective vendors. As buildingSMART moves forward with new initiatives to improve IFC (making it more comprehensive, but also clearer, more strict, more efficient, etc.) there will always be challenges for the vendors/developers to overcome. buildingSMART can’t force those vendors, but end users can have a greater say and significant sway over their efforts and results.
So, there are some concerns that can be addressed here by bSI support groups, but there may be some cases where the answer is “go talk to your vendor about fixing it”. That may not be a satisfying answer to some, but that may be the most pragmatic means of solving some issues. In the meantime, we are trying to engage more proactively with the vendors/developers to get better results, but this does take time, manual effort, and debate… as well as a great deal of patience.
Thank you @jwouellette.
I will like to summarise the following non-compliant issues with Revit, so that I can keep it on the public record for others who come across similar issues, and we can communicate with Autodesk representatives at our end here and use this thread as a reference to help resolve this.
To add to the story. I converted some typical Allplan model (IFC export) to STEP (using BricsCAD DWG) for use in Inventor. We need to have colored rebar available on object level in Inventor (no need for the ‘why this software?’)
Apparently step keeps the colors alive which is great.
Hi Dion,
Please check these too, in both Revit and BlenderBIM:
Covering: IfcCovering
Finish: IfcSurfaceFeature
Material: IfcMaterialResource, IfcMaterialSelect
I think Revit has a specific way of managing these together which is poor
Just a heads up, since it was on my todo list for a while, that I’ve just (re-)implemented support (it used to exist, but I did a rewrite) for BlenderBIM importing object-level surface styles.
BlenderBIM’s import also distinguishes between an import of object-level and material-level surface styles. To my knowledge, this is the only BIM program which does this. So later on when you click on the object to see its colour properties, you can see whether it was assigned via material or assigned via object.
@Hans_Lammerts - see a screenshot of a portion of your model you sent me below, with colours!
I will mention that this Allplan IFC file seems to have a lot of identical colour and surface definitions for the exact same colours. Blender can handle this, but it results in a bloated and inefficient IFC file, and unless Blender compensates, it means that the import takes longer and creates more data. If Allplan doesn’t fix this, a workaround is to run the IFC through an IFC optimiser. I think Solibri has one in their product portfolio.
Looks good Moult! I hope all the software developers in construction will apply the same color rules for reading and understanding rebar in 3D. It’s getting better but there should be much more feedback generated from construction sites outside… good work!
@Hans_Lammerts I think your best hope for getting software vendors to implement a system of diameter-based colors for rebar is first to get consensus among users (especially at the international level) on such a workflow. If this can be agree upon and documented in standards (NBIMS-US, CEN, BSI, etc.), then you are more likely to see vendors support it. To me another key question for implementation and standardization would be “What color scheme is used?”. Again, is you can get a large consensus and documentation, vendors have something concrete to work from. Otherwise it becomes more difficult to implement in software.
