Why is it so difficult to get colors to show up?

I’m attempting to use IFCStyledItem to show both color and transparency. Colors work in Solibri, but not transparency. In ArchiCAD, both colors and transparency don’t work.

I’ve tried an approached suggested by @jonm of mapping a styled item to an IfcMaterialDefinitionRepresention. That didn’t work, and in fact caused colors to stop showing up in Solibri.

There is no reason this should be so difficult. I’ve provided a cut down IFC that just creates polygonal mass as an IfcBuildingElementProxy

Finally, please don’t recommend that I change the MVD of the file. None of the IFC test applications that I have seem to care about what MVD is being used. In fact, I’ve got an AllPlan test file linked from another thread that simply puts ‘no view’ there and colors work just fine.

Here’s the shape in ArchiCAD (no color and no transparency):

Here’s the shape in Solibri (color, but no transparency):

Here’s the file:

    ISO-10303-21;
    HEADER;
    FILE_DESCRIPTION(
    	('ViewDefinition [DesignTransferView_V1.0]'),
    	'2;1');
    FILE_NAME(
        'models/Elements_Mass.ifc',
        '2020-01-24T18:01:39',
        ('ikeough'),
        ('Elements'),
        'IFC-dotnet',
        '0.1.4.0',
    	'None');
    FILE_SCHEMA (('IFC4'));
    ENDSEC;
    DATA;
    #1 = IFCORGANIZATION($, 'IFC-dotnet', $, $, $);
    #2 = IFCAPPLICATION(#1, '0.1.4.0', 'IFC-dotnet', 'IFC-dotnet');
    #3 = IFCPOSTALADDRESS(.OFFICE., $, $, $, $, $, $, $, $, $);
    #4 = IFCACTORROLE(.ARCHITECT., $, $);
    #5 = IFCPERSON('ikeough', $, $, $, $, $, (#4), $);
    #6 = IFCORGANIZATION('Elements', 'Elements', $, $, (#3));
    #7 = IFCPERSONANDORGANIZATION(#5, #6, $);
    #8 = IFCOWNERHISTORY(#7, #2, $, $, $, $, $, 1579918359);
    #9 = IFCSIUNIT(*, .LENGTHUNIT., $, .METRE.);
    #10 = IFCSIUNIT(*, .AREAUNIT., $, .SQUARE_METRE.);
    #11 = IFCSIUNIT(*, .VOLUMEUNIT., $, .CUBIC_METRE.);
    #12 = IFCSIUNIT(*, .SOLIDANGLEUNIT., $, .STERADIAN.);
    #13 = IFCSIUNIT(*, .MASSUNIT., $, .GRAM.);
    #14 = IFCSIUNIT(*, .TIMEUNIT., $, .SECOND.);
    #15 = IFCSIUNIT(*, .THERMODYNAMICTEMPERATUREUNIT., $, .DEGREE_CELSIUS.);
    #16 = IFCSIUNIT(*, .LUMINOUSINTENSITYUNIT., $, .LUMEN.);
    #17 = IFCSIUNIT(*, .PLANEANGLEUNIT., $, .RADIAN.);
    #18 = IFCMEASUREWITHUNIT(IFCPLANEANGLEMEASURE(0.017450), #17);
    #19 = IFCDIMENSIONALEXPONENTS(0, 0, 0, 0, 0, 0, 0);
    #20 = IFCCONVERSIONBASEDUNIT(#19, .PLANEANGLEUNIT., 'DEGREE', #18);
    #21 = IFCUNITASSIGNMENT((#9, #10, #11, #12, #13, #14, #15, #16, #17, #20));
    #22 = IFCCARTESIANPOINT((0.0, 0.0, 0.0));
    #23 = IFCDIRECTION((0.0, 0.0, 1.0));
    #24 = IFCDIRECTION((1.0, 0.0, 0.0));
    #25 = IFCAXIS2PLACEMENT3D(#22, #23, #24);
    #26 = IFCDIRECTION((0.0, 1.0, 0.0));
    #27 = IFCGEOMETRICREPRESENTATIONCONTEXT($, 'Model', 3, 0.000010, #25, #26);
    #28 = IFCPROJECT('0rbbK2c1TFfBGXkq3k_CBa', #8, 'Elements', 'Elements', $, $, $, (#27), #21);
    #29 = IFCSITE('307$HOAJv978fdh6iQQOQD', $, 'Hypar Site', 'The default site generated by Hypar', $, $, $, $, .ELEMENT., (0, 0), (0, 0), 0.0, $, $);
    #30 = IFCRELAGGREGATES('3rKKdrAjj6Bg3s8$acnfQP', $, $, $, #28, (#29));
    #31 = IFCBUILDING('2T7R4ctJz9ROo8O5BpDdaQ', $, 'Default Building', 'The default building generated by Hypar.', $, $, $, $, .ELEMENT., 0.0, 0.0, $);
    #32 = IFCBUILDINGSTOREY('3cDOx1CgX3ve_baTgfFJg7', $, 'Default Storey', 'The default storey generated by Hypar', $, $, $, $, .ELEMENT., 0.0);
    #33 = IFCRELAGGREGATES('130uEkaF5BhQV9QXB6OanO', $, $, $, #31, (#32));
    #34 = IFCRELAGGREGATES('1rCW0JHU19XguGyc527LNt', $, $, $, #29, (#31));
    #35 = IFCCOLOURRGB($, 1.0, 1.0, 1.0);
    #36 = IFCMATERIAL('mass', $, 'Hypar');
    #37 = IFCCOLOURRGB($, 0.500000, 0.500000, 1.0);
    #38 = IFCSURFACESTYLESHADING(#37, 0.800000);
    #39 = IFCSURFACESTYLERENDERING(#37, 0.800000, #37, #35, #35, #35, #35, IFCSPECULARROUGHNESS(1.0), .PHONG.);
    #40 = IFCSURFACESTYLE('mass', .BOTH., (#38, #39));
    #41 = IFCCARTESIANPOINT((0.0, 0.0, 0.0));
    #42 = IFCDIRECTION((0.0, 0.0, 1.0));
    #43 = IFCDIRECTION((1.0, 0.0, 0.0));
    #44 = IFCAXIS2PLACEMENT3D(#41, #42, #43);
    #45 = IFCLOCALPLACEMENT($, #44);
    #46 = IFCCARTESIANPOINT((0.0, 0.0, 0.0));
    #47 = IFCDIRECTION((0.0, 0.0, 1.0));
    #48 = IFCDIRECTION((1.0, 0.0, 0.0));
    #49 = IFCCARTESIANPOINT((0.0, 0.0, 0.0));
    #50 = IFCCARTESIANPOINT((30.0, 10.0, 0.0));
    #51 = IFCCARTESIANPOINT((20.0, 50.0, 0.0));
    #52 = IFCCARTESIANPOINT((-10.0, 5.0, 0.0));
    #53 = IFCPOLYLINE((#49, #50, #51, #52, #49));
    #54 = IFCARBITRARYCLOSEDPROFILEDEF(.AREA., $, #53);
    #55 = IFCDIRECTION((0.0, 0.0, 1.0));
    #56 = IFCAXIS2PLACEMENT3D(#46, #47, #48);
    #57 = IFCEXTRUDEDAREASOLID(#54, #56, #55, 5.0);
    #58 = IFCSHAPEREPRESENTATION(#27, 'Body', 'SolidModel', (#57));
    #59 = IFCPRODUCTDEFINITIONSHAPE($, $, (#58));
    #60 = IFCBUILDINGELEMENTPROXY('05dfLk1Br3gBkiL6rr$Syd', $, $, $, $, #45, #59, $, .ELEMENT.);
    #61 = IFCSTYLEDITEM(#57, (#40), $);
    #62 = IFCRELCONTAINEDINSPATIALSTRUCTURE('18TdxAko18nB7bok_kjT2q', $, $, $, (#60), #32);
    ENDSEC;
    END-ISO-10303-21;

Raised that question earlier in relation with rebar functionality. Like other thing the problem seems to be the are just to many ways in ifc that control it. Needs standardisation.

Here’s how the Geometry Gym Rhino import identifies styling (which is applied as a custom material in Rhino).

I would note that your IFC file isn’t quite schema compliant. You have assigned a IFCSURFACESTYLESHADING and a IFCSURFACESTYLERENDERING. Rendering inherits from shading, and there are where rules restricting to maximum of one of Shading, Lighting, Refraction, Textures and externally defined. https://standards.buildingsmart.org/IFC/DEV/IFC4_2/FINAL/HTML/link/ifcsurfacestyle.htm

I’m not saying this is the reason why implementations aren’t recognizing or rendering correctly, I’m not sure styling has been given the attention that you and others might expect.

2 Likes

@ian - I can confirm @jonm’s observations that your IFC file is not quite 100% schema compliant, but can still be parsed successfully in BlenderBIM (both colour and transparency import correctly), same as Geometry Gym.

I would recommend submitting a bugreport to Solibri and ArchiCAD. Their importers are not open-source and so there is no way that I am aware of how to diagnose it further.

2020-01-26-212713_1920x1080_scrot

Thanks @Moult and @jonm! To be honest, that IFC represents one of many permutations I tried To get something to work, and was a direct copy of the AllPlan generated IFC linked in the issue referenced by @Hans_Lammerts above.

It’s interesting to note that two independent developers built importers that work according to the spec, while the primary vendors did not (unless they can confirm that we are all somehow interpreting the spec incorrectly).

I should also note that prior to trying both shading and rendering, I had tried only shading, which worked in Solibri without transparency, but not at all in ArchiCAD.

One more minor note I just noticed about your file, the IfcSite requires a long/lat of “degrees, minutes, seconds, and, optionally, millionths of seconds”. You have only provided the first two, not the third, which is mandatory.

I might add that FreeCAD, another free and open source software (by @yorik, @bernd, and others) also imports your file successfully and renders the colours correctly. (The green line in the screenshot is because I have selected that particular edge)

I might also add the insight that transparency was only added in IFC4 to the IfcSurfaceStyleShading so that might explain why Solibri might not have quite so good support for it yet.

1 Like

So that makes three uncertified applications that support this spec-compliant behavior and 2 “certified” applications that don’t. Makes total sense :laughing: Thanks for the extra checks!

2 Likes

I can only speak for Allplan because it is the software I have been reporting any IFC issue I now of for almost 7 years now. Some get fixed some not. It is up to them to fix it. Since it is neither OpenSource code nor OpenSource development process (bug tracker, etc) we will have no idea why some issues just do not get fixed even for years.

BTW: I have switched to BIMCollabZoom as my favorite closed source ifc viewer.

Ahh there might be another uncertified application the supports it, try ifcplusplus.

cheers bernd

If you import an ifc in FreeCAD activate debugg messages and watch the report console. I implemented some error logs in the regard of ifc which do have more than one color for one object. I have seen lots of ifc from the proprietary vendors which use different colors for the material assigned to a shape and for the shape itself. Thus no wonder different software show up different colors.

bernd

Maybe the issue is related to this: The way their kernel calculates the RGB

https://www.realtimerendering.com/blog/tag/srgb/

To add to this colour study, Revit does not display colour nor transparency.

Revit is technically not IFC4 certified, but it is nonetheless the most commonly used tool in the industry … that said, if your file was IFC2X3, the colours would still not work in Revit.

@ian if you would like a deep-dive into why exactly colours may or may not work, this thread goes through in quite a bit of detail. In addition, this post describes the prerequisites for colours in Revit.

I have seen lots of ifc from the proprietary vendors which use different colors for the material assigned to a shape and for the shape itself. Thus no wonder different software show up different colors.

@bernd: this is not illegal although I agree it should not be the norm (I have seen it more as the norm). There is an implementer agreement in place that when both are provided, the shape style overrides the material style.

The output in Revit:

image

And yes! @bernd you are absolutely right - this is IfcPlusPlus / IfcQuery - another uncertified open-source, free software implementation that displays both colour and transparency correctly.

Hear Hear! @Moult is the man :slight_smile:

@Moult

There is an implementer agreement in place that when both are provided, the shape style overrides the material style.

Do you have a link to this?

@bernd - I was going to link to it earlier but the links were broken, they are now fixed. See CV-2x3-131. Also of interest is CV-2x3-167. Hope it helps.

I appreciate that you dug these up @Moult and @bernd, but this is incredibly frustrating. In order to understand how applications apply colors I have to read a memo from a meeting that happened in 2006? How am I supposed to know that this memo exists? I had no idea that there were “implementor agreements” aside from the spec, and I would imagine that most other developers are the same.

