Where and how will my colors be saved in IFC?

[Moult]

@Hans_Lammerts - yes, it is similar to that By the way, BlenderBIM now allows you to pick whether objects are assigned surface styles by object or by material. As far as I am aware, it is the only BIM program which allows you to do this.

@pilarjimenez - sorry, I don’t know of any that supports textures. It is on my to-do list. However, it is possible in BlenderBIM to assign externally defined material files - I have used this to associate external material definitions which have textures as well as complex material setups. Like the ability to assign surface colours by object or by material, BlenderBIM is the only BIM authoring tool that I know is capable of doing this.

[Hans_Lammerts]

Newer version of Allplan IFC and import BricsCAD conforms better color handling. Good! One one crucial part is missing. The diameter of rebar on elements. This is on BricsCAD interface side i think @Moult

[bernd]

Diameter of a rebar:
FreeCAD (should) and Allplan (for sure does) do export the rebars as IfcSweptDiskSolid. Thus the diameter is not a property inside a property set but a geometry information of the shape. Solibri does show this information, CollabZoom not (support is aware of the problem). I do not know about BricsCAD.

Colors:
AFAIK there are two possibilities to give a color to a object:

• directly to the shape
• to the material assigned to the object

Allplan for sure has a bug and writes for one object different colors in the material and in the shape. This is easy repeatable. The ifc development management knows about the problem. If they are going to fix it, who knows.
FreeCAD does shown a log message on import of such case. Since I implemented this I have seen more file from other CAD vendors too which shows the same problem. Different colors for material and shape.

BTW: Allplan has ever written an own material for each object. Thus in FreeCAD ifc importer it is possible to merge materials with the same name and color (If not one would end up with thousands of materials). Allplan is aware of this, but AFAIK they are not going to change this behaviour.

cheers bernd

[Hans_Lammerts]

“Diameter of a rebar:
FreeCAD (should) and Allplan (for sure does) do export the rebars as IfcSweptDiskSolid”

I think you understand my initial reply and need for information. We need to have a displayed property in the rebar. I am not an ifc expert but i think the name is Property Set right? Crucial data should be available to a set (array) of same objects (rebar) and on the object itself. Because during further modelling and modeluse the array (block in dwg) should be able to be exploded.

So from a ‘bim’ perspective the same information should be attached on more the one objects. Two sets of objects. The array (batchnumber, amount and diameters,etc etc) but also one level deeper as single rebar. I don’t see this in any bim ‘authoring’ software yest. I am not surprised this is same in ifc import in bricscad. I would think this shortcoming is in the way ifc works on export and import, not on BricsCAD side. They are doing a really great job working on ifc in DWG ! Geometry is very very good in V20. Best i have seen sofar!

[bernd]

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.

[Hans_Lammerts]

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…

[bernd]

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.

screen|690x490

[bernd]

BTW, how do you get inline pics?

[Moult]

Hans, can you send me a test file so that I can make sure your colours come through in BlenderBIM?

[Hans_Lammerts]

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.

[bernd]

fine simple examples here … https://forum.freecadweb.org/viewtopic.php?f=39&t=40935

[jwouellette]

@Hans_Lammerts. It is a certified aspect under both the IFC2x3 CV2.0 and IFC4 RV1.2 suites.

[bernd]

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

[Moult]

@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.

[Hans_Lammerts]

Excellent observation and writing.

[TLiebich]

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.

[Moult]

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.

[jwouellette]

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.

[Moult]

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.

1. Colour representation should be agnostic to the geometric representation as confirmed by @TLiebich, whereas the demo file above demonstrates otherwise
2. Revit imports surface style names into the “Materials” field, misleading users about whether material data is stored in IFC. This is not theoretically wrong, but it is misleading, and a separate interface would be appreciated (which Revit already has, so this could be an easy fix) To clarify, this is not to do with geometry styles overriding material styles, this is about the UI misleading users to think that material data is being stored properly.
3. The streamlined style assignment approach in IFC4 should be supported as part of the IFC4 certification roadmap. It is at Autodesk’s discretion to provide a timeline, but currently a lot of IFC4 users are inconvenienced.

[Hans_Lammerts]

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.