@PatrickRyan thank you for your detailed explanation which clarifies much for me. I would be grateful if you would check whether what I am saying below is correct or not.
When reading this, from our docs around normal maps , I missed the stored part of To illustrate this, here is a simple graph to show how the UVs are stored in a glTF file versus .babylon file:
. I was think about how they were viewed online rather than stored.
I still believe there is an error in this diagram
since top left and bottom right of the glTf cannot both be (0, 1)
For clarity and hopefully less confusion I am going to use the terms readable and upsidedown for image/ textures rather than coordinates. By readable I mean when viewed directly on the web English text will read as normal and a rotation of 180o makes them upsidedown. As viewable means the displayed orientation in 3D matches as seen on the web.
The following two are readable
Link Link
The following one (from inside a glTF) is upside down. (It was difficult to find an image with text inside a glTF)
Link
Taking a plane created in babylon.js and also saving it as glTF the following occur when default settings are used, applying the images as material after the plane is created or imported, the orientation of the image on the plane matches ; i.e. readable stays readable and upside down remains upside down. For example
When the image is within a glTF model and the whole model imported the image is displayed as readable although it is upside down within the glTF.
In the case of upsidedown images needing to be readable on the plane this can be dealt with on importing or by using uv scales.
However @ecoin 's issues are not that straight forward. When importing models with textures or models and textures separately there is no way of knowing prior to importing about the construction of the models or how the uv mapping onto vertices have been done. For example the PG below shows a cube created within Babylon.js and one imported from a glTF. If the imported cube had had its texture set before exporting Babylon.js would display the cube with its texture as saved.
When meshes and textures are being mixed and matched from a range of sources there can be no one way of importing them that will force the textures to all be readable nor can the user of the app necessarily know before importing whether the texture needs adjusting. It is therefore necessary for the user to have a simple way of adjusting the texture per model, perhaps with a reflectX and reflectY button. Of course this means for each texture adjustment there needs to be a seperate texture cloned from the base texture. The maximum stored materials would be 4, base, reflectX, reflectY, reflectXY.
For example https://playground.babylonjs.com/#KZDXTB#20
However this PG raises a new issue due to LHS v RHS, the imported cube and the created cube are both at position.x = 1.5 but moving in opposite directions and rotate in the opposite directions when both angles of rotation are increasing.
This should cover most but not all situations. It would not cover models such as the wall as it is currently constructed nor I believe merged meshes.
Hope that it shows I have understood more of the issues @ecoin faces and that it puts him and me in more of an agreement about the issues even if not the solutions