As far as I can tell, the engine completely ignores mutiple UVs, even though the exporter is capable of exporting them. I've been looking into the GTLF format and how it defines everything. There's a part where the actual mesh is defined:
JSON:
"attributes" : {
"POSITION" : 0,
"NORMAL" : 1,
"TEXCOORD_0" : 2,
},
The names are a semantic for the type of point; POSITION is the 3D position in space, NORMAL is the vertex normal (and used as the basis for how the normal map re-aligns the normals) and TEXCOORD_0 is the 2D UVs. The points themselves are held in buffers in the .bin file, the numbers after the semantic names are the buffer indices - where to find the points.
If you export a model with more than one set of UVs, you get something like this:
JSON:
"attributes" : {
"POSITION" : 0,
"NORMAL" : 1,
"TEXCOORD_0" : 2,
"TEXCOORD_1" : 3,
},
So you can see the extra UVs are defined, and it has incremented the buffer index, indicating they're held in a separate buffer in the .bin file.
In the Material definitions, for each material there is a section like:
JSON:
"baseColorTexture" : {
"index" : 1,
"texCoord" : 0
},
Looking at the .gltf documentation from Khronos, "index" points to which image file to use and the "texCoord" field points to which TEXCOORD buffer to use for the UVs.
I created a simple cube object with a red and blue texture. I made two sets of UVs, one mapped only to the red side and one mapped only to the blue side. A basic export had the cube red in the sim; it was using the first set of UVs, as you'd expect.
However, changing "texCoord" : 0 to "texCoord" : 1 in the material definitions had no effect.
Just to check, I changed the buffer indices around on the TEXCOORD_0 and TEXCOORD_1 in the Mesh definitions, so TEXCOORD_0 was now pointing at buffer 3 and vice-versa. And hey-presto! The cube turned blue in the sim, so we know the buffer exists in the object and can be read by the game engine.
So, to recap, the exporter CAN export multiple UVs. The object files DO contain the set of points for both sets of UVs. But Asobo have their game engine completely ignore the setting chooses which one a texture is supposed to use, it's hardcoded to always use the first one.
I don't think it's going to be possible to use multiple UVs without a patch. I suppose we could try a feature request on the FS2020 support desk?
, I've used it in my own game engines.
but it would make my life so much easier if we could do it
