buildingSMART Forums

Is it possible to attach texture mapping information to ifc files?

Hi, I am a developer and I am not sure if it is possible to attach texture mapping information to ifc files(it is related to my current work).
I am told by many people that ifc does not support texture mapping but I found many related webpage saying that ifc actually supports texture mapping. For example:




For the second one, we could even download a sample file. However I could not open this file using all the ifc viewing software(such as bim vision, solibri, and FZKViewer, etc.)

So I resort to the official forum to query if is it possible to attach texture mapping information to ifc files. If so, could you give me a sample file which can be viewed by an ifc viewing software.

Thank you so much.

Just because software does not support it, does not mean the schema does not have the possibility (as you have correctly found in the documentation). Unfortunately, I cannot tell you which viewing software supports textures so that you could test it. :frowning:

Maybe this post helps:

@citystrawman The ISG along with current and previous bSI certification regimes have never pursued wide implementation, testing and certification of textures, even though they have been supported in IFC for some time. The main thrust of IFC support has centered around design coordination (which is no small feat, but highly valuable), with no requirements for “realistic” visualization. A couple of other vendors have expressed a desire to move forward with texture support, but I think we need more workflow information and a better definition of the optimal exchange requirements (and respective IFC elements) for a good rendering/visualization MVD.

@jwouellette It seems that these days many have focused on IFD
Which including texture and also “material development” becomes important for “PDT”

This is why these days we hear this question constantly

And I think if buildingSMART wants IFD and IFC be integrated and work well with each other have to “reconstruct” IFC structure, and focus more on “Classification” and “Material Catalog/Dictionary” development

I say let’s drop IfcRoot, IfcOwnerHistory, and IfcObjectDefinition, …, and just have the end one
For instance an IfcWindow is just an entity --> We can with “CLASSIFICATIONS” say that a window is an object, a product, an element, a building element

Thank you for your explanation.

Problem is that the IFC examples are not even valid:
IFCBLOBTEXTURE blob is unreadable in tessellation-with-blob-texture.ifc as it doesn’t contain valid PNG texture
The RasterCode element in XML example(ifcblobtexture.htm) has correct value for texture.

Also tessellation-with-image-texture.ifc is missing companion file “texture.png”

The only viewer I know which supports IFC with textures is Gygax viewer but was not able to compile it as it relies on old PCL library for displaying point clouds.

There is real need for IFC to support basic texture information not just “realistic” visualization. Delaying implementation and certification of texture support is bad move as it doesn’t allow to catch out issues earlier as it was with IFC2 issue with blob texture specified as boolean and not binary.

See for example this publication which shows where it could be beneficial - Integrating RC Bridge Defect Information into BIM Models: 2018_Borrmann_bridgedefects.pdf

Attaching IFC examples with corrections -