# Adding an OBJ IfcShapeRepresentation? **URL:** \ **Category:** Uncategorized\ **Created:** [January 19, 2024, 10:11pm UTC](https://forums.buildingsmart.org/t/adding-an-obj-ifcshaperepresentation/5126 "2024-01-19T22:11:25Z")\ **Posts on this page:** 14\ **Page:** 1
**Author:** ![devonsparks](https://sea2.discourse-cdn.com/flex016/user_avatar/forums.buildingsmart.org/devonsparks/32/539_2.png) [@devonsparks](https://forums.buildingsmart.org/u/devonsparks)\ **Post date:** [January 19, 2024, 10:11pm UTC](https://forums.buildingsmart.org/t/adding-an-obj-ifcshaperepresentation/5126/1 "2024-01-19T22:11:25Z")
Is there a schema-compliant way to add a textual ShapeRepresentation, like OBJ? I can create an `IfcShapeRepresentation`, and declare its `RepresentationType` to be `"OBJ"`: ```auto #10= IfcShapeRepresentation($, $, "OBJ", (#20)) ``` And now I’d like to have some kind of `IfcRepresentationItem` as its target, like `#20= IfcGeometricRepresentationItem(...)` that somehow encodes a text literal representing the OBJ geometry, e.g.: `"v 0 0 0\nv 0 0 2.3\nv 0 0.3 2.3\nv 0 0.3 0\nv 5 0 0\n..."` Is this possible within IFC4.x? ---
**Author:** ![aothms](https://avatars.discourse-cdn.com/v4/letter/a/c67d28/32.png) [@aothms](https://forums.buildingsmart.org/u/aothms)\ **Post date:** [January 20, 2024, 2:05pm UTC](https://forums.buildingsmart.org/t/adding-an-obj-ifcshaperepresentation/5126/2 "2024-01-20T14:05:43Z")
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. ---
**Author:** ![devonsparks](https://sea2.discourse-cdn.com/flex016/user_avatar/forums.buildingsmart.org/devonsparks/32/539_2.png) [@devonsparks](https://forums.buildingsmart.org/u/devonsparks)\ **Post date:** [January 20, 2024, 4:55pm UTC](https://forums.buildingsmart.org/t/adding-an-obj-ifcshaperepresentation/5126/3 "2024-01-20T16:55:15Z")
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. ---
**Author:** ![devonsparks](https://sea2.discourse-cdn.com/flex016/user_avatar/forums.buildingsmart.org/devonsparks/32/539_2.png) [@devonsparks](https://forums.buildingsmart.org/u/devonsparks)\ **Post date:** [January 21, 2024, 9:27pm UTC](https://forums.buildingsmart.org/t/adding-an-obj-ifcshaperepresentation/5126/4 "2024-01-21T21:27:03Z")
Actually, one clarifying question: 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](https://standards.buildingsmart.org/IFC/DEV/IFC4_2/FINAL/HTML/schema/ifcrepresentationresource/lexical/ifcrepresentation.htm) 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`? ---
**Author:** ![aothms](https://avatars.discourse-cdn.com/v4/letter/a/c67d28/32.png) [@aothms](https://forums.buildingsmart.org/u/aothms)\ **Post date:** [January 22, 2024, 2:01pm UTC](https://forums.buildingsmart.org/t/adding-an-obj-ifcshaperepresentation/5126/5 "2024-01-22T14:01:58Z")
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). Overall the ecosystem is moving into restricting these [ifc-gherkin-rules/features/GEM004\_Constraints-on-representation-identifiers.feature at main · buildingSMART/ifc-gherkin-rules · GitHub](https://github.com/buildingSMART/ifc-gherkin-rules/blob/main/features/GEM004_Constraints-on-representation-identifiers.feature#L22) Also, are you aware that the value actually has validity implications also in the schema? [8.18.6.3 IfcShapeRepresentationTypes - IFC 4.3.2 Documentation](https://ifc43-docs.standards.buildingsmart.org/IFC/RELEASE/IFC4x3/HTML/lexical/IfcShapeRepresentationTypes.htm) Unknown values result in indeterminate though, not invalid/false. ---
**Author:** ![angel.velez](https://avatars.discourse-cdn.com/v4/letter/a/4bbf92/32.png) [@angel.velez](https://forums.buildingsmart.org/u/angel.velez)\ **Post date:** [January 22, 2024, 5:09pm UTC](https://forums.buildingsmart.org/t/adding-an-obj-ifcshaperepresentation/5126/6 "2024-01-22T17:09:22Z")
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. ---
**Author:** ![devonsparks](https://sea2.discourse-cdn.com/flex016/user_avatar/forums.buildingsmart.org/devonsparks/32/539_2.png) [@devonsparks](https://forums.buildingsmart.org/u/devonsparks)\ **Post date:** [January 22, 2024, 6:08pm UTC](https://forums.buildingsmart.org/t/adding-an-obj-ifcshaperepresentation/5126/7 "2024-01-22T18:08:13Z")
@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? ---
**Author:** ![angel.velez](https://avatars.discourse-cdn.com/v4/letter/a/4bbf92/32.png) [@angel.velez](https://forums.buildingsmart.org/u/angel.velez)\ **Post date:** [January 22, 2024, 6:32pm UTC](https://forums.buildingsmart.org/t/adding-an-obj-ifcshaperepresentation/5126/8 "2024-01-22T18:32:09Z")
@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. ---
**Author:** ![devonsparks](https://sea2.discourse-cdn.com/flex016/user_avatar/forums.buildingsmart.org/devonsparks/32/539_2.png) [@devonsparks](https://forums.buildingsmart.org/u/devonsparks)\ **Post date:** [January 22, 2024, 6:36pm UTC](https://forums.buildingsmart.org/t/adding-an-obj-ifcshaperepresentation/5126/9 "2024-01-22T18:36:49Z")
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? ---
**Author:** ![aothms](https://avatars.discourse-cdn.com/v4/letter/a/c67d28/32.png) [@aothms](https://forums.buildingsmart.org/u/aothms)\ **Post date:** [January 22, 2024, 7:30pm UTC](https://forums.buildingsmart.org/t/adding-an-obj-ifcshaperepresentation/5126/10 "2024-01-22T19:30:01Z")
> 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. ---
**Author:** ![jbrouwer](https://avatars.discourse-cdn.com/v4/letter/j/4bbf92/32.png) [@jbrouwer](https://forums.buildingsmart.org/u/jbrouwer)\ **Post date:** [January 22, 2024, 7:58pm UTC](https://forums.buildingsmart.org/t/adding-an-obj-ifcshaperepresentation/5126/11 "2024-01-22T19:58:22Z")
That IfcPropertySingle value could also have the type IfcBinary and allow for even more exotic representations. ---
**Author:** ![devonsparks](https://sea2.discourse-cdn.com/flex016/user_avatar/forums.buildingsmart.org/devonsparks/32/539_2.png) [@devonsparks](https://forums.buildingsmart.org/u/devonsparks)\ **Post date:** [January 22, 2024, 8:16pm UTC](https://forums.buildingsmart.org/t/adding-an-obj-ifcshaperepresentation/5126/12 "2024-01-22T20:16:37Z")
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. Appreciate the consult 🙂 ---
**Author:** ![stefkeB](https://sea2.discourse-cdn.com/flex016/user_avatar/forums.buildingsmart.org/stefkeb/32/1755_2.png) [@stefkeB](https://forums.buildingsmart.org/u/stefkeB)\ **Post date:** [January 23, 2024, 3:53pm UTC](https://forums.buildingsmart.org/t/adding-an-obj-ifcshaperepresentation/5126/13 "2024-01-23T15:53:42Z")
Couldn’t external “OBJ” (or GLTF or …) geometric “blobs” be covered with a Document Reference? ---
**Author:** ![devonsparks](https://sea2.discourse-cdn.com/flex016/user_avatar/forums.buildingsmart.org/devonsparks/32/539_2.png) [@devonsparks](https://forums.buildingsmart.org/u/devonsparks)\ **Post date:** [January 24, 2024, 1:10am UTC](https://forums.buildingsmart.org/t/adding-an-obj-ifcshaperepresentation/5126/14 "2024-01-24T01:10:42Z")
In the spirit of a “container”-based implementer agreement, a document reference could work. Something like: 1. Generate one or more secondary representations off of the IFC. 2. Relate these representations to their `Elements` via `DocumentReference`s. 3. 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.