IFC Development Monthly Call - 16 July 2020

Developers General Assembly (neé ISG) Meetings
1

Greeting buildingSMART Technical Community,

The next meeting will be 16 July 2020, 13.00 UTC/GMT

The topic for this meeting: Colours and Textures
Please refer to:

Topic summary:

Colours in IFC are a much discussed topic. There is a vast number of options to define colour for an object or a face, and an almost equal amount of ways to overrule that again. Almost none of the current implementations have a 100% valid way to deal with this part of the standard. It is fair to say it is overly complicated and needs to be simplified to become more predicable.

While textures have been defined in IFC for quite some time, there have been very few implementations and no official validation or certification of them.

What are your thoughts and ideas? Do you have a solution? Send us your maximum of 5 slides to technical@buildingSMART.org at lease 24 hours before the meeting and present July 16th at the IFC Development meeting. All ideas are welcome. Feel free to be drastic.”

The meeting will be held via GoToMeeting (Note that there is a limit of 150 attendees) and recorded for others to review and comment. Interaction for this one will be limited, but use of the Chat function will enable us to capture questions and answer them later, if we don’t get to them in the meeting.

IFC Development Monthly Call

Please join my meeting from your computer, tablet or smartphone.
GoToMeeting

You can also dial in using your phone.
United States: +1 (312) 757-3119

Access Code: 362-688-421

More phone numbers
Australia: +61 2 8355 1038
Austria: +43 7 2081 5337
Belgium: +32 28 93 7002
Canada: +1 (647) 497-9373
Denmark: +45 32 72 03 69
Finland: +358 923 17 0556
France: +33 170 950 590
Germany: +49 721 6059 6510
Ireland: +353 15 295 146
Italy: +39 0 230 57 81 80
Netherlands: +31 202 251 001
New Zealand: +64 9 913 2226
Norway: +47 21 93 37 37
Spain: +34 932 75 1230
Sweden: +46 853 527 818
Switzerland: +41 315 2081 00
United Kingdom: +44 330 221 0097

New to GoToMeeting? Get the app now and be ready when your first meeting starts:
https://global.gotomeeting.com/install/362688421

If there are any questions, please let me know.

1 Like
2

I won’t be able to join the meeting (inconvenient timezones) so my 2 cents:

  1. Colour should always associate with a material. This is a well established paradigm, and most programs data models treat colour as an attribute of a material. The fact that right now, a colour may be part of a material, or may be standalone, creates confusion to users. The fact that an object can have a material, and then part of an object has a colour (but wait, it’s just a colour, not a material!) just really confuses people. This makes it annoying to implement for vendors since they need to deal with this mismatch. Just allow materials to be assigned either to the object as a whole, or to individual representation items (change the Styles attribute in IfcStyledItem to Material - problem solved). Or just simplifiy it further: one material may be assigned to “N” representation items.
  2. Other than material, colours are sometimes useful to represent other arbitrary attributes / properties, like the radius of rebar. This data is essentially a “legend” in a diagram, so it should be treated as such in the IfcSchema. I.e., store it in its own IfcClass, perhaps called IfcColourLegend, unrelated to the material classes, which a client application may choose to visualise.
  3. I disagree with the statement below. Supposedly, colour is part of the buildingSMART certification program, so I see this as a fault in the certification program where buildingSMART needs to be stricter on vendors. Specifically, buildingSMART needs to ensure vendors support the material assignment better - as almost all vendors already have geometry-assigned colours working.

There is a vast number of options to define colour for an object or a face, and an almost equal amount of ways to overrule that again. Almost none of the current implementations have a 100% valid way to deal with this part of the standard.

I disagree because:

  • There are 2 ways to define colour: by material, or by geometry. This is not unreasonable. These 2 concepts are well established in the CG and CAD worlds.
  • There are two ways to overrule it: by object instance vs type, or by representation vs material. This is not unreasonable.
  • xBimXplorer, IfcOpenShell, the BlenderBIM Add-on, Solibri, SimpleBIM, FreeCAD, all have valid ways of dealing with this. (Edit: I haven’t tested, but a LinkedIn commenter also suggests SketchUp has no issues)

  1. Now that colours (and alpha channel) are out of the way, we deal with shaders and textures. Coming from CG, I’d really, really like it if IFC didn’t try to reinvent this, as it is a large, complex domain, and a half-implementation in IFC will probably just end up in poor quality data that isn’t really useful to the target usecase: which are CGI ArchViz artists. An attempt to deal with the complexity of UV mapping the many geometric representations in IFC sounds like a nightmare for implementers - most of who are interested in CAD, not CGI. And textures and UV are just the tip of the iceberg. CGI folks want procedurally generated materials for instant visualisation, they want object proxies with textures for vegetation, they want shaders with mipmapping and mixes of multiple materials, biased, unbiased, NPR, PBR, volumetric… it is an entire industry, not something reducable to a few properties in the schema - any attempt to do so would leave the majority of users (which move very, very fast in this space!) wanting more. A better approach would be to let users use the externally defined materials (this feature already exists in the schema), and add a native property for object proxying (right now, an external document association can be used, but it is only a convention and not official).

  2. Finally, colours for purposes of lighting simulation. Instead of copying the properties from an established standard, it would be much better if it could then just reference an external definition - because that’s what would actually happen. Radiance/AGi32 simulationists would have their own materials and proxy objects where required, that can just “plug and play”. Right now, the attempt to copy properties doesn’t really help simulationists as there are many missing properties.

3 Likes
3

By the way, the image (not a photo) below is produced directly from an IFC in the BlenderBIM Add-on - it is a pure IFC model, with textures with full UV mapping (made much easier due to the native mesh representation). It also includes object proxying which goes hand-in-hand with CG texturing of BIM models (for things like photogrammetrically scanned vegetation, entourage, grass particles, etc). Not only is it a render, it is a photometrically correct light simulation, which demonstrates that if an IFC simply links to well-established lighting simulation definitions, it can be used out of the box.

image
image2000×1125 757 KB

All of the assets were released as individual IFC libraries here (this is an old project, so I distributed it as Blender files, but the data is in there).

This was achieved with existing IFC schema functionality by making heavy use of IfcExternallyDefinedSurfaceStyle, and IfcDocumentReference, which allows you to literally drop in a BIM model, and have it used both in CGI rendering, and light simulations (in this case, Radiance). This shows that the functionality already exists in the schema. (As an example of object proxying, when viewed in a regular BIM program which isn’t geared towards CGI, grass would be displayed as a single plane, because each individual blade of grass is irrelevant to BIM authorers, but is highly relevant to CG artists.)

For buildingSMART to support this workflow, it needs to include round-trip certification of these external definitions (one definition for shaders / textures, another definition for object proxying). Once these are preserved reliably, vendors can start writing adaptors for their engine of choice (Radiance, AGi32, Autodesk Cloud Renderer, Arnold, Cycles, Eevee, Renderman, Maxwell, V-Ray, Enscape … the list goes on!)

Shader technology moves fast. Too fast for any perceived stability in IFC. It does not make sense to always play catch-up (and always be behind the CG industry) in copying the highly complex attributes required to describe a CG shader. I advocate the strategy to encourage and certify use of the existing ability to reference external definitions (i.e. externally defined shaders).

Lighting simulation moves slower. Validated simulation software requires their inputs to be preserved - some of these inputs are “common denominators”, e.g. the average diffuse RGB reflectance of materials, which I’m not opposed to keeping in the IFC schema. However, once it gets more complex, it shares the same issues with shaders - how is IFC going to store the same input that will work for all validated engines? It seems wiser to simply reference them as external definitions.

1 Like
4

Let’s stop confusion out of the box !
When it comes to material and surface aspect, many concepts overlaps leading in current fuzzy situation.

There must be a clear separation between those concepts.

  • IfcSubstance / IfcMaterialComponent for material components like melted / concrete made of sand - cement …
  • IfcMaterial with surface color - finish state / thermal / physical properties, made of as many substances needed.
  • IfcStyled"Whatever" for taxonomy you want to highlight using random color
1 Like
5

To provide a bit more clarity from that wall of text - things I propose keeping:

  • IfcSurfaceStyleShading: Basic RGBA as-is
  • IfcExternallyDefinedSurfaceStyle
  • IfcSurfaceStyleLighting (some of these properties might need reviewing - see my previous thread about this)

Things I propose adding:

  • Externally defined representations (for object proxying)
  • IfcColourLegend for arbitrary colouring of arbitrary attributes (inspiration can be taken from IfcColourRgbList)

Things I propose changing:

  • IfcStyledItem “Styles” attribute should be “Material” (singular!) instead. (Note: there needs to be a bit of thinking on how this deals with mapped representations, should a mapped representation want to have a different material. I do not currently have a proposal for this)
  • Actually write it in the docs that a material assigned to a representation overrides a material assigned to an element (as opposed to an implementer agreement)
  • buildingSMART should certify that vendors assign colours via material
  • buildingSMART should certify that vendors maintain external definitions on import / export

Things I propose removing:

  • IfcStyledItem’s “Styles” properties.
  • IfcSurfaceStyleRendering - there is no need. Basic RGBA is already provided in IfcSurfaceStyleShading. The rest have unreliable translations to the multitude of rendering engines.
  • Ifc{Foo}Textures. Surface texture. Texture vertex. Texture coordinate, etc. Leave it to the experts in an external definition.
  • IfcSurfaceStyleRefraction - leave more complex definitions to the experts in an external definition.

In addition, I propose a series of auxiliary guides to be published:

  • Conventions in referencing a external Radiance definition
  • Conventions in referencing a external AGi32 definition
  • Conventions in referencing a <insert CGI rendering engine here> definition, to be contributed and evolved by the community for various CGI rendering engines. I’m pretty sure folks like Unity, Twinmotion, Blender, will be more than happy to fill this void.
6

Thanks to all for joining us on today’s call. @berlotti and I think it was a good start. Here is the link to the recording:
https://app.box.com/s/ta3696pf2mti3jqwkk41uyvh23uvxbg9

To move forward, we would like to form a Working Group of volunteers. The purpose of the WG is to put together a formal proposal on the topic of Colors and Textures based on the discussion. This includes, but is not limited to:

  • Identifying the current issues that are being encountered with the current schemas (IFC2x3 and IFC4.3);
  • Identifying the use cases for colors and textures;
  • Identifying what is in and out of scope for IFC-based solutions;
  • Proposals on optimal solutions for IFC5.

I am happy to help facilitate this WG. Please send an email to technical@buildingsmart.org if you would like to participate. We will use the existing set of tools (GitHub, Box, and Discourse) for communication and documentation.

We should plan on the WG providing the proposal before the end of October in order to help the IFC5 Task Force with its continuing work, and give the community time to review and provide feedback on the proposal before the end of the year.

3 Likes
7

Very good discussion! Clearly other Australians sleep later than me :slight_smile: A couple things I noted from the recording:

  • There was some debate as to how to apply these arbitrary colour legends which are not material based. I.e do you record rules (IMHO: disagree)? Do you bake them (IMHO: agree)? How are they baked? To answer this, I’d like to suggest inspiration from BCF - which allows “component colouring overrides” (essentially baking at the IfcElement level - note it does not bake at the IfcRepresentationItem level, but perhaps it is sufficient). Perhaps the same solution can be used in IFC?
  • There was general consensus that textures is difficult, and if textures are stored, they should be limited to triangulated meshes. 100% agree.
  • The issue with signage. Signage consultants require showing bespoke bitmaps across the model. The example was given about the stop sign, but architects working with signage consultants have the same issue. An attribute is not sufficient - the graphic design is bespoke, and required for stakeholders in safety/regulatory signage, marketing/retail signage during leasing stages, wayfinding in council applications, corporate branding in real estate portfolio investors … and so on. Again, perhaps inspiration can be taken from BCF’s bitmap locations? This allows a combination of either a simple located bitmap (just like BCF, which is geometry agnostic - simply a floating bitmap) + UV mapped triangulated meshes (for more complex scenarios) - that combo seems like an easy way to solve a big problem.
  • There was the discussion of colouring lines. This is a big discussion since it goes into the debate of 2D vs 3D representations. I may, though, propose that perhaps surface styles may apply to everything (points, lines, too, not just surfaces) by default… and then we delay talking about the whole 2D issue until later.
  • The first few slides Thomas showed with the highly nested styles relationship … I am in favour of simplifying that heavily :slight_smile: In fact, I would be so daring as to propose actually adding an RGBA attribute directly to IfcMaterial and removing the whole style chain (yes, yes, it breaks the whole 2D vs 3D styling I know …). Then, for lighting simulation physical properties, it can be added as PSet_MaterialLighting to the IfcMaterial. Similarly, PSet_Material2D can be added perhaps for 2D? I know, it’s a drastic suggestion - but would love to hear thoughts!
  • No discussion was made on object proxying. Object proxying is a usecase vital for CG artists working with BIM models. Just a reminder that it is something to consider :slight_smile: Right now the approach of document references is kinda unofficial.
  • No discussion was made on lighting. Remember: physically correct material properties for lighting simulation is only half the story: the simulation does not work unless you also have lights :slight_smile: For the usecase to be satisfied, support for IES must be had. To start the discussion, the photometric properties should probably allow reference to an IES file. There are other common denominator attributes, but I would prefer to invite some domain experts to comment first!

One bit which was not mentioned is that there is also a way to assign materials to individual shape representations by correlation of the names in IfcShapeAspect. My proposal of simplifying IfcStyledItem to reference a material will therefore make this rather convoluted assignment technique obsolete. See picture below of the current state:

image
image600×600 27 KB

Again, great discussion, and thank you @jwouellette for the transparency in discussion.

1 Like
8

Thanks Moult for all that. The window example is where “colour-overrides” might need to be available at the ShapeRepresentation level - to force the glass to be transparent, while the frame is opaque

9

@tim.sharrock not entirely sure I agree - the IfcColourLegend concept - an arbitrary override colouring scheme is usually used to represent a particular attribute, quantity, or relationship. These attributes, quantities, and relationships are almost always applied to the element as a whole (e.g. PSets / attributes / spatial connectivity, containment, structural properties are assigned to the element) - not to individual representation items. The only common exception to the rule I can think of is material properties … but one could simply use material colours for that instead - which you’ve just described (transparent glass, opaque frame).

Or can you think of other examples where you might need to override on an representation item by representation item basis?