buildingSMART Forums

Where and how will my colors be saved in IFC?

IFC supports the use of image files (preferably png) for textures, see IfcImageTexture

I start from a question from @Moult which is so close to what Ms. @pilarjimenez is looking for, “Material Catalog” and mainly “Product Catalog” for COBie

A as oldskool AutoCAD user i see some similarities between “bylayer” “byblock” and “bymaterial”. Simple as that it might be.

I was hoping there is a way to control or change colors in a simple way. It should be made easy. You could use a user defined property “color” with a description.

@Hans_Lammerts - yes, it is similar to that :slight_smile: 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.

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

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

“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!

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 :frowning:

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. :slight_smile: A tru ‘pouring reinforced concrete’ discussion :slight_smile:

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.

screen|690x490

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.

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

1 Like

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

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.

image

Solibri opens and shows both colours without any issue - great job, Solibri!

image

In Revit, it also works as shown below…

image

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

image

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.

image

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:

image

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.