Proposal to deprecate some generated texture coordinates in IfcTextureCoordinateGenerator

[Moult]

Current situation

• UV coordinates are supported. This is not the topic of this proposal though.
• Generated coordinates are supported (X3D calls this COORD)
• Camera coordinates are supported (X3D calls this either CAMERASPACEPOSITION or COORD-EYE with seeming equivalency)
• Out of the box X3D (and therefore IFC) supports a number of other coordinate types. Some of these are downright crazy and nobody would ever use them. I don't think anyone would implement them. As a result of our conversation, we suspect these will see a culling in X3D. For example, when have you ever taken geometry vertex coordinates then applied a noise with a user configurable parameter to distort your texture coordinates?
• Using a transformation mapping to shift texture coordinates is supported

Proposal

The ambiguity of the two camera coordinates should probably be resolved to choose one or the other.

In addition, the other coordinates are outdated or kinda crazy :) Maybe it should just be culled down to "COORD" + one more for the camera coordinates?

[Moult]

Before I write a more substantial proposal for this I've reached out to michalis from X3D about different projection methods for coordinates (box, flat, etc):

https://community.osarch.org/discussion/comment/10512/#Comment_10512

[Moult]

IFC has two primary usecases for generated coordinates:

1. Sticking a image to a plane without worrying about the complexities of UV
2. Can I specify an image (e.g. brick texture) and have it "naturally" wrap around an arbitrary shape

Out of the box, the default texture coordinates generated for arbitrary shapes (IndexedFaceSets) in X3D try to be "clever" and have rather bespoke rules on choosing a texture orientation and how it is clipped. The rules are documented here.

However for specific shapes that aren't arbitrary, like rectangles, spheres, etc, similar to IFC, X3D defines special texture mapping rules.

For the first IFC usecase of an image on a plane, the equivalent in X3D is the texture mapping shown in their Rectangle2D geometry definition here. In modern tools like Blender, this correlates to this setup (note how "Generated" is used and the texture projection type is set to "Flat"):

However, when we get to the general problem of how to get an arbitrary image to "naturally" wrap around an arbitrary shape, there is no known general solution in the X3D / glTF world. Instead, X3D specifies specific texture coordinate rules for specific shapes (e.g. spheres, extrusions). Note that IFC has come to a similar conclusion - it has rules for spheres, blocks, and extrusions. glTF does not understand specific shapes and instead only deals with generic meshes and so does not have this solution.

End-user artistic applications attempt to add extra cleverness when faced with arbitrary shapes. For example, in Blender there is a "Box" or "Sphere" or "Tube" projection setting. There are many variations of this cleverness and they are not generally interoperable between applications. X3D does not attempt to specify this clever behaviour due to its inconsistency across end-user apps - it's very difficult for implementers to replicate. I suspect IFC would come to same conclusion: should we make this complexity the responsibility of the implementers, or the responsibility of the model author in their platform who then generates UVs. Another advantage of not specifying this and just relying on UVs is that the UVs remain locked in case the model is ever animated in the future. If it is generated, what happens when the object moves? Right now, IFC doesn't specify animated objects. In the future, especially with transport domains and when 4D gets smarter, who knows.

Therefore I would propose for IFC to follow in X3D's direction and:

1. Use something similar to the texture coordinate rules for Rectangle2D as the default IFC projection for arbitrary shapes. This is the least "magic" and most intuitive for artists who want to put images on planes.
2. For specific shapes (sphere, block, extrusion) leave as is - the IFC rules are similarly bespoke for our industry as is X3D's rules for their primitives. Maybe there is an opportunity for alignment between spheres which exist both in X3D and IFC but i'm tired.
3. For arbitrary shapes, users should specify UV coordinates if they want any clever texture mapping.

To do this, change this paragraph in IfcSurfaceStyleWithTextures:

The entity IfcSurfaceStyleWithTextures is part of the surface style table for presentation information assigned to surfaces for shading, rendering and lighting with textures. The mapping of the texture onto the surface or the solid is determined by the texture coordinates. In absense of an IfcTextureCoordinate assigned to each surface texture, a default mapping of the texture to the geometric face or surface applies.

First add this sentence:

If the geometry is of a special IFC type which defines a texture mapping, such as an IfcSphere, IfcBlock, or IfcExtrudedAreaSolid, then that definition is the default texture mapping.

Then, there are two options to add:

Option 1: Texture stretches to input geometry. Easy :D (note: I prefer this - also I reckon an architect would prefer this)

If geometry has no special texture mapping definition, the Texture U coordinate comes from local vertex X coordinate. Texture V coordinate comes from local vertex Y coordinate. Along each axis: texture coordinate goes from 0 to 1, as the geometry goes from bounding box minimum to maximum.

Option 2: Texture stretches to longest dimension of input geometry, and is cropped elsewhere when aspect ratio does not match between texture and geometry. More complex, but prevents warping of texture.

If geometry has no special texture mapping definition, the Texture U coordinate comes from local vertex X coordinate. Texture V coordinate comes from local vertex Y coordinate. The aspect ratios of the bounding box and the texture are compared such that the texture always expands to fill the boundingbox. Where the aspect ratios do not match, the texture is cropped. TODO: write this in math.

(Note: prose by Michalis from X3D)

[Moult]

Can we get some votes in for Option 1 or Option 2 so this can move to decided? My personal preference is Option 1, given that many users would likely mess up the exact aspect ratio, so stretching to fit is a good assumption to make so it "looks right" out of the box, and if they actually cared about it, they would properly model their geometry or edit their image anyway.

[aothms]

I agree, stretch to fit.

[TLiebich]

+1 for option 1

[Moult]

Cheers, upgrading to decided so that in the next few days I can help implement this.

[aothms]

Currently we mark enum items as deprecated using solely the Md. I propose to keep it like that. We can't model it in Express and changelogs for enums are currently calculated based on the express, so there isn't any real upside currently in expressing this in UML. So I'm not attaching the affects-uml label.

[Moult]

If we get the time I will put in some images and examples.