-
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 What texture file format
- Thread starter jgarnold
- Start date
- Messages
- 6,561
- Country
I'm guessing you're asking about MSFS. The SDK states only PNG or JPG.
- Messages
- 1,839
- Country
Thanks Dick. Yes I thought that this forum was only for MSFS?
I have more than one .glTF scenery object from the internet which have some texture filenames the same even though the actual image is different so I can't use them both in the same 'airport scenery' (I'm using ADE) as all images go into the (shared) texture file (in the source files). There appears to be a 'link' in the 'giTF/.BIN) files to those texture files so I can't simply rename them. Any ideas how I can get around that?
I have more than one .glTF scenery object from the internet which have some texture filenames the same even though the actual image is different so I can't use them both in the same 'airport scenery' (I'm using ADE) as all images go into the (shared) texture file (in the source files). There appears to be a 'link' in the 'giTF/.BIN) files to those texture files so I can't simply rename them. Any ideas how I can get around that?
- Messages
- 6,561
- Country
Hi John. The glTF is a text file, and you can change texture names and extensions there, as well as the referenced BIN file that contains the mesh.
- Messages
- 1,839
- Country
Wow I didn't realise that it was a text file so thanks.
I did though find quite by accident that MCX allows you to 'prefix all with model name' before Save Textures which is a neat way of changing the names.
I used MCX a lot yesterday including importing previously exported Object where all I wanted to do was change the texture filenames (as above). Get's me FSX models too. A great tool.
I did though find quite by accident that MCX allows you to 'prefix all with model name' before Save Textures which is a neat way of changing the names.
I used MCX a lot yesterday including importing previously exported Object where all I wanted to do was change the texture filenames (as above). Get's me FSX models too. A great tool.
- Messages
- 1,839
- Country
FYI (I bet everyone already knew) I just discovered that MCX (appears to) output 'square' texture files. I had a problem with Blender and so used MCX to output the texture files with the model name as prefix to the texture files to get different file name. I found that MCX (appears to) fixes texture files which are not 'square' automatically during output (I had a texture file which was something like 1069 x 1200). I guess it is a feature I didn't know about.
- Messages
- 278
- Country
For MSFS your textures have to be squared - eg. something like 256x256, 1024x1024, 512x2048 or 4096x1024. Minimum 8x8. MCX has a feature to change textures with wrong proportions, and it also can rename and save all textures as PNG! Very handy!
Hello:
I believe MSFS SDK now requires us to be even more precise in our interpretation of the "Powers of 2" concept used by many 3D display engines.
Rather than "square" pixel arrays, we must think in terms of mapped Materials as 'square or rectangle' arrays of texture pixels (aka "Texels").
Info on the whys and wherefores as to use of "Powers of Two" in pixel dimensions of texture image materials in 3D modeling graphics:
www.katsbits.com
https://gamedev.stackexchange.com/q...lways-square-powers-of-two-what-if-they-arent
https://docs.microsoft.com/en-us/wi...1-devices-downlevel-intro?redirectedfrom=MSDN
https://devblogs.microsoft.com/dire...edback-some-useful-once-hidden-data-unlocked/
BTW: I have yet to find where Asobo allegedly cited 'Powers of Four' in an early interview about MSFS-2020 development. 
Rather, we might best interpret that info as referring to a "Multiple of Four" rule
I can only refer to this recent updated statement in the MSFS-2020 SDK online docs:
docs.flightsimulator.com
"TEXTURES
This page is for general guidelines related to creating your own textures for add-ons that will be used in Microsoft Flight Simulator. In principle, the game supports all texture formats that can be loaded through the WIC (Windows Imaging Component) and also supports the DDS file format. For glTF models, as per the specification, *.JPG and *.PNG are supported.
When creating your textures, it is important to note that input texture dimensions must be a multiple of 4 pixels and be at least 8 by 8 pixels. Textures do not have to be square, as long as the sides adhere to the multiple of four rule.
The closest I have found thus far, to an explanation of the "multiple of 4 pixels" reference is this discussion of DX-12 MIPMAPs:
https://devblogs.microsoft.com/dire...edback-some-useful-once-hidden-data-unlocked/
If you use a small mip region, you get more fine-grained information but the feedback maps are a bit bigger. If you use a larger mip region, you get less-detailed sampler feedback information, but save a bit on memory."
One might wonder if DX-12 development underway for MSFS-2020 might be a basis for future-proofing all 3D content for optimal performance:
www.3dgep.com
This may correlate with the general optimizations required for efficiently rendering MIPMAPs and LODs cited in the MSFS-2020 SDK Docs:
Regarding MCX, I hope Arno will add a feature in MCX Event Log and in Material Editor to warn when textures are not at least 8x8 Pixels.
GaryGB
I believe MSFS SDK now requires us to be even more precise in our interpretation of the "Powers of 2" concept used by many 3D display engines.
Rather than "square" pixel arrays, we must think in terms of mapped Materials as 'square or rectangle' arrays of texture pixels (aka "Texels").
Info on the whys and wherefores as to use of "Powers of Two" in pixel dimensions of texture image materials in 3D modeling graphics:
Make Better Textures For Games, ‘Power of two’ & Proper Image Dimensions – KatsBits.com (legacy)
Make Better Textures For Games, 'Power of two' & Proper Image Dimensions
www.katsbits.com
https://gamedev.stackexchange.com/q...lways-square-powers-of-two-what-if-they-arent
https://docs.microsoft.com/en-us/wi...1-devices-downlevel-intro?redirectedfrom=MSDN
https://devblogs.microsoft.com/dire...edback-some-useful-once-hidden-data-unlocked/
BTW: I have yet to find where Asobo allegedly cited '
Rather, we might best interpret that info as referring to a "Multiple of Four" rule
I can only refer to this recent updated statement in the MSFS-2020 SDK online docs:
SDK Documentation
docs.flightsimulator.com
"TEXTURES
This page is for general guidelines related to creating your own textures for add-ons that will be used in Microsoft Flight Simulator. In principle, the game supports all texture formats that can be loaded through the WIC (Windows Imaging Component) and also supports the DDS file format. For glTF models, as per the specification, *.JPG and *.PNG are supported.
When creating your textures, it is important to note that input texture dimensions must be a multiple of 4 pixels and be at least 8 by 8 pixels. Textures do not have to be square, as long as the sides adhere to the multiple of four rule.
The closest I have found thus far, to an explanation of the "multiple of 4 pixels" reference is this discussion of DX-12 MIPMAPs:
https://devblogs.microsoft.com/dire...edback-some-useful-once-hidden-data-unlocked/
"Granularity
Feedback granularity is controlled through a mip region. The smallest possible mip region is 4×4, and they are powers of two. If you have a mip region of 4×4, then it’s as if “every texel in the feedback map corresponds to a 4×4 area in the texture it’s storing feedback for”.If you use a small mip region, you get more fine-grained information but the feedback maps are a bit bigger. If you use a larger mip region, you get less-detailed sampler feedback information, but save a bit on memory."
One might wonder if DX-12 development underway for MSFS-2020 might be a basis for future-proofing all 3D content for optimal performance:
Learning DirectX 12 - Lesson 4
In this lesson, you will learn how to load textures and generate mipmaps using a compute shader in DirectX 12.
www.3dgep.com
This may correlate with the general optimizations required for efficiently rendering MIPMAPs and LODs cited in the MSFS-2020 SDK Docs:
Regarding MCX, I hope Arno will add a feature in MCX Event Log and in Material Editor to warn when textures are not at least 8x8 Pixels.
GaryGB
Last edited:
- Messages
- 1,839
- Country
Thanks Gary
I used the term 'square' VERY loosely and ALWAYS check that the dimensions (in pixels) can be divided by 4 but now think that I should 'go for' 8. I LOVE binary numbers and was the first thing I learnt when learning to program/code especially in the days of 8bit processors
Yes a warning in MCX that images aren't 8X8 would be good BUT it seems that MCX automatically resizes as I had an .fbx object which I imported into Blender and later exported as a glTF to find that one texture image was 2469 X 1944. I imported that into MCX and exported (image type PNG) and the resulting output image was 2048 x 1024 and so MCX had fixed the wrong image. I did the same exercise outputing JPG images andMCX resized those to 2024 X 2048.
NEAT eh?
So maybe not a warning but a message also stating that output images will be resized?
I used the term 'square' VERY loosely and ALWAYS check that the dimensions (in pixels) can be divided by 4 but now think that I should 'go for' 8. I LOVE binary numbers and was the first thing I learnt when learning to program/code especially in the days of 8bit processors
Yes a warning in MCX that images aren't 8X8 would be good BUT it seems that MCX automatically resizes as I had an .fbx object which I imported into Blender and later exported as a glTF to find that one texture image was 2469 X 1944. I imported that into MCX and exported (image type PNG) and the resulting output image was 2048 x 1024 and so MCX had fixed the wrong image. I did the same exercise outputing JPG images andMCX resized those to 2024 X 2048.
NEAT eh?
So maybe not a warning but a message also stating that output images will be resized?