Add an IfcStyle to an object without creating an IfcMaterial

Hi all, I've been lurking on this forum for a while now and decided to start asking some questions that I can't find answers to in my searches.
As far as I gather, colours of objects in IFC is one of those which is much easier said than done.
From my understanding, it is possible to assign an IfcStyle to an IfcElement without needed to go via an IfcMaterial. If this understanding is correct, can someone let me know if it's possible to accomplish this via the BlenderBIM UI?
There is a discussion here where Moult shows a method via the IfcOpenShell api: https://community.osarch.org/discussion/comment/12260/#Comment_12260
Thanks

Comments

  • I've been experimenting with various ideas and in my efforts I have noticed an unexpected behaviour.
    My source IFC (2x3), when opened in all my viewers, has consistently coloured objects (which exact type of IFC colour this is I don't yet know).
    Now if I open the IFC in BlenderBIM - and do nothing except immediately Save the Project - and now open in Navisworks, the colours are gone. In other viewers (BC Zoom, BIMvision, simpleBIM) the colours remain. So you could argue that the fault is with Navisworks in this case.
    However what this means is that something has changed inside the IFC, simply by opening and closing it with Blender. This surprises me tbh as I thought the idea was that BlenderBIM didn't run an import/export process, in order to avoid this sort of thing.

  • CSNCSN
    edited July 2023

    With a bit of testing I found the change. Test cube was created in Blender, then coloured with Set Colour in simpleBIM, then I reproduced my issue.

    #80 is the main culprit, BlenderBIM makes this change:
    Original #80 = IFCSURFACESTYLERENDERING(#81, 0., $, $, $, $, $, $, .NOTDEFINED.);
    BBIM#80=IFCSURFACESTYLERENDERING(#81,0.,#127,$,$,$,IFCNORMALISEDRATIOMEASURE(0.),IFCSPECULARROUGHNESS(0.5),.NOTDEFINED.);
    It also includes a new line:
    #127=IFCCOLOURRGB($,0.800000011920929,0.800000011920929,0.800000011920929);
    No idea why it does this as #127 isn't referenced anywhere else.
    I've uploaded my test ifcs. Maybe this is expected behaviour, if so I'd be interested to know why? Thanks

    atomkarincaArv
  • Well it looks like it is referenced in line 80 : #80=IFCSURFACESTYLERENDERING(#81,0.,#127,$,$,$,IFCNORMALISEDRATIOMEASURE(0.),IFCSPECULARROUGHNESS(0.5),.NOTDEFINED.);

    According to the docs I would say this new line adds a DiffuseColor component that is used by rendering engines to calculate shading effects. It also adds values for transparency and roughness ? I don't know why this makes other viewers fail though. Those attributes look like they are optional.

    Arv
  • Ah yeah thanks - time to get my eyes checked.
    I think my surprise is mainly based on the fact that BlenderBIM has modified my IFC without me really asking it to. I can only assume it's somehow necessary in order for BBIM to be able to 'read' the IFC into Blender?
    As a very general principle I think BBIM should avoid editing parts of the IFC that the user hasn't asked for - but perhaps in this case it has no choice?

    atomkarinca
  • edited August 2023

    There might be a bug there, since according to the docs these arguments are optional, I don't see why the BlenderBIM addon tries to "fix" it by adding the definitions.

  • CSNCSN
    edited August 2023

    After updating the add-on to the most recent (20230804) version, this behaviour is no longer present. (as a side-note, should have done this earlier - the new UI is cool!)
    I still need to wrap my head around materials/styles/colours etc and how each of them is related to the other. The original idea of adding colour to my objects without using an IfcMaterial is still something I'd like to do (if it's possible).
    I'm not sure what changed to fix the issue above, but after a very quick search, might have been this one? https://github.com/IfcOpenShell/IfcOpenShell/commit/f3924249e910caa82fd7b169c000391d68b865de

Sign In or Register to comment.