• Which the release of FS2020 we see an explosition of activity on the forun and of course we are very happy to see this. But having all questions about FS2020 in one forum becomes a bit messy. So therefore we would like to ask you all to use the following guidelines when posting your questions:

    • Tag FS2020 specific questions with the MSFS2020 tag.
    • Questions about making 3D assets can be posted in the 3D asset design forum. Either post them in the subforum of the modelling tool you use or in the general forum if they are general.
    • Questions about aircraft design can be posted in the Aircraft design forum
    • Questions about airport design can be posted in the FS2020 airport design forum. Once airport development tools have been updated for FS2020 you can post tool speciifc questions in the subforums of those tools as well of course.
    • Questions about terrain design can be posted in the FS2020 terrain design forum.
    • Questions about SimConnect can be posted in the SimConnect forum.

    Any other question that is not specific to an aspect of development or tool can be posted in the General chat forum.

    By following these guidelines we make sure that the forums remain easy to read for everybody and also that the right people can find your post to answer it.

MSFS20 Re-using MSFS Textures

rhumbaflappy

Administrator
Staff member
Resource contributor
Messages
6,504
Country
us-wisconsin
MSFS has a lot of nice textures used in their models. We can re-use these textures in our own models via Blender. But one of the advantages of re-using textures is that we can reference these textures without including them in our packages, saving potential gigabytes of project size. The key is the use of texture.cfg
XML:
[fltsim]
fallback.1=scenery\outskerries\TEXTURE
Here, I decided to use textures from the Asobo outskerries package. Knowing which textures I want, I copied them to a SourceTextures folder, where I convert them from DDS to PNG, for use in Blender. I use Paint.net for this, as it easily converts the DDS to 32-bit PNG.

sourcetextures.png


Now I just use these PNG textures in Blender. When I export my object, I don't need to save these textures to my project, as my texture.cfg handles them.

blender.png


You can load the project into the DevMode, and MSFS will display the objects properly, even though you include no textures in the project. Here is an example: ReferencingTextures.zip
 
Arno has made a change in the way textures are initially loaded into MCX, and now it is trivial to load a model from a library, convert the textures to PNG, export the object, and the gltf output accurately uses the model's UVs. This lets us examine default models with the textures showing correctly oriented by using only a texture.cfg, rather than a texture folder loaded with converted textures.
 
I made a new test of referencing textures in your models. ReferringTexturesTest.zip on Google Drive

It has a !rhumba-modellib-texture package to go into Community. That is an example texture library, much like asobo-modellib-texture. The manifest.json gives a clue as to how to configure that.
Also there is a project that experiments with referring textures via texture.cfg. It contains some models that in turn uses textures from an Asobo package, a Microsoft package, my texture package, and a local modelLib texture.

This is the result of a discussion at https://devsupport.flightsimulator.com/t/modellib-texture-fallbacks/6260/1
 
Once you understand how the sim's VFS works, you can use any asset with the fallback metod.
 