2 Likes

I’m with you, the industry “regenerates” old-fashioned things again and again

It’s odd when we see most of the resources are from (and based on) 10-15 years ago

However, @Moult and @bernd are right too.

It’s odd when we see IFC 2x3 is for years ago and still software vendors even can’t solve such small things :slight_smile:

1 Like

Makes one question about history of media . Tooknit just as long to get a standard for color tv? Ooo but Color is not ‘information’. :stuck_out_tongue:

1 Like

@ian - I genuinely share your frustrations and you aren’t the first. My belief is that this stems from the history in buildingSMART.

In the words of @jwouellette, the ISG has traditionally been a refuge of the “big” international vendors. buildingSMART historically made decisions behind closed doors, which in my opinion has been the single biggest hindrance towards the adoption of OpenBIM. BCF has been much more successful in a shorter time period, with the support of an ecosystem, without the big vendors involvement.

A good example of this is how one year ago, I noticed that the documentation for generating an IFC GlobalId did not match the algorithm - a fundamental error. After a month of discussion (and agreement that it was wrong), nothing happened, and nobody bothered to return to it after a 4 month reminder and even after it was highlighted as a source of error. Yet another reminder 3 weeks ago revived the discussion, but still, there are no changes, even though the change is fairly trivial and the documentation wording was spelled out explicitly and agreed with an MSG member.

I am still waiting for the GlobalId documentation to be fixed. Note that this fix doesn’t consider another point I brought up a year ago about how the randomness was not specified, meaning that if a digital twin of a city should be created, ID collisions could occur. This point was ignored. GlobalIds are one of the most fundamental aspects of IFC and it is sad to see it given so little attention. For this reason Revit models --which provide sequential IDs-- are useless for us and we have to re-generate all of the IDs.

See another problem only fixed one year later, seemingly by coincidence, not because the issue was recognised on the forum.

Your problem with materials in general has come up before, and again, and yet again, and still again, and I suspect it will come up in the future by another.

There are many, other, examples, but you get the idea.

What this demonstrates, is that although there are clearly qualified technical individuals browsing this forum, is that there is a breakdown in process between technical discussion happening on this forum and actual implementation in the specification. Just like the GlobalId fix is simple, fixing colours is also relatively simple by adding a few sentences to the documentation describing the order of precedence - and the implementer agreement can be removed. There are a few examples on this forum where a mistake or issue has translated into an actual implementation, but they are few and far between. This is a cultural problem.

To be taken seriously by buildingSMART currently requires a paywall membership to the local chapter, self-funding for flights and accommodation for international meetings, and a ballpark figure of ~50,000USD for software certification, of which a publicly available open-source unit test suite could solve half the implementation problems. As a result, we have removed the requirement for buildingSMART certified software in contracts as they no longer are indicative of the quality of data and authoring capabilities. We are also having to produce documentation of all of the known workarounds for these certified software.

That said, I believe things are changing slowly for the better.

The first evidence is this forum’s existence, which previously didn’t exist, despite buildingSMART being around for a while. Also, this which was fixed, although it did take one year. This initiative for a community meeting, which although the first one was cancelled, might happen next month. In addition, @jonm’s work on moving IFC to Git, so that others could theoretically contribute - though the branching is confusing and I have been told that PRs for only minor wording are currently allowed. I have proposed a Free and Open-Source buildingSMART chapter to help open up buildingSMART to the community, but we will see is it is currently on hold, hoping that the community meetings fill this gap.

Please stay active in the forums and help demonstrate to buildingSMART that the community is out there and can make a difference. Please join in the community meeting initiative when it supposedly happens in Feb, and please voice your concerns. I hope we can change things.

buildingSMART still has far to go to increase in transparency. MSG/ISG members should take notice of the forums more and actually propagate suggestions to schema changes, rather than this being a black hole of technical discussion. Expert groups should hold all meetings publicly and give an outlet for the community to voice their concerns.

I understand that there is a rigorous process behind ISO and certification, and these are no doubt good things and do require a hand of authority and selection behind it. However, this process is not mutually exclusive with community outreach and transparency.

1 Like