Closed timchipman closed 10 years ago
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.
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!
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.
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.
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
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?)
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 :)
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
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.
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.
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:
Other aspects? Please comment.