Thanks for this, everyone! There are a few wrinkles, tips and tricks I learned along the way, mostly intended for people just starting with this:

  • Backward conversion is pretty much a straightforward process. MOST textures have 3 versions *_ALBEIDO.PNG.DDS, *_COMP.PNG.DDS, and *_NORMAL.PNG.DDS. The only "tricky" one is the *_NORMAL.PNG.DDS, where I had to save to BMP format, then vertically flip all channels, and fill one of the channels from black to white, mainly to conform to the standard look of NORMAL texture from green to blue.
  • In case the explanation above is NOT straightforward: the ASOBO default textures are in:

    MSFS2020\Official\OneStore\asobo-modellib-texture\Asobo_Buildings\Texture

    What you do is open (any-texture)(_ALBEIDO, _COMP).PNG_DDS (assuming your image editor can open DDS, my photoshop needed an NVIDIA plug-in for DDS), and SAVE AS, TYPE PNG, extension PNG (remove .DDS from the original file name) and save IN YOUR OWN FOLDER (no the default ASOBO folder)
  • As mentioned before, conversion of _NORMAL texture is not so straightforward. I use Arno's ModelConverterX to open the _NORMAL texture, SAVE AS BMP type, then use photoshop to vertically flip all channels, and fill BLUE channel with white color, then save as PNG.
  • If the textures are named exactly the same, except for their _ALBEIDO, _COMP, _NORMAL extensions, 3DS MAX material editor will automatically load _COMP and _NORMAL textures with its chosen _ALBEIDO texture. However, after that, you can manually replace or mix and match any _ALBEIDO, _COMP, _NORMAL texture from other materials.
  • The default Asobo textures are all bundled together, but I organized my converted textures into thematic/material folders: Concrete, Brick, Plastic, Metal, Doors, Rooftops, Windows, etc. this helps with locating the right material. I also have the folder at the biggest icon preview setting.
  • Most materials can be colorized by changing the color of the underlying base material, and thus creating a variation of what the original ALBEIDO texture was representing. The brighter the ALBEIDO color is, the better the effect is. So basically, you can have any material type (concrete, metal) painted in almost any color, not just the color that ALBEIDO version of the material comes in.
  • Adding an ALBEIDO detail map to the material, and adjusting its separate UV parameters can greatly add to the realism, by introducing a bit of a "dirty" look into the material, and breaking up the material pattern repetitiveness. Works well for the roofs and siding of hangars and buildings.
  • 3DSMAX material editor will let you have any combination of textures, or no texture at all (just a base material showing, but still with PBR properties. Clean chrome material is designed this way). In fact, Asobo recommends designing Lowest LOD with base materials only, so that the textures don't need to be loaded.
  • Unlike FSX and P3D days, Asobo's PBR material settings in 3DS MAX actually work and have been greatly simplified (Alpha modes, Render params, things like that). The only thing that I found annoying is that the double sided property of the material is not lit properly - both sides of the double-sided polygon are lit the same. So, this makes it unusable except in a few specific circumstances.
  • I've created all kinds of cool prop equipment (rooftop AC units, vent boxes, circuit and electrical boxes on the sides of the buildings) just by using default textures. I've saved these props as components and re-use them everywhere.
  • I've fine tuned my workflow and now I can produce a complete custom building in under an hour, using Asobo's excellent PBR textures. Every single custom building I create has its own multi-material with 5 basic sub materials that every building needs, in this order:
    SIDING
    ROOF
    FOUNDATION
    DOORS
    WINDOWS
    With this setup, if I have a lot of similar shaped buildings (sheds or small hangars) that vary in size and external appearance, I just keep creating copies (not instances) of geometry AND its material, vertex-resize as needed (width, length, height) and insert appropriate textures into the material slots. This greatly cuts down on production time. Most of my buildings have roof gables, gutters, downspouts, roof vents, air conditioning gear, electrical boxes, etc. Materials for those I add as needed after the WINDOWS material slot.
  • I mainly use Google maps and street view for reference. Google Earth has some areas covered with 3D photogrammetry, which helps a lot. But, to design a simple building (hangar/shed/warehouse), I basically take top-down width/length from Google Maps measuring feature, find the street view of the building and ratio-deduce height of the building from known length/width, and go from there.
  • EVERY building I design has a fairly deep FOUNDATION (usually with a CONCRETE material) that reaches into negative Z values. I reduce the size of this foundation in width and length from the main siding size (using bevel/extrude), and raise the whole building so that the building's siding is slightly above Z-plane (ground), showing the foundation part slightly. Then - I center the PIVOT point on the building, and manually force it to zero vertically (Z axis) to ground level. This basically makes the building sit properly on the ground, and if the ground is uneven or has a grade, you won't get any bottom corners hanging in the air - but you will properly see the foundation.
  • After you compile your building into the model library, their textures will also be included in the texture folder, which (if you did renaming mentioned above correctly) should be exact copies of the default ASOBO textures, but PNG type, without DDS extension. However - PNG textures are no longer needed, because they already exist as default textures. So, I created a simple CMD script which deletes all the unnecessary textures:

    del AIRCONDITIONER_WHITE_ALBEDO.PNG
    del AIRCONDITIONER_WHITE_COMP.PNG
    del AIRCONDITIONER_WHITE_NORMAL.PNG
    del AIRCRAFT_BELT_LOADER_GRID_ALBEDO.PNG
    del AIRCRAFT_BELT_LOADER_GRID_COMP.PNG
    del AIRCRAFT_BELT_LOADER_GRID_NORMAL.PNG
    ... (and so on)

  • After that, you compile your model library in the SDK project editor. And, of course, for this to work, make sure you include texture.cfg file discussed in the previous posts.
Anyway - I hope my experience with the default textures helps someone who wants to get into the design, but is turned off by the whole PBR concept, or lacks skills to create their own PBR materials. The point is - you don't NEED to design your own. Asobo provided ALL the textures needed to design almost any kind of material needed. I just wish they included the default PNG texture library and a bit of automation with their 3DSMAX/Blender plugins.
 
Last edited:
How to find the 'default' textures used in MSFS? I use an app named Everything. I use the 64-bit portable version (Zip file... extract to any folder).
Here's a search result: alb ext:dds D:\MSFS\Official\Steam\ It searches in my Steam folder recursively for any DDS file that contains alb in the name (for albedo). It returns 35001 textures in the standard MSFS. I can view them as thumbnails. Right-click on an image, and you can go to it's folder:
path.png


You need the path for a texture.cfg entry, and to find the comp and normal textures that go with it. alb glass ext:dds D:\MSFS\Official\Steam\ gives me 484 albedo textures that contain the word glass. That should find you a good glass texture that can be re-used. :laughing:
 
Ambient Occlusion. When referencing textures for your project, you'll inherit the AO stored in the red channel of the referenced COMP texture. And that's great for almost every situation. This is a 'per texture' AO. The sim also has a graphics setting for Ambient Occlusion that gives you an object AO, which is not material or texture dependent. But what if you want to include your own dramatic AO for an object. Maybe the sim's graphic settings don't give you the 'pop' that AO can provide? Adding AO to the COMP or Albedo textures doesn't work if you are referencing textures. And Adding a Decal material only introduces another texture, which is what referencing usually avoids. How can we add AO, without adding or altering textures? Vertex coloring.

Blender 3.6 can bake AO to the active Color Attribute (Vertex Color).

Color Attributes.png


AO bake setup.png


AO Baked.png
 
Dick,

When a texture.cfg is present in a scenery package it seems the listed folders are relative to the MSFS root folder.

If they are used in an aircraft package, the texture.cfg file is typically in the texture folder and in that case the listed folders are relative to that texture folder.

But the syntax of the files is the same. Do you happen to know when they are processed as relative to the containing folder and when as relative to the root?
 
Edited...
Hi Arno. I miswrote so I'm trying again. This is all relying on the virtual file system structure.
From asobo_VL3:
Code:
[fltsim]

fallback.1=..\..\..\..\texture\detailMap
fallback.2=..\..\..\..\texture\Glass
fallback.3=..\..\..\..\texture\Gauges
fallback.4=..\..\..\..\texture\AS3X
fallback.5=..\..\..\..\texture\Lights
fallback.6=..\..\..\..\texture\AS21
fallback.7=..\..\..\..\texture\AS92
fallback.8=..\..\..\..\texture\Planes_Generic

This actually refers to folders within D:\MSFS\Official\Steam\fs-base\texture (on my PC).
example:
Untitled.png

I'm not sure how to convert the VFS to the actual locations on the end-users PC.
 
Last edited:
Here's what I find on Airplanes:
..\..\..\..\texture is the location of the folder fsbase\texture\
..\..\..\..\texture\Lights is the location of the folder fsbase\texture\Lights\
..\..\ goes up 2 folder levels to whatever is indicated
example
..\..\Microsoft_Pilatus_PC6_Common\texturecontainers
points from that texture.cfg location (D:\MSFS\Official\Steam\microsoft-aircraft-pilatus-pc6\SimObjects\Airplanes\Microsoft_Pilatus_PC6_G950_Floats\texture) to (D:\MSFS\Official\Steam\microsoft-aircraft-pilatus-pc6\SimObjects\Airplanes\Microsoft_Pilatus_PC6_Common\texturecontainers) which is the standard 2 folder up and down to Microsoft_Pilatus_PC6_Common\texturecontainers\

In Aircraft, this is all I have found
..\..\ or ..\..\..\..\ none at ..\..\..\ (which I think is the VFS Airplanes folder)

Scenery can use VFS folders:
In D:\MSFS\Official\Steam\asobo-airport-seqm-mariscal-sucre-quito\scenery\mariscal_sucre_quito\texture.cfg

[fltsim]
fallback.1=scenery\mariscal_sucre_quito\texture
fallback.2=Asobo_Buildings\Texture
fallback.3=Scenery\modellib-texture\ModelLib

Asobo_Buildings is a VFS designation for D:\MSFS\Official\Steam\asobo-modellib-texture\Asobo_Buildings in my PC.
Scenery\modellib-texture\ModelLib is a VFS designation for D:\MSFS\Official\Steam\microsoft-modellib-texture\Scenery\modellib-texture\ModelLib in my PC.
 
Last edited:
Hi Dick,

But for the fallback2 and fallback.3 from the last example, it seems the paths are not relative to the location of the texture.cfg file. So how would MSFS know where to find them?
 
Those are VFS designations. Asobo_Buildings and Scenery.
 
Yes, that's my point, they seem to be absolute in the VFS, while for aircraft the entries in the cfg are relative. That is making it hard for me in ModelConverterX to process the cfg file correctly, as it seems you need to know what kind of package contains it.
 
I had another look, maybe I should just check each fallback path both as absolute (from MSFS root) or relative from the current folder. I think that will cover all possible situations.
 
It seems simobjects might be different than object models in finding the vfs texture path?
 
Guess so, I just implemented it to check both absolute and relative and that seems to work fine for scenery and aircraft.
 
Hi Arno.

I just tested a reference:
Code:
[fltsim]
fallback.1=Scenery\airport-41wi-elkhorn\MyModelLib\texture
fallback.2=Texture\LIVERY
It references the textures in fs-base\texture (D:\MSFS\Official\Steam\fs-base\texture in my PC). I think for scenery objects, the VFS assumes fs-base as the root.

For an aircraft (or any simobject?), fallback.2=..\..\..\..\Livery would work So there is a difference I think in how the sim locates textures depending on the type of object.

Untitled.png
 

Attachments

Last edited:
Back
Top