You can send to firstname.lastname@example.org
If you need to generate a DWG with color, the Geometry Gym Rhino IFC plugin has configured options to use different style inputs and Rhino3d can then save to DWG. We’ve been considering to develop an AutoCAD IFC importer for some time and hope we can do this soon.
Thank you. Lots of workarounds go around.
Not looking for one more.
@Hans_Lammerts, I have recieved your file. Your file is IFC2X3, but this diagram from the IFC4 documentation which describes how materials have colours still largely applies.
Your object, say
IfcReinforcingBar, has an
IfcMaterial assigned to it. An
IfcMaterial is purely a material name. By itself, it doesn’t contain complex information such as how it should look or what colour it should have. The example code below taken from your IFC file shows how a simple material called
S 500 is defined and how it is assigned to an
#162= IFCRELASSOCIATESMATERIAL('3jqclFXRX4suObPM94MO4I',#4,$,$,(#167), #163); #163= IFCMATERIAL('S 500'); #167= IFCREINFORCINGBAR('00kx2obfn9xPPzuYYnZ350',#4,'<Unnamed Element>', $,$,#108,#109,$,$,20.,0.503,$,.NOTDEFINED.,$);
As said, the material alone isn’t enough. You also need to define the “style” of a material. So, if you want to apply a colour to a 3D surface, you should have an
IfcSurfaceStyle defined. The code below, taken from your IFC file, describes a surface style used for rendering or shading purposes (as opposed to other purposes such as illumination simulations) of an RGB of
(1, 1, 0), or Yellow colour.
#142= IFCSURFACESTYLERENDERING(#143,$,$,$,$,$,$,$,.NOTDEFINED.); #143= IFCCOLOURRGB($,1.,1.,0.); #144= IFCSURFACESTYLE($,.BOTH.,(#142));
Again, as shown in the below diagram, defining the surface style is not enough. We now need to link the style to the material … and that surface style has to be assigned within a specific representation context (because IFC supports more than just a 3D representation, it also supports 2D representations, or other scale specific representations, or even diagrammatic representations).
Therefore, from the below diagram, we need definitions of an
IfcMaterialDefinitionRepresentation. However, only the
IfcStyledItem is defined in your file shown in the code snippet below. This suggests that the link between the style and the material is not defined properly in your IFC file.
#146= IFCPRESENTATIONSTYLEASSIGNMENT((#144)); #148= IFCSTYLEDITEM(#140,(#146),$);
That said, there are two different ways to map colours to an IFC file. So far, we have been following the “chain” on the left of the diagram. Your particular file takes a different approach, i.e. the chain on the right:
#148= IFCSTYLEDITEM(#140,(#146),$); #140= IFCMAPPEDITEM(#137,#151); #135= IFCSHAPEREPRESENTATION(#34,'Body','MappedRepresentation',(#140)); #109= IFCPRODUCTDEFINITIONSHAPE($,$,(#135)); #167= IFCREINFORCINGBAR('00kx2obfn9xPPzuYYnZ350',#4,'<Unnamed Element>', $,$,#108,#109,$,$,20.,0.503,$,.NOTDEFINED.,$);
As you can see, Allplan has chosen to assign the surface style to the shape itself (notice how
#167 matches the first code block I posted), rather than to the material. This is not my preference, but it is not incorrect. I also believe it is not your preference, since I see that you have carefully named your materials. It would be more efficient to define a small number of materials, one per size, each with its own style and be done with it.
My initial conclusion, but perhaps others might have an opinion, is that buildingSmart has defined two approaches towards assigning a basic colour, and Allplan took one approach. Other IFC viewers that can open your file might not support that approach, and that might explain why you are running into problems.
I should also note that there are some IFC viewers that simply do not visualise any coloured shading. This is not an error, as the raw data is still there, but it is simply the way they choose to visualise the object. One example of this is XBim. You can still check that the appropriate material data has been assigned, which I believe is the more important piece of data.
I would also highlight that it looks as though there are 428 material definitions and material assignment entities in your IFC file. I highly doubt that you have 428 distinct materials in your file as I see many with identical names. This shows that the Allplan exporter is highly inefficient with regards to materials and results in a bloated IFC file. There are other issues with the quality of your IFC file, such as the
<Unnamed Element> shown above rather than using
$, but if I continued with these descriptions, it would be off-topic. Please raise these issues with Allplan.
I hope this helps, and I hope the explanation was clear.
Thanks for your detailled analyses. I will inform a dutch reseller of Nemetschek software. Overall, i hope BSA manages to streamline input/output more with color testing to that this INFORMATION is passd though better in the future. Users should not need to know all this technical stuff in the first place
Do you know any IFC Viewer that can show textures? We are trying to introduce textures in IFC’s models by writting the txt format but we don’t know if we are doing well
Textures are mostly mapped witj pgn files.The FBX files stores them. I doubt you will find it for ifc.
IFC has some issues in texture.
I understand your considerations and what are you looking for?
I think soon we will see them, open-source.
IFC supports the use of image files (preferably png) for textures, see IfcImageTexture
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 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.
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.
“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
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?