Textures are wavy after building the package

[erasam]

After I build my aircraft the fuselage texture is shown wavy, even if in Blender it is shown perfectly (as well as in ModelConvertX where no texture distortion is reported)

I checked the UV coordinates of the built package (reimported in Blender) and some of them have been shifted even if to my knowledge the 16bit Float precision should keep up to the 4 decimal digit

I'm stuck now as I tried more or less everything to fix it

 

[arno]

Hi,

The half precision looses accuracy very quickly, so if you texture coordinate is not in the range between 0 and 1, you have a lot less decimals for your coordinate. Are you sure they are not tiled or shifted so that they are not in the 0 to 1 range.

 

[erasam]

Thanks for the reply Arno. As you can see from the blender screenshots the UV coordinates are all between 0 and 1

I really don't know how to avoid it: I tried resizing (less or more) the texture, remeshing the mesh, changing the material, shifting the UV, rebuilding the UV, applying a different texture, creating seams, decimating the vertices, and so on: nothing worked

Those textures are always wavy

 

[arno]

Did you try to look at the texture coordinates in the MCX hierarchy editor to double check the values are what you expect?

 

[erasam]

They are correct, actually the exported gltf looks fine in any 3D viewer, moreover I re-imported it and it's fine in blender as well. Just the gltf created by the package builder has that issue as shown if I re-import it in blender
I can attach the blender file and the texture files for who is interested to try it

 

[=rk=]

They are correct, actually the exported gltf looks fine in any 3D viewer, moreover I re-imported it and it's fine in blender as well.

Yes, I tried processing it using native 3ds Max tools. 3ds Max can quadify mesh and retriangulate, I ran your mesh through Mesh Cleaner, Pro Optimize, Quadrify, TurboSmooth and finally Reptology to decimate it. That should have remapped anything UV related but the projection looked the same, it suggests the model is incapable of storing this information correctly. Perhaps this model was made with a different gltf schema? Everything in it seems fine, until it has to represent Asobo gltf.

 

[erasam]

Yes, I tried processing it using native 3ds Max tools. 3ds Max can quadify mesh and retriangulate, I ran your mesh through Mesh Cleaner, Pro Optimize, Quadrify, TurboSmooth and finally Reptology to decimate it. That should have remapped anything UV related but the projection looked the same, it suggests the model is incapable of storing this information correctly. Perhaps this model was made with a different gltf schema? Everything in it seems fine, until it has to represent Asobo gltf.

Thanks a lot for trying
Actually that's completely absurd for me: how is it possible that a "model is incapable of storing this information correctly" ? It's just a mesh as any other... Moreover when I have remeshed it using Quad Remesher a new mesh is actually created from the original one and also that one is shown wavy. I tried loading the original source file (in 3DS format) then publishing it to the sim with the same annoying result
The gltf the package builder creates just is wrong because there is a bug somewhere: that's it
As I have checked loading in Blender the gltf produced by the package builder some (not all) UV coordinates have been shifted (at the 4th decimal digit level) making the texture wavy

 

[=rk=]

Actually that's completely absurd for me: how is it possible that a "model is incapable of storing this information correctly" ? It's just a mesh as any other...

So you are saying that the original model was indeed gltf? I think it bears mentioning that gltf is an open source format. Asobo has made numerous edits or custom implementations of the format. We've all seen this passage from the SDK so I think it's ok to not link it:

When you create a package for Microsoft Flight Simulator, models are processed by the package tool into compatible gLTF files that are optimised for use within the simulator. Part of this optimisation process involves storing the UV data as 2-byte floating point numbers, instead of regular floats, to save on memory usage.

What we tend to overlook is that no other implementation of gltf uses this floating point workaround. Anyway, when the Babylon exporter writes the gltf, it's doing so from a different format, like .max or .blend. This is just a guess, but it seems to jibe with what we've been seeing here and at the Discord server. I'm not saying it is the answer either, many gltf files convert just fine, but maybe your particular flavor of gltf has a conflicting customization or something. I bet if you exactly copied the geometry and tried that, it would work.

 

[erasam]

I have checked a specific uv point coordinates that is wavy after the package builder runs
In the original file in blender (created natively) the coordinates are X=0.6987 and Y=0.118 (to be sure I manually forced to value to the 4th digit cleaning the remaining decimals)
In the GLTF created from the exporter (re-imported in Blender) the same uv point coordinates are untouched (as expected) and the texture looks perfect
In the GLTF created by the package builder (re-imported in Blender) the same uv point coordinates are X=0.69873 and Y=0.118164 and the texture looks wavy (as in the sim): the small difference in the Y is enough to have it distrorted

I'm not a mathematician but I don't call this result "rounding" !

P.S. Moreover just to be sure before exporting the mesh from Blender I triangulated it to have the exact same topology

 

[=rk=]

Whelp we're mostly just speculating here and good dive on the specifics, but what rounding refers to is the number of decimal places and not necessarily to zero. Say we have a value that is 0.6666666 and that is too many decimal places, so the engine will round it to 0.666667. I am no mathematician either, but I think the thing that gets rounded is the result of a conversion algorithm and not the actual coordinates. Ok so you "round" to 0.118000 and then the algorithm crunches it to 1.2345E1 or something and then calculates it back to 0.11816396417, obviously I am making up numbers here, but that last one rounds out to 0.118164.

Something I have not seen addressed in any discussion about this, is regarding your Blender set up. I've seen threads for issues due to switching Blender versions in the middle of a project, or mismatching exporters to versions, it's fairly common and if it's not something you're on top of, it probably warrants a check, the result is usually odd unexplainable errors, is why I mention it.

 

[arno]

I don't think you should look at importing the glTF file back into Blender or something like that. The problem will only occur after running it through the packager tool, as that is when the UV coordinates are set to half precision. So you probably want to check the output of the packager tool and see what kind of UV coordinates you find in there.