Metallic Textures not showing in MSFS

[mrauh]

Hi all,

I'm trying to export an object with a PBR-texture to MSFS. The gltf looks ok in Windows 3d Viewer but when I place it in MSFS the roughness and metallic information is lost. Also when I export the project the albedo and normal textures are exported but not the comp textures. I have included the object in question as well as the textures and screenshots of the MCX material dialogue, the object in 3d Viewer and in MSFS.

Any help is greatly appreciated.

Matt

 

[rhumbaflappy]

MSFS 2020 or MSFS 2024?

 

[arno]

And what do you export the object to when the comp texture is not saved? You mean export as a scenery package?

 

[mrauh]

FS2020

MSFS 2020 or MSFS 2024?

And what do you export the object to when the comp texture is not saved? You mean export as a scenery package?

Yes, that's what I meant. But the texture already doesn't show when I add the object in the scenery editor.

 

[arno]

FS2020



Yes, that's what I meant. But the texture already doesn't show when I add the object in the scenery editor.

I just loaded the object in MCX and exported it to a MSFS 2020 scenery package, and all 3 textures are saved in the texture folder. So it seems there is no bug there.

Still need to check what is with the metallic.

 

[arno]

I had a look at the comp texture as well now. Is the problem not that you use only black and white for the roughness and metallic? When you set the metallic to 255, you have a roughness of 0. I don't think that's the best combination to get a realistic effect (but I'm no texture artist).

 

[rhumbaflappy]

The MCX imported-exported model shows an error in the FS2020 compiler regarding the packing of the metallic and roughness texture, and as a result, the textures are not compiled, and their reference in the sim is gone.
Importing-exporting the gltf in blender compiles without error, and the material and textures are fine in the sim.

There's a problem in MCX I think.

 

[rhumbaflappy]

I think I found the problem.

  "materials": [
    {
      "name": "Test_Box",
            "occlusionTexture":{
                "index":1
            },
      "pbrMetallicRoughness": {
        "baseColorFactor": [
          1.0,
          1.0,
          1.0,
          1.0
        ],
        "roughnessFactor": 1.0,
        "metallicFactor": 1.0,
        "baseColorTexture": {
          "index": 0
        },
        "metallicRoughnessTexture": {
          "index": 1
        }
      },
      "emissiveFactor": [
        0.0,
        0.0,
        0.0
      ],
      "normalTexture": {
        "index": 2
      },
      "extensions": {
        "ASOBO_material_day_night_switch": {
          "enabled": true
        }
      }
    }
  ],

To the glTF, I added :

"occlusionTexture":{
"index":1
},

Maybe this is something new to the in-sim compiler? But you need to tell the sim where the occlusion texture exists.

 

[rhumbaflappy]

But I see MCX does add the occlusion line in a regular 2020 model. So why isn't it in the provided glTF? At any rate, MCX seems OK. The model's glTF was a problem.

 

[arno]

Let me check if MCX writes that correctly in all variants of the glTF it supports.

 

[mrauh]

Thanks for taking care of this. In the meantime I've checked if a gltf-file exported for FS2024 would work. I could actually place it in FS2020 but the Comp-Texture wasn't displayed either. I also found out that I exported the comp-texture as 8bit from Substance Painter but exporting it as 16bit didn't make a difference.
Finally I wanted to try using a version of MCX that I had used for scenery last year. But for some reason that didn't start. One those days when staying in bed might have been the better option... ;-)

 

[mrauh]

I just gave it a shot in MCX version 1.6.0.0 and the box displayed okay in FS2020.

 

[arno]

But I see MCX does add the occlusion line in a regular 2020 model. So why isn't it in the provided glTF? At any rate, MCX seems OK. The model's glTF was a problem.

I have just checked my code, but MCX does not always add the occlusionTexture. This is due to a change I made for MSFS 2024, where they is a specific occlusion texture that can be specified. So I guess for MSFS 2020 I should still add this line for the comp texture. For MSFS 2024 I need to test how it works with the separate occlusion texture.

 

[ronh]

The comp texture in 2024 is the same as the comp in 2020. There is a new texture/slot for a UV2 that is for a second ambient occlusion texture.

Here is an example blend file with packed textures (blender 4.2 exporter for SU4) and gltf/bin

It produces a gltf with an added ASOBO extension extraOcclusionTexture

Note the added texCoord_0 and _1 (for UV1 and Uv2) and Color_0 on the mesh - ASOBO wants a "white" Vertex color for 2024

 

[arno]

Thanks Ron, let me check that sample to get the msfs 2024 things right.

 

[arno]

Thanks Ron, that sample really helped. When I implemented the MSFS 2024 material options a while ago, the documentation was not so clear yet for the extraOcclusionTexture, so I mixed it up with the occlusionTexture. That caused this issue. In the next development release it will be all fixed.

 

[ronh]

Please note I feel the exporter 5.4.2 from ASOBO for SU4 beta is not working correctly - so the gltf file produced for the UV2 AO will not work.

discussion on dev hub

https://devsupport.flightsimulator.com/t/blender-exporter-doesnt-export-ao-uv2/15271/9

the fix to the ASOBO code is there. very simple - remove the 1: from index square brackets.

EDIT: The ASOBO export 3.3.1 i believe worked as expected

 

[rhumbaflappy]

SU3 uses the asobo addon version 4.3.5 for 2024. I make a scenery object. In Blender v3.6.22 AO doesn't work. The COMP AO gets made into a scaling factor for the Occlusion UV2 (?), and then mixed somehow with the Albedo. When the glTF is made, it just ignores the nonsense and uses straight albedo. The AO texture doesn't get used at all.

I can make a non-MSFS glTF that shows AO just fine, so it's not as if the sim is the problem, as far as I can tell. So I would hold off making changes to MCX until Asobo figures out what they are doing with blender. I don't know if the same problem exists for 3dsMax.

 

[arno]

I have just released the fix that fixed the missing occlusionTexture attribute that gave the warning. I did update the extra occlusion texture in line with the sample Ron provided.

If that needs to change again later on I will do that. It's quite hard to follow all those small changes they are making to the glTF extensions. So there might be more areas where MCX is a bit lagging.

 

[rhumbaflappy]

SU3 uses the asobo addon version 4.3.5 for 2024. I make a scenery object. In Blender v3.6.22 AO doesn't work. The COMP AO gets made into a scaling factor for the Occlusion UV2 (?), and then mixed somehow with the Albedo. When the glTF is made, it just ignores the nonsense and uses straight albedo. The AO texture doesn't get used at all.

I can make a non-MSFS glTF that shows AO just fine, so it's not as if the sim is the problem, as far as I can tell. So I would hold off making changes to MCX until Asobo figures out what they are doing with blender. I don't know if the same problem exists for 3dsMax.

I replying to myself
The SU3 Blender addon does work OK for adding an extra Occlusion texture to the material. Senior moment? Maybe. AO_Test_2.zip

The COMP contains the texture AO. Tiled textures like rocks or gravel will have the AO in the red channel. But for the object, it can have it's own AO in addition to the COMP. MSFS adds visual AO to objects in the sim automatically. But you can add extra AO to objects in each material with the Occlusion texture slot in MSFS2024. In blender, you need to select the object, make a new UV. Make sure the original UV is named UV1 and the new UV is named UV2. And make sure the UV2 has it's own UV mapping in the UV Editor. Then bake the AO to the UV2's texture (Occlusion slot).

This seems a bit complicated, but it does work.