MSFS20 MCX Texture attributes relations

[Nordscape]

I am currently using Sketchup as my modelling tool, before importing the model into MCX to adjust textures.

Previously I only added normal maps to the textures which worked ok after adjusting the metallic and roughness values (Metallic was always very shiny if not adjusted).

However I am now experimenting with the use of comp textures and I am struggling to understand the relationship between MCX texture attributes vs. comp textures. Will MCX textures settings (metalness and roughness) override any comp texture values when a comp texture is added? If so, what is the best value to set metalness and roughness to best represent the comp texture "information" so that the textures is shown the way it is meant to be shown.

 

[GaryGB]

Hi Vetle:

If considering pros / cons of 3D model mapped- vs. default terrain / custom TIN / draped- with custom texture image Materials, we must consider this:

https://www.fsdeveloper.com/forum/t...-when-i-set-a-comp-texture.458407/post-923515

The "COMP" texture for a ground material is not the same as the "COMP" for a model or effect. (3D) Models use ORM (occlusion, roughness, metallic) for it's channels.

The SDK describes the ground materials here: https://docs.flightsimulator.com/html/Developer_Mode/Material_Editor/Inspector_Menus.htm#NRM

Ground COMP channels:

Red= Metallic
Green= X value of the Normal (Normal Red channel)
Blue= Roughness
Alpha= Y value of the Normal (Normal Green channel)

NOTE: "Value" = numeric value of the 'Channel Factor' used in making a Composite (aka "COMP") PBR texture Material = PBR COMP 'Factor Value'.

One must distinguish between a PBR "COMP" texture for a ground material versus a PBR "COMP" for a MSFS extended glTF 3D model or Visual Effect.


A note regarding PBR "Metallic" / 'Composite' (aka "COMP") attributes:

MSFS SDK Docs does use a PBR 'Composite' or 'COMP' terminology; but they typically use "Metallic" as a PBR attribute.

https://docs.flightsimulator.com/html/Developer_Mode/Material_Editor/Inspector_Menus.htm#NRM

https://docs.flightsimulator.com/html/Asset_Creation/3DS_Max_Plugin/#material-types

https://docs.flightsimulator.com/html/Introduction/#occlusionr-roughnessg-metallicb

"Occlusion(R) Roughness(G) Metallic(B)
The occlusion-metallic-roughness texture. The metalness values are sampled from the B channel. The roughness values are sampled from the G channel. The occlusion values are sampled from the R channel. These values are linear. If an alpha channel is present (A), it is ignored for occlusion-metallic-roughness calculations."


IIUC, structuring this info for comparison to Dicks post above, we get:

3D Model COMP channels ('RGB'):

Red= Occlusion
Green= Roughness
Blue= Metallic
Alpha= ( Ignored )


Ground COMP channels ('RGBA'):

Red= Metallic
Green= X value of the Normal (Normal Red channel)
Blue= Roughness
Alpha= Y value of the Normal (Normal Green channel)


BTW: Federico Pinotti (aka "mamu") offers some insight that one may use Materialize for 3D models, but not for Ground texture Materials ...here:

https://www.fsdeveloper.com/forum/threads/ground-textures-in-msfs-with-materialize.455792/


In that same thread, Doug (aka "Pyscen" states: "After Materializer, you will need to invert the y-axis on the Normal map".

Google AI Overview states regarding that assertion:

"To invert the Y-axis of a normal map in Materialize, click the "Flip Normal Y" button located in the "Saving Options" section on the right side of the Materialize interface. This will adjust the normal map's orientation so that it is compatible with rendering applications that expect the Y-axis to be flipped, such as Carrara.

https://www.google.com/search?q=mat...ItMbgHggLCBwUzLTEuMcgHJg&sclient=gws-wiz-serp

GaryGB

 

[Nordscape]

Hi Vetle:

If considering pros / cons of 3D model mapped- vs. default terrain / custom TIN / draped- with custom texture image Materials, we must consider this:

https://www.fsdeveloper.com/forum/t...-when-i-set-a-comp-texture.458407/post-923515



NOTE: "Value" = numeric value of the 'Channel Factor' used in making a Composite (aka "COMP") PBR texture Material = PBR COMP 'Factor Value'.

One must distinguish between a PBR "COMP" texture for a ground material versus a PBR "COMP" for a MSFS extended glTF 3D model or Visual Effect.


A note regarding PBR "Metallic" / 'Composite' (aka "COMP") attributes:

MSFS SDK Docs does use a PBR 'Composite' or 'COMP' terminology; but they typically use "Metallic" as a PBR attribute.

https://docs.flightsimulator.com/html/Developer_Mode/Material_Editor/Inspector_Menus.htm#NRM

https://docs.flightsimulator.com/html/Asset_Creation/3DS_Max_Plugin/#material-types

https://docs.flightsimulator.com/html/Introduction/#occlusionr-roughnessg-metallicb

"Occlusion(R) Roughness(G) Metallic(B)
The occlusion-metallic-roughness texture. The metalness values are sampled from the B channel. The roughness values are sampled from the G channel. The occlusion values are sampled from the R channel. These values are linear. If an alpha channel is present (A), it is ignored for occlusion-metallic-roughness calculations."


IIUC, structuring this info for comparison to Dicks post above, we get:

3D Model COMP channels ('RGB'):

Red= Occlusion
Green= Roughness
Blue= Metallic
Alpha= ( Ignored )

"Occlusion(R) Roughness(G) Metallic(B)
The occlusion-metallic-roughness texture. The metalness values are sampled from the B channel. The roughness values are sampled from the G channel. The occlusion values are sampled from the R channel. These values are linear. If an alpha channel is present (A), it is ignored for occlusion-metallic-roughness calculations."

Ground COMP channels ('RGBA'):

Red= Metallic
Green= X value of the Normal (Normal Red channel)
Blue= Roughness
Alpha= Y value of the Normal (Normal Green channel)


BTW: Federico Pinotti (aka "mamu") offers some insight that one may use Materialize for 3D models, but not for Ground texture Materials ...here:

https://www.fsdeveloper.com/forum/threads/ground-textures-in-msfs-with-materialize.455792/

GaryGB

Thank you. I am not talking about comp maps in regards to ground textures, but for use with model texturing. In MCX it is possible to set different values for metalness and roughness, as well as add a comp map. However, it seems like MCX metalness and roughness values still plays a part, even though a comp map is added to the texture. I was under the impression that comp maps had values which present the metalness/roughness correctly, and that further adjustment was not really necessary, but after some testing it seems like comp maps still is dependent on the setting within MCX metalness/roughness, i.e. setting metalness to 1, and roughness to 0,0600 gives a very reflective metal texture, while setting the roughness to 1 is almost non-reflective.

I read somewhere that Blender suggest setting metalness and roughness values to 1 when adding comp maps, so that the maps will be shown the way that they are supposed to look in regards to shinyness, AO and other detailing. But I have yet to find such logic within MCX, hence the question; What are the best values within MCX texture adjustment when using textures with comp maps, to best show the texture the way they are supposed to look?

 

[GaryGB]

I would initially load default 3D models into MCX that use COMP texture Materials, and which render via PBR very well in MSFS.

Then I would write out a Material Template for those example 3D models in MCX' Material Editor to study.

I would next begin testing those MCX Material Template settings by applying them to my own custom PBR texture Materials.

If adjustments are required, they can be applied incrementally via controls in MCX, as numeric "Factor Values" between 0 and 1.

GaryGB

 

[rhumbaflappy]

This isn't a MCX issue. This is how the sim works. You can tweak a comp textures roughness and metallic by assigning a value between 0 and 1. If the comp texture is OK in the sim, then assigning 1 for each would work. Or you can turn the effects down to 0 if needed.

As a side note, Arno, does MCX support using , as a decimal point, or does it adhere to using .

 

[Nordscape]

This isn't a MCX issue. This is how the sim works. You can tweak a comp textures roughness and metallic by assigning a value between 0 and 1. If the comp texture is OK in the sim, then assigning 1 for each would work. Or you can turn the effects down to 0 if needed.

As a side note, Arno, does MCX support using , as a decimal point, or does it adhere to using .

No, not an issue - as in "a problem" -. However still something that is relative to which values are set within MCX.

From what I can see, setting metal and roughness within MCX both to 1 results in no reflection within the sim other than the sun lighting up the surface. Many downloaded freeware metal textures are defaulted within mcx with a metalness factor of 0,09999...8 which gives an extremely unrealistic reflective surface within the sim. I therefore need to change these settings to something more natural. Currently setting the Metalness factor to 1, and roughness to between 0,9 -0,7 gives a reflective surface while not being too aggressive.

So from what I understand is that MCX metalness and roughness values directly affect whatever comp maps are added to the texture. So it is not working like Blender where you set a value of 1 for both when using comp maps.

 

[GaryGB]

Hello:

I'll bet you "Dollars To Donuts" < no, I'm not a Police Officer > ...that the required Decimal Point is a ( . = period) character.

Historically that has been the case in all prior versions of FS, and most North American software; try it and see.

It is best for FS development purposes to set the required Decimal Point to a ( . = period) character in Windows.

If you are not familiar with how to do so, we can post info on that very brief procedure.

And historically, unanticipated surprises occur for FS Developers if they do not make that change when working in the FS SDK.

If the computer is otherwise used for work in European software that utilizes the Decimal Point as a ( , = comma) character, set it to that as needed after finishing work sessions involving FS SDK and any North American sourced software.

GaryGB

 

[Nordscape]

Hello:

I'll bet you "Dollars To Donuts" < no, I'm not a Police Officer > ...that the required Decimal Point is a ( . = period) character.

Historically that has been the case in all prior versions of FS, and most North American software; try it and see.

It is best for FS development purposes to set the required Decimal Point to a ( . = period) character in Windows.

If you are not familiar with how to do so, we can post info on that very brief procedure.

And historically, unanticipated surprises occur for FS Developers if they do not make that change when working in the FS SDK.

If the computer is otherwise used for work in European software that utilizes the Decimal Point as a ( , = comma) character, set it to that as needed after finishing work sessions involving FS SDK and any North American sourced software.

GaryGB

Please excuse me if I misunderstand, but MCX uses comma with the [correct eek:)]"," definition. I am not discussing any thing adjusted within msfs.

 

[GaryGB]

Please excuse me if I misunderstand, but MCX uses comma with the [correct eek:)]"," definition. I am not discussing any thing adjusted within MSFS.

Sorry Vetle, but I am concerned that something may be getting lost in translation; I did not understand your use of emoticons that rendered above.

When working with MCX and the various Microsoft / 3rd party component software code libraries it utilizes to operate, and FS development utilities from North America, and MSFS SDK, it is best to globally- within Windows Operating System- change the Decimal character from a Comma to a Period.

If MCX made itself tolerant of the comma, it does not change requirements of other software that FS development utilizes to "go do that voodoo that it does so well".

Inevitably, problems may arise if one does not make this change.

https://www.fsdeveloper.com/forum/threads/modelconverterx-help.19009/


Of course, it may just be that you have already made this change, and our communication is, as cited above, getting lost in translation.

For better mutual understanding at this time, please tell us:

Do you- or do you not- have the Windows system-wide Decimal Character set to a Period ?


Thanks for helping us to help you.

GaryGB

 

[Nordscape]

Sorry Vetle, but I am concerned that something may be getting lost in translation; I did not understand your use of emoticons that rendered above.

No, I'm sorry. I was trying to make a joke about the US vs. rest of the world in regards to units and measurements. Anyway...

When working with MCX and the various Microsoft / 3rd party component software code libraries it utilizes to operate, and FS development utilities from North America, and MSFS SDK, it is best to globally- within Windows Operating System- change the Decimal character from a Comma to a Period.

If MCX made itself tolerant of the comma, it does not change requirements of other software that FS development utilizes to "go do that voodoo that it does so well".

Inevitably, problems may arise if one does not make this change.

https://www.fsdeveloper.com/forum/threads/modelconverterx-help.19009/


Of course, it may just be that you have already made this change, and our communication is, as cited above, getting lost in translation.

For better mutual understanding at this time, please tell us:

Do you- or do you not- have the Windows system-wide Decimal Character set to a Period ?

...I do not have that, no. Is that still relevant in 2025 you say? That article you refer to is 15 years old?

 

[GaryGB]

That was a quick link of a thread that is older; the point was, FS Developers must always set the Decimal Character to Period.

Please set it to that when doing any work with FS SDK's, Sketchup, FS utilities etc., and any North American software.

Assuming you are running Windows 11:

https://answers.microsoft.com/en-us...cimal-in/698cbcae-0496-44b0-8cdc-69eb4de3bdeb

GaryGB

 

[arno]

As a side note, Arno, does MCX support using , as a decimal point, or does it adhere to using .

In the GUI MCX will use what the windows setting is. But everybody who works for FSX or P3D has that set to dot of course since XtoMdl does not work with comma.

For MSFS using comma should work, on export MCX should make a glTF with the right format.

 

[Nordscape]

In the GUI MCX will use what the windows setting is. But everybody who works for FSX or P3D has that set to dot of course since XtoMdl does not work with comma.

For MSFS using comma should work, on export MCX should make a glTF with the right format.

Thanks for clarifying. I will adjust and report back.