Textures - functionality in scope

[timchipman]

Texturing in IFC provides many capabilities; for the Coordination Views, we need to decide what should be in scope - perhaps all or perhaps a small subset. Following are some initial recommendations:

1. Entities -- IfcImageTexture supporting relative or absolute URL to image file, IfcBlobTexture supporting embedded file in original format (e.g. png, jpg), and IfcPixelTexture supporting embedded uncompressed bitmap.
   --> Recommend only IfcImageTexture such that initial file retrieval is fast and textures can be loaded in background as needed (or if needed at all for particular app). If using zip file, relative URL may be used to indicate a file within the zip.
2. Single or multiple textures -- Should there only be a single texture indicating diffuse coloring, or should multiple textures be supported for defining additional shader operations for supporting translucency, reflection, light emission, etc., making use of IfcSurfaceTexture Mode and Parameter?
   --> Recommend only single diffuse texture, no translucency (implementations may ignore alpha channel if present)
3. Vertex mapping -- IfcIndexedTextureMap provides efficient mapping to triangulated models; IfcTextureMap provides general mapping to each IfcFace of IfcFacetedBrep; IfcTextureCoordinateGenerator provides procedure-defined ways of calculating texture mapping (e.g. mirrored surfaces, applying mappings to defined faces of parametric geometry)
   --> Recommend only IfcIndexedTextureMap and optional; in absence of texture map, use standard mappings for shapes as documented in IFC4 spec.
4. Texture transforms -- stretch, translate, or rotate textures (particularly useful when there's no vertex map). This allows indication of how many pixels represent a physical length (e.g. 256 pixels = 1 meter).
   --> Recommend in scope
5. Texture stretching or repeating in either direction. IfcSurfaceTexture RepeatS and RepeatT allow indication of whether texture should use the transformed length (e.g. 256 pixels per meter) or stretched to fill each face or triangle.
   --> Recommend in scope
6. Formats -- PNG, JPG, GIF, BMP, ICO, TIF, ...
   --> Recommend limiting to PNG, JPG -- these seem to be the most common on product manufacturer websites

Other aspects? Please comment.

[berlotti]

Anyone that wants to exchange textures in a collaboration/coordination environment please raise your hand.... (and explain why).

Textures are indeed great. Perfect that they are in IFC. But in a coordination view? Even with real hard thinking I cannot come up with a use case that makes sense.

[stefkeB]

It makes sense. Architects are frustrated by lack of visual quality in IFC models. In Solibri we even get only a single color per object. Coordination is also about how things look and are materialized. But don't invent Anything new. Follow FBX or Collada and think about shaders too, not only textures. Allow us beautiful models!

[jwouellette]

I disagree with your interpretation of the purpose of "coordination" stefkeB.

For the Coordination View, textures are NOT necessary. I don't need textures to run an automated clash detection between discipline models, a code check, or do quantity take-off. All "material" info should be embedded as data in the object (IfcMaterial, IfcMaterialLayerSet, etc..), not as rendering. Differentiated coloring is good enough. A case can also be made for further simplifying colors to be limited to one color per discipline model. I'm not saying that's always desirable, but for coordination, textures are too much.

For visualization, or the proposed "Presentation View", I would say that textures are more appropriate. With the further geometric simplification using Tessellation or BREP, I believe this is also more appropriate, as it would enable multifaceted coloring and texturing on a single object.

[stefkeB]

I'm thinking that you ought to seperate information and presentation. Allow detailed material information, including textures. Depending on the coordination you desire, you might be interested in color-coded representation (disregarding actual material color and texture) but this depends on the purpose. Don't enforce a particular color scheme. Sometimes I want red to indicate clashes, sometimes it might represent low LOD, sometimes it might represent paint.

[owensharp]

i agree with Stefan that appearance IS important for coordination which is as much about construction teams visually 'walking the floor' in the model to identify issues as it is about those same models being analysed via rulesets to detect problems - both processes are important and for practical purposes they occur in the same environment.

The ability to identify materials visually without clicking on elements, digging through the parameters to find material, etc is very useful - I too get frustrated with Solibri's 'mono-color' display of object materials - and therefore i would support texturing being part of the CV - although perhaps not a 'deal breaker' in terms of application certification.

and I think the idea of case for one colour per discipline model is not one i can see any end-user receiving positively

[timchipman]

Keeping with the goal of improving usability of IFC models while not imposing additional application functionality, it seems there shouldn't be any requirement that an application reading an IFC file must display textures - it is free to color-code elements as fit, or according to whatever viewing modes are available.

Ultimately, as information needs to be captured that is sufficient for indicating how a building should get built, textures provide a practical fundamental capability for humans to quickly understand how something should be constructed and are particularly useful for finishes -- i.e. a user can spend 5 seconds looking at a floor tile pattern and offset to understand how it should be arranged, or become an IFC expert and dig through properties to figure that out. Similar for cabinetry, masonry, ceiling grids, wall coverings, landscaping, ...

There's also a more subjective aspect of when users see a building model with realistic detail vs. one that looks like a science project -- it can give the impression of whether to bother using the information or dismissing it for an alternative. I have similar discussions with my 14 year old son - to me, there's not much functional difference between Atari 2600 Adventure vs. Doom on XBox 360, but good luck convincing anyone of that who expects 3D realism in this day and age.

Here's a possible "opt-in" approach:

(A) Applications that do not capture textures files on geometry
Import: Ignore texture references
Export: Nothing required

(B) Applications that directly support texture files
Import: Show textures if in viewing mode that supports it
Export: Export texture references, with option of any local files (files that aren't on a server or Internet)

(C) Applications that generate textures from parameters (without explicit files)
Import: Do nothing
Export: Generate files for such textures (or do nothing?)

[jlkiss]

Textures must be included in Reference View/Coordination View! This is not my request, this is what architects want! It is very awkward that we are not able to handle textures in 2014 :)

[jwouellette]

I disagree. I think textures are more important for Presentation/Illustration than Coordination/Clash Detection. It may be OPTIONAL for Reference/Coordination, but REQUIRED for Presentation/Illustration.

[rasso]

... totally agree with Jeff's viewpoint. Textures are absolutely unnecessary for design coordination of different disciplines. For design transfer I would agree to textures. We really need to focus the MVDs on the real purpose of IFC data exchange and should not overload a specific purpose with stuff which belongs to a different purpose.

Rasso

Sent from mobile device

Am 19.06.2014 um 21:20 schrieb "Jeffrey W. Ouellette" notifications@github.com:

I disagree. I think textures are more important for Presentation/Illustration than Coordination/Clash Detection. It may be OPTIONAL for Reference/Coordination, but REQUIRED for Presentation/Illustration.

—
Reply to this email directly or view it on GitHub.

[TLiebich]

We will develop the IFC4 Reference View for several exchange requirements (see also the general presentation of the purposes for the reference view and the design transfer view). Similar to the current IFC2x3 Coordination View, that contains 4 exchange requirements, we will have to separate those for the upcoming IFC4 Reference View.
And yes, it should separate the purpose of presentation / viewing (e.g. by the client or general public), from coordination/ clash detection. The IFC4 RV will include the texture definitions within its sub schema, whether they are required, or option will be driven by the exchange requirements.