New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
missing entity for defining texture maps for polygonal face sets #135
Comments
yes the request is valid. When adding the IfcPolygonalFaceSet in IFC4.0.2 adding, the need to also add a particular support for textures on polygonal faces seems to be missed. It would be a good time to add. I briefly checked the spec. The addition would be along: ENTITY IfcIndexedPolygonalTextureMap a where rule could be added to check that the entity type the the corresponding face set is actually a IfcPolygonalFaceSet. Along (to be validated) WHERE Note: similar should be added to IfcIndexedTriangleTextureMap WHERE |
Also at IfcIndexedTriangleTextureMap consider to make to attribute TexCoordinate mandatory. ENTITY IfcIndexedTriangleTextureMap |
One problem I see is that polygonal faces can have holes. So a one
dimensional list of indices per face might not be enough. I was thinking to
reuse the same polygonal face definition but pair it with a 2d coord list.
Sent from a mobile device. Excuse my brevity. Kind regards, Thomas
Op wo 12 jan. 2022 19:27 schreef Thomas Liebich ***@***.***>:
… Also at IfcIndexedTriangleTextureMap
consider to make to attribute TexCoordinate mandatory.
ENTITY IfcIndexedTriangleTextureMap
SUBTYPE OF (IfcIndexedTextureMap);
TexCoordIndex : LIST [1:?] OF LIST [3:3] OF IfcPositiveInteger;
END_ENTITY;
—
Reply to this email directly, view it on GitHub
<#135 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAILWV63SZPQEJM27JQOSDDUVXB2HANCNFSM5LZVFS6Q>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
You are receiving this because you are subscribed to this thread.Message
ID: ***@***.***>
|
quesion to all with a good understanding how CG and shaders work in detail. Is it sufficient to have the outer contour texture coordinate mapping (to position the texture coordinates onto the 3D plane) and leave it to the geometric engine to cut out the inner holes from the texture, or do we need the holes already in explicit 2D texture coordinates upfront? |
I'd say for the shader it's too late, their you need a consistent vertex definition. And at that time you're also already talking about triangulated data. I think you could argue that the indeed the inner bounds uvs should be linearly interpolated from the outer bounds. But if we do that we're going to have to define how, to prevent ambiguities. The outer bound uv coords do not necessarily define a consistent embedding of uv space in 3d. Typically of course they should and will otherwise you have weird distorted appearance. I'd still prefer to have uv definitions also for the inner bounds just for the sake of less work for (a) bSI spending less time on spelling out how to interpolate and (b) viewer implementations having to write code for the interpolation. |
based on a group discussion, the following proposed solution was defined:
|
and the EXPRESS code
|
For the record, the diagram makes sense to me. I recently implemented the triangular counterpart and as far as I can tell this follows the same concept. I see minor discrepancies between the names in the diagram "InnerCoordIndices" and "Text" vs "Tex" (Tex is what currently exists) but I assume these will be resolved. I thought I was able to, and I really did try to think of a simpler diagram but I failed :) In particular its the voids in faces which make it very difficult to simplify. This proposal gets the +1 from me. |
Just for the record, there was a proposal by @aothms to create an attribute relating IfcIndexedPolygonalFace and IfcTextureCoordinateIndices. This means:
This creates value because it means you don't need to split geometry up if you only want to texture a portion of it. This means you retain closed shells which makes quantification easier. The specification of exactly the same order also has advantages sense it makes it less rigid for implementers - they don't need to loop poly faces and UV faces at the same time. |
A good note by Michalis is that a benefit of having the attribute that links polygonal faces with texture faces is that this decouples textures from representations - it allows UV coordinates to be reused by different representation items. |
@TLiebich so you are worried about an inconsistency, where TriangleTextureMap relies on an ordered list of faces, IndexedColourMap relies on an ordered list, but IndexedPolygonalTextureMap does not? |
I agree, we need the order, because the per-face colour indices are provided as a list. I have another proposal though for IndexColourMap. Currently we support only face colours, not vertex colours. The latter is quite appropriate for dense meshes obtained from scans or other data. The vertex colours are then interpolated over the faces. I think what we can do is make ColourIndex optional. In which case the ColourList should match the dimensions of the cartesian point list? Thoughts? |
we discussed this in the IFC4 time frame and decided at that time to not include color by vertex. However with infrastructure, meshes coming from surveys, etc. it could be time to revisit it. however we need different solution - we can't rely on corresponding Cartesian point and RGB lists. Those could also be shared by several tesselations and using pxindex also allows to have a different sequence. Im my view, it would require to have a dedicated entity for colour by vertices. |
regarding last question ny @Moult - yes, this is what I thought - having inconsistency in observing order and also direct links. Not sure whether it is crutial. |
I don't fully understand. I don't think it's realistic to expect [reuse with] the same positions with different colours, or vice versa, in the case of detailed survey meshes. Also I think defining them in the same order is a realistic requirement. If you think it deserves a separate entity I can live with that, but I don't think the mechanism of optional indices is illegible, where if absent it maps to the vertices directly. In the opengl world vertex colours is also much more common than face colours (which barely exists because you only have the vertices with position/normal/colour/uv and than faces only as indices without any possibility for attributes). |
So is the proposal to go back to #135 (comment) ? I do not have a strong opinion either way anymore. |
If that's so, I am happy to give a +1 to it. It's consistent with the way the rest of the schema works, and it solves the problem. Could it be better? Perhaps, but also sounds like it'd be a lot of work to make everything consistent, which takes time which we don't have. Maybe better revisited after IFC4.3, but the current proposal is fine by me. If nobody has objections, I'll mark this as decided on Monday. Also fun to note this issue was brought up almost 2 years ago. |
Happy days, marking this as decided so it can be implemented :) |
It looks as though this is implemented. Closing :) |
original issue from SCTE Review (Norway)
IfcIndexedTextureMap is missing a subtype for textures for IfcPolygonalFaceSet
https://standards.buildingsmart.org/IFC/DEV/IFC4_3/RC2/HTML/schema/ifcpresentationappearanceresource/lexical/ifcindexedtexturemap.htm
Here it states:
" Subtypes of IfcIndexedTextureMap establish the index attribute corresponding to subtypes of IfcTessellatedFaceSet defining the corresponding index lists of vertices."
So, if I want textures on my IfcTriangulatedFaceSet, I will of course use the subtype IfcIndexedTriangleTextureMap. But if I want to have textures on my IfcPolygonalFaceSet, there seems to be missing a corresponding IfcIndexedPolygonalTextureMap.
The IfcIndexedTextureMap is abstract, so we can’t use that.
The text was updated successfully, but these errors were encountered: