MSFS20 ModelConverterX Textures have become darker

[jkustom56]

Hello, This is my first post.
I have been making my own scenery objects for about 7 years. My method is to build Buildings such as hangars
using TinkerCad, converting the STL file with MCX into .dae files, than painting/texturing in SketchUp, exporting the .KMZ file back to MCX to place
them into my MSFS object library. Before MSFS I used this method in FSX. A few months ago I noticed a change in the way my textures looked
after they were exported into MSFS. Before, lite colors such a lite yellow came though the way they looked in the MCX window. Whites looked white
lite blue or yellow look that way. But now white surfaces come out grayish and light yellow looks darker and grayish.
In my Pic there are 2 examples of the same
building. "A" was exported a year ago and "B" was put thorough MCX this week the same way as "A". Other Pics include the actual hangar colors of Edwards AFB.
I have tried everything I could think of and listened to tutorials by Arno
and others but I can't fix the problem. It has takin some of the fun out of making scenery. BTW Please don't recommend Blender. I cant figure it out. Thanks I have been a member for a while. JK

 

[arno]

Hi,

Would you have the glTF files of A and B? Then I could compare them to see where the difference is.

 

[jkustom56]

Hi Arno! Thank you for everything you do for all of us! Hope I sent the files in a manner which is useful. I'm also sending other pics to demonstrate the problem.
thanks again, John

 

[=rk=]

Hi, just a quick observation here, I see you are using Sketchup and I see a picture with the annotation, "this should be this," with the arrows pointing at what appears to be different projections of a texture of skylights. If so, this is different from the shading issue and thank you for raising it, I have been noticing it for a long time and had thought it was a consequence of of the MSFS render. Currently there is no real black.

Back to the skylights, you can encounter an issue with texture projection which Sketchup is vulnerable to, for which Arno has already devised a correction procedure that is available in the development release of MCX. What seems a little odd, is that both models should have the same projection and both models should be affected similarly, the UV projection restriction is a consequence of the Asobo software and not MCX. I may have gotten this wrong, the Sketchup model appears to reflect the appearance of the "modern" model and not the "legacy" one, making it more likely the change in skylights is an edit.

 

[jkustom56]

Hi =rk=,
The lines were meant to just point to the models in general. I want the model on the left to be the same color as the one on the right. This scenery is for Edwards AFB. Almost all the buildings
there, are the colors you see in the model on the right. Over the last year I have been working to recreate every hangar and building there. Unfortunately about 2/3 of the
way into this project this strange problem came up. So the rest of the buildings don't look quite correct. It is quite posable the problem is with MSFS. But I also wonder if I changed something in
my settings or procedures in MCX. Thank you for your input!

 

[=rk=]

All good about texture projections. The color issue seems to be a matter of "saturation" and the fact you've provided Arno an example of the richer colors makes me optimistic we will soon have true black in our color pallets and not just dark gray.

 

[jkustom56]

 

[arno]

I have been a bit busy in the last days, but I'll check the same soon.

 

[arno]

Hi,

When I compare the two glTF files the main difference I see is that A has a metallic value of 0, while B has a metallic value of 1. The default value of the metallic value has changed from 0 to 1 in August 2021, so that is indeed after you made the export A.

I guess it is hard to say what the best default value for metallic would be, as you never know what kind of material an object is made from. Maybe a default value of 0.5 would even be better. Any thoughts on this are welcome.

I think if you change the metallic value of the object it will look like before again.

 

[jkustom56]

Thank You So Much Arno! I love MCX thank for that too. I'm going to try that and ill let you know.

 

[=rk=]

The PBR channels run from zero to 1, so 1 is full metallic. With the default settings, this does not show at all because 1 is also full roughness. FYI the SDK prefers numeric PBR over material driven to reduce load and this a a convention I try to follow. I almost never use zero metallic, I do use zero roughness for full chrome and also glass. Mathematically perfect glass, with a hefty dose of metal, can really kick off some sun flashes.

In other news, Arno, it appears I may have encountered the attached object duplication bug, again. This model has 16 attach points and 79 additional lights I did not add. The last time I edited the model, was during the comp/normal texture event and I am just getting back to it now, because I was checking night lighting and noticed how bright it was.

 

[jkustom56]

Hi,

When I compare the two glTF files the main difference I see is that A has a metallic value of 0, while B has a metallic value of 1. The default value of the metallic value has changed from 0 to 1 in August 2021, so that is indeed after you made the export A.

I guess it is hard to say what the best default value for metallic would be, as you never know what kind of material an object is made from. Maybe a default value of 0.5 would even be better. Any thoughts on this are welcome.

I think if you change the metallic value of the object it will look like before again.

 

[jkustom56]

THAT WAS IT!!! Im so happy!! Thank You!!!

 

[jkustom56]

The PBR channels run from zero to 1, so 1 is full metallic. With the default settings, this does not show at all because 1 is also full roughness. FYI the SDK prefers numeric PBR over material driven to reduce load and this a a convention I try to follow. I almost never use zero metallic, I do use zero roughness for full chrome and also glass. Mathematically perfect glass, with a hefty dose of metal, can really kick off some sun flashes.

In other news, Arno, it appears I may have encountered the attached object duplication bug, again. This model has 16 attach points and 79 additional lights I did not add. The last time I edited the model, was during the comp/normal texture event and I am just getting back to it now, because I was checking night lighting and noticed how bright it was.

View attachment 86598

I changed Metallic value to .5 that made a sharp difference! So it worked Thank you as well, Rick!!!

 

[jkustom56]

I may try A Metallic value of "0" as well too see if there is any measure difference.

 

[arno]

The PBR channels run from zero to 1, so 1 is full metallic. With the default settings, this does not show at all because 1 is also full roughness. FYI the SDK prefers numeric PBR over material driven to reduce load and this a a convention I try to follow. I almost never use zero metallic, I do use zero roughness for full chrome and also glass. Mathematically perfect glass, with a hefty dose of metal, can really kick off some sun flashes.

Correct, the default value is fully metallic now. If any of you have a better idea for a default value let me know. Maybe in the middle (0.5) would be best when you don't know if a material is metallic or not.

The default value for the Roughness is 1 as well indeed (or actually internally MCX stores Smoothness as P3D uses and that has a default value of 0). Maybe a better default value for this would be in between (0.5) as well.

I don't know what you mean with "the SDK prefers numeric PBR over material driven". The metallic and roughness settings are also part of the material. In this case we are talking about the values in the material that apply to the entire polygon the material uses, not about the values that can be set from the comp texture.

In other news, Arno, it appears I may have encountered the attached object duplication bug, again. This model has 16 attach points and 79 additional lights I did not add. The last time I edited the model, was during the comp/normal texture event and I am just getting back to it now, because I was checking night lighting and noticed how bright it was.

I thought that was fixed, but I will double check to be sure. So you have a model with LODs added an attachpoint and on loading the MSFS model again they where duplicated?

 

[=rk=]

Each light has 5 duplicates, which implies I'd edited the model 5 times after compiling it into the modellib.

I don't know what you mean with "the SDK prefers numeric PBR over material driven". The metallic and roughness settings are also part of the material. In this case we are talking about the values in the material that apply to the entire polygon the material uses, not about the values that can be set from the comp texture.

I tried to use ChatGPT to find the exact link and decided a computed apology was entertaining enough. I sincerely hope I am not the only one that finds it humorous that a computer must mime contrition, to be understood.

I apologize for the confusion in my previous response, as there is no specific passage with that exact wording in the MSFS SDK documentation. However, the documentation does provide guidance on the use of numeric PBR values versus texture maps in various places, such as the "Creating Materials" section of the SDK.

For example, in the "Creating Materials" section, under the "PBR Materials" subsection, the documentation states:

"While PBR textures can be used to define various material parameters, it is recommended that you use numeric values in the material definition file wherever possible. Numeric values can be tuned for each material and are not limited by the quality or resolution of a texture. When using textures, make sure that you choose high-quality textures with appropriate resolution and use them judiciously."

I had been mistaken about the reason to use numeric PBR. I had thought is was to reduce texture/material load, this says it is to increase fidelity.

 

[jkustom56]

I Have been working with a PBR metallic value of .3 and it seems to work out good for me. Such a big improvement!! Thanks again to you both!!

 

[arno]

Hi Rick,

I had a look at the attachpoints. I can't reproduce the issue. I made a glTF file with LODs and attachpoints and when I import/export the object multiple times I don't get any additional attachpoints. So what's the exact workflow you are using, so that I can try to reproduce it?

 

[=rk=]

The workflow is somewhat contrived, apologies, because the model is a hangar with detailed interior. So rather then just culling random polygons with the LOD creator, I decided to import an earlier version, with no interior. That worked great, full exterior detail with a hollow core and even if I had placed lights on that earlier model, I hadn't, bringing that model into the high detail one, that also had not had lights attached yet, would only double the number of attachments. After that, I may have edited PBR settings, possibly changed LOD values or other setting adjustments to the model and recompiled it.

However, after getting the lower LOD model imported, I did not physically replace, or swap out the model again, which is the usual way to multiply attached lights.