I don’t think it’s possible and I also wouldn’t be in favour of this. OBJ is a pretty poorly standardized specification, e.g some implementations support only triangular faces, some polygons, some implementations only support positive some relative indexing, some prefer g for groups other o for objects to distinguish between parts. The mtllib referencing would be awkward within an IFC context.
I would say IfcTriangulatedFaceSet is a really a much more precise, strict and roughly equivalent choice for this kind of geometry.
Thanks @aothms. OBJ was just an example. The intent was to understand whether IFC has support for encoding/caching secondary ShapeRepresentations (as blobs or text strings) that aren’t part of the standard itself. The answer seems to be no. Appreciate the follow-up.
If it’s not possible to support custom IfcRepresentationItems, why does the standard say IfcRepresentations can have a RepresentationType defined by implementers agreements?
“The supported values for [RepresentationType] context type are to be specified by implementers agreements.” – IfcRepresentation
It’s almost like the specification intended to support extensibility here, but then constrained the behavior of subentity definitions so that predefined types are the only ones that can be used in practice.
Are there any existing implementers agreements that use a custom RepresentationType?
I don’t know, the fact that it mentions the wrong attribute name is not promising in that regard
Also the subtypes IfcShapeRepresentation I think has different tone to it in this regard, although the headings on the table are still a bit non-normative.
I think the Body-fallback idea comes from implementer agreements, but that’s a RepresentationIdentifier not a -Type. Adapting the semantic meaning of a shape item (the identifier) is not the same as a extending the schema vocabulary (the type).
I’d have a more nuanced answer. There is no reason that we couldn’t do what you said, because it’s a text file. But it would be unique to represent a “blob” (that is, something you would have to know how to interpret) in an IFC file as a standard. It would require an implementer’s agreement and given IFC has an OBJ-alternative, it probably wouldn’t get accepted as such.
@angel.velez - that’s what I’m interested in: can we even theoretically encode these secondary “blob” representations, instead of having to generate them at runtime, every time. I can’t find a IfcBlobRepresentationItem (a theoretical subentity of IfcRepresentationItem that supports secondary representations identified by a custom RepresentationType) or similar in the schema. So it looks like there’s no way to achieve this, even as an experiment, without inventing new schema entity definitions.
@aothms - Good note on the IfcRepresentationTypes Function callout. This alone doesn’t seem problematic, because the the result of the function is an EXPRESS Logical, where the default response is a Logical “Unknown”. What is problematic for this use case is that Gherkin Rule, because it’s stricter than the current schema in declaring that the only valid RepresentationTypes are those that are predefined.
If the ecosystem is moving to restrict valid RepresentationTypes, will the schema be updated accordingly (e.g., will the Function IfcRepresentationTypes have its return value changed to an EXPRESS Boolean, so anything other than a predefined RepresentationType fails?) or do the Gherkin rules take precedence over the EXPRESS definitions?
@devonsparks I think it depends on what you mean by “invent”. You could have an entity with an empty representation and a property in a property set called “OBJRepresentation” and a property called “Data” that had the encoding. I’m not suggesting you do that of course. But if you are looking for an existing IfcRepresentationItem sub-class that allows for arbitrary data, that doesn’t exist.
Yeah, wasn’t willing to go quite as far as new PSets
That only leaves one remaining curiosity - will the schema be updated to reflect the Gherkin Rules, or should we interpret the Gherkin Rules to have a higher precedence than the schema itself?
will the schema be updated to reflect the Gherkin Rules
My guess is no. Creating these backwards incompatibilities (possible serializations that are no longer deemed valid) on a express level is near impossible in the context of an ISO standard.
But in the greater specification (property sets, concept templates, supplementary rules in the validation service) bSI is not so constrained.
–
Maybe one last (?) concluding remark. Did you consider something like ICDD as a container zipping up heterogeneous data and still allowing fairly granular links? It’s maybe even a bit more interoperable, unzip and open the OBJ in any tool of your liking, as opposed to burying it into some SPF serialization leaving you in the hands of the few parsing libraries that exist to extract it.
Yep - agreed on the value of something like ICDD as an alternative here. Generate your secondary format however you like off the IFC, and stash it together with the original in a zipped container.
In the spirit of a “container”-based implementer agreement, a document reference could work. Something like:
Generate one or more secondary representations off of the IFC.
Relate these representations to their Elements via DocumentReferences.
Set the DocumentInformation metadata for each reference, especially ElectronicFormat (to dispatch on mime type), Location (for its URI), and Purpose.
Consuming systems conforming to the implementer agreement could then check for the presence of these external documents, try to resolve them, and load the cached models as needed.
