1.18.13.0 Pink Textures

[MSFS 2020] Questions & Community Discussions Aircraft
21

Hi Sylvain, I forgot this ones was modified after we built it. This was due to
troubleshooting if the textures were being converted incorrectly. As for the
textures, most of our airport shares the same textures on buildings and
several buildings use the same texture multiple times. Prior to SU5 this was
not an issue, just something that appeared with the latest version. I have
attached a photo of something that one of our devs experienced today. the roof
uses the same texture the whole way across, same material, same properties
etc. 3/4 Panels are working, 4th experiences the issue we’re facing at ypad.
You can also see the walls being the same, Right and left sides, visible in
the photo are the same material and texture, one loads, other doesn’t.

1797×1136 600 KB
Another thing we found testing
a project for another dev, is that since the last update if two textures are
name the same in different packages, the sim seems to select whichever it
wants. Photo Below, this is Aldinga by AUScene. Uses a texture called
Glass.PNG.DDS in the final build. Fly Tampa’s YSSY also has the same named
texture (Glass.PNG.DDS) , causing the sim to do this.
1125×633 123 KB
Sim has pulled it at random
meaning that the project doesn’t appear to be constrained to it’s own
resources anymore. Our building at YPAD the Vickers Vimy Museum is the only
place that specific brick texture is used, it’s only used once on the building
and all has the same texture, (Located at the end of the terminal) this also
broke after the latest update. I must add, that YPAD worked after the update.
We noticed the issue after doing a clean build after doing some apron edits.
Our old package is still fine. All textures that are in the build are in the
texture folder and being exported to the final build folder, so it can’t be
missing. Thankyou for your time in looking into this, your suggestion hasn’t
worked as changing the texture and material to a new one not used anywhere
else had the same result. P.S I posted the download two days ago for
moderators only, didn’t appear that you could see it. :slight_smile:

22

Hi Sylvain, I have now created a sample project with the result below, as you
can see 2 textures load perfect while 1 doesn’t. If I convert the texture
manually to .DDS and create the Json file manually it loads fine…

1920×1080 690 KB
This is using 3ds max 2020, SDK
0.14 and MSFS 1.18.14.0 I will upload the full package shortly. Regards, Raul

23

That’s not what the bgl analysis tells me. Looking for the the usage of the
BRICK_WALL_COMP.PNG.DDS texture that also triggers the VFS Bitmap Loader
warning, I found at least 5 materials using it: - BRICKS BLUE GREY :
Metal_Roughness_AO & Decal channel - RED BRICK 2 : Metal_Roughness_AO -
BRICK WALLS : Metal_Roughness_AO - BRICKS : Metal_Roughness_AO - BRICK :
Metal_Roughness_AO The main issue here is with the texture being used for both
the M_R_AO and Decal channel, causing the problem I explained above. If this
layout doesn’t match what you configured in your scenery, this might be a bug
at the BGL generation step but I’ll need your source package to investigate
further. Can you try creating a private comment and tag me using @ ? I am able
to see other private comments so I’m surprised I missed yours.

24

Your method has fixed some of our buildings, sadly not all. but certainly
isn’t an effective workflow. On another note @FlyingRaccoon, Replied privately
if you can see it. Also since the last update we’re not able to update the
GLTF and see it almost instantly. @Simbol have you also had that issue?

25

Hi m8, Tell me about… I always hit build package, and everything reloads
automatically for me. The only issue is the pink textures, which will re-
appear if I clean the package… I sent Sylvain an example yesterday, hopefully
this will help to track down the causes and get it resolved. Best, S.

26

Hi @FlyingRaccoon , I am getting a notification about a response, but cannot
see it? could it be due to permissions on the response? odd. Regards, Simbol

27

Sim has pulled it at random meaning that the project doesn’t appear to be
constrained to it’s own resources anymore. I’ve found a bug because of this,
big oops. This will be fixed in a future update (but requires some testing
on our end first). This only bug only applies to textures, by the way,
nothing else.

28

Hello @Simbol Checking your package, I found what
the issue is. The game engine gltf parser now expects paths to be normalized.
As you’re using a standard PBR max material and not an FSMaterial, the
exporter is not normalizing the paths (which used to be ok). We will fix the
way standatd max pbr materials are handled in the exporter BUT , this
gives me the opportunity to remind people that even if the exporter is
tolerant, we strongly advise you to use FSMaterials. This is the type of
materials we use internally, the type we test on a regular base, and in the
end, the material with the least chance of regressions. The same applies for
GLTF vs MDL, ArtProj vs ModelLib, etc… Replacing your materials with
FSMaterials with solve your issue

1487×1003 576 KB
Regards, Sylvain

29

Hi Sylvain, This is correct, however there are certain occasions or
circumstances were we need to use PBR materials, even if it is for a
temporally period of time. For example:

  • When converting 3D objects from another engine to MSFS, the object will come with PBR or standard materials, sometimes hundreds of these and we need to check and convert slowly textures, settings, etc. ensuring they are moving swiftly to FSmaterials, so we need to export to the engine and check how things looks, go back and convert the part to FSMaterial, compare and continue. This process can takes time since no 3D objects we need to convert will come with FSmaterials by default, so being able to see how things look is very important for 3rd party developers.
  • There are some things that cannot be achieved via the FSmaterials at the moment, but that are totally doable with PBR materials, so while the video game shaders get upgraded or such things are implemented directly via the FSmaterials material, we can use PBR materials as a stop gap.
  • PBR materials allows us to control certain settings (for example reflection profiles among others, etc) in a more controlled way… but unfortunately when we switch from PBR material to FSmaterials without being able to compare we can lose some quality in the process without noticing it. By allowing us to use both materials, we can start have a more relaxed process to convert texture maps, implement secondary details, etc. and still being able to see the differences inside the game from Material A vs Material B to find the right spot we are looking for.
  • We can’t share visually FSMaterial bitmap textures between or other FSMaterials, so the workflow for a large project (specially at beginning when we are implementing new textures) can become very hard since we cannot see what bimaps textures we are using unless we double click the FSmaterial to see inside. In the other hand, PBR Materials show the bitmaps with the channels very visually and easy, allowing us to organise things very well. When we finish everything then we can start the process to move everything to FSmaterial, etc.

Lots of people using blender are also using a similar workflow as 3ds PBR
materials for their material layout, I wonder if they are also getting pink
textures due to the same path normalisation issue. I think it would be good to
retain the compatibility between PBR, Standard + FSMaterial since it will
helps us to be able to work much better, mostly during conversion process from
A to B, and as you can appreciate most 3D artist / freelancers are
specifically familiar with 3DS default materials, therefore we often receive
projects using these materials and we need to check things inside the video
game while we convert to the required preferred format. Many thanks once again
to you and the Asobo team for the time being spend to replicate this issue and
for taking the time and consideration to implement a fix. Kind Regards, Simbol

30

I use blender, we get pink textures too. hopefully there will be an official
plugin for it soon enough.

31

About your second and third points, do you mean those things you can’t do with
FSMaterials still get exported in the gltf and have an impact on the rendering
in game? For instance, does tweaking the reflection profiles on a standard PBR
Material have an influence in game? As a workaround, while waiting for the fix
to be available and if you don’t want to move to FSMaterials, you can also
edit the generated GLTF and normalize paths manually.

32

Yes, they impact the rendering engine and I can make things look much better
sometimes… Most of the time to get the same look under FSmaterials I have to
edit textures and test many times, where with PBR materials we can adjust
things on the fly via the material parameters. Blender saves directly to gILT,
and the rendering engine game also uses all sorts of special settings pushed
by the blender materials property. Will try your suggestion to edit the paths,
thanks for this tip. Regards, Simbol

33

Hi Simbol. Well that shouldn’t be the case as all gltf material parameters are
supposed to be tweakable through the FSMaterial. Can you give us examples of
parameters you use and how it affects the end result? We will have a look and
improve the FSMaterial if needed. Regards, Sylvain

34

,

1869×1121 890 KB
I have the same problem. The
textures are set correctly in blender but the result in MSFS is not the same.
A bug fix is highly appreciated. Regards, Marco

35

Is there an sdk update planned to fix the texture problem? I did not get any
feedback since the last post.

36

I’m not aware of any remaining issues. Could you verify the exported glTF
contains image uris of the form “textureName.png” and not, for example,
“texture/textureName.png”?

37

Also, can you confirm you’re using FS Materials?

38

Hi Sylvain, I just retried with the test packaged I supplied earlier on this
topic, latest SDK 15.0, re-exported and the problem persist… got pink
textures…

1864×759 566 KB
The sample I
supplied earlier is not using FSmaterials indeed, however you guys mentioned
this was going to be fixed with SU6 so when this occurs the textures would be
exported properly as per prior SU5 when this functionality used to work fine.
This picture shows how the texture was actually exported fine from 3DS:
1271×924 82.2 KB
But upon compiling inside MSFS,
the texture is never copied from the package sources to the package
destination as it should with the extension .DDS:
818×917 47.4 KB
Causing the pink texture showed
above. Hope this helps to troubleshot. Regards, Simbol

39

Does the exported gltf model contain image URIs with
“texture/someTexture.ext”, or just “sometexture.ext” ?

40

Hi there, I just checked, below is the result of what is inside the exported
gltf file, the failing texture is marked in bold. “images”:[{“uri”:“fsr-b-
OxidatedMetalDetail.png”},{“uri”:“fsr-b-beaten-up-metal1-Normal-
dx.png”},{“uri”:“fsr-b-Leader_Map.png”},{“uri”:“fsr-b-Leather_normal.png”},
{“uri”:“…/Texture/fsr-b-color.png”} ] That is the only one not using
FSmaterials, so it seems the problem is related to relative name paths with
“non-fsmaterials” when it is exported from 3DS. Regards, Simbol