buildingSMART Forums

IFC - Problem about Elements with Texture

I should clarify here what you are looking for if you do intend to open up the .ifc file.

Assuming you mean an image texture, you are looking for is IfcSurfaceStyleWithTextures, which would then assign an IfcImageTexture with a URI to your image file. Assuming those are there, then it is a relatively safe assumption that somewhere in the IFC file, your texture is captured. You then need to verify that the texture is assigned as a style representation for your IfcMaterial which is associated with your BIM element / shape. This differs between IFC2X3 and IFC4, and so you will need to check the specification to know exactly what the process is. For instance, I am aware that in Revit exporting an IFC4, it incorrectly assigns presentation styles using deprecated methods, which may explain why things don’t work (specifically, Revit incorrectly uses IfcPresentationStyleAssignment on export).

If you share your file here (by exporting a portion of your model, if you are concerned about intellectual property), we can help more.

Thanks, today I´m out of office. I´m going to contact with a collegue in order to answer you and try to give you the IFC File.

Thank you very much.

Hello Moult,

IFC-with-texture.ifc (3.5 MB)
Thank you very much for the quick response. Here you have an example of the format with which we have the problem of textures. I hope you can help us.
Thank you

P.D: The software we work with is called Istram BIM and it is a software of Linear Work for the development of projects of roads, railways and pipelines fundamentally.

Manuel

Hi Manuel.

Unfortunately, your authoring program is not saving the texture in the IFC file to begin with - this is why you don’t see the texture.

I also noticed that everything in your IFC file is an IfcBuildingElementProxy and it doesn’t contain data such as psets, or qto. Has the file been stripped down? Maybe the texture data was stripped with it.

To date, There has not been an emphasis on implementing the texture features of IFC. Most effort has gone into coordination support (including quantity takeoff and spatial validation workflows) with less complex color support.

If this is a high-priority need, then the end user community should develop some consensus around the workflows and exchange needs so the technical community can help the implementer with support. My understanding is that further schema enhancements may be necessary to support textures robustly. Thus, this may be suited for the next major version of IFC and not IFC4.x

Isn’t it also true that setting texture coordinates (UV-coords) is only supported for a few geometry classes, mostly tessellated BREP geometry? All other geometry types have no explicit texture mapping and thus require an interpretation based on the geometric operation which they imply.

I have tried to get at least something usable by using box-projection (after importing geometry from IFC) so materials with textures show a mapped texture. The texture map itself and the box-mapping is done afterwards and thus not translated via IFC.

Problem is that even the Buildingsmart 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 find compiled version which would run on Windows 7/10

The missing texture file and the error in the blob texture is already noted and should be updated with the next technical corrigendum of the IFC specification.

@andreas.geiger - you also had some findings here, could you please share?

Hi Thomas,
No. I have no more issues to the blob texture. It is working in FZKViewer. My problem was a that I had mixed up the definitions between Part 21 and Part 11.

As a related issue to texture support, BlenderBIM has now implemented improved support for externally defined materials. You can link in a “material passport”, which defines shaders for multiple rendering engines. This allows you to link in not just textures, but highly complex material shaders for multiple uses, such as traditional visualisation, real time game engine views, and light simulation. Please note that this is purely a link to external shader standards, not the built-in IFC texture support, but it is highly useful nonetheless and therefore may be relevant to this discussion.

Could you please share a working example as my blob texture examples crashes FZK Viewer.

Hello,
this is a slightly modified example working with the latest version of the FZKViewer.
Regards Andreas
tessellation-with-blob-texture_ag.ifc (23.0 KB)

1 Like

Where to look for latest IFC examples?

What I found is these old examples seems to be more correct - https://users.ugent.be/~pipauwel/AUTCON2017_ifclists/0_IFCSPF/

Texture:
diagnostic

FZKViewer 5.3 no longer shows textures.

I have checked with version 5.3 (Build 1004) and in general it is working.
What exactly is not working (image texture, blob texture)? Is texture mode activated?
In the folder you have mentioned “0_IFCSPF” the texture file is missing.

The recent discussion at the ISG/IFC development meeting led to this:

But before making a final decision, it their any reason anyone can think of for continuing to support PixelTexture and BlobTexture?

Ok, seems it is issues with graphics on the computer as the same build 1004 works correctly on other machine. Texture file is missing but it can be extracted from blob texture example only need to drop the leading zero in blob data not sure the purpose of that.

BlobTexture seems to be more flexible as no need to keep textures as file and package together so easier to use in common data environment. But ifczip could be also used instead.

I would consider textures external to the IFC file wherever possible and use Document Reference or similar mechanisms to reference them. An IfcZip container may be usable to “embed” them. In STEP and others, they may remain external, which often makes it easier for software developers, as they can be handled by regular JPEG/PNG/GIF compatible software library methods.

IFC has limitations through external… methods
I think @Moult mentioned these limitations before and even shared a POC through BlenderBIM some comments above

However, if you decide to use new versions of STEP the federated approach will happen and most of the existing obstacles will solve

However, still, there would be a need to work and improve colors, shaders, materials, etc too