DDS file-size and 8/18 bit question

User Support Hub SDK
,
1

Hello.

EDIT: Im one step further already. Its the Albedos that get 10.9 MB and metal and normal get 21.8 MB.
Seems like that is normal. Multiple ppl told me so by now that this is also like this for them. So basically there is no need to convert to 8 bit before. There will be no saving in the file-size. Only the resolution seems to have influence.

Yesterday I came around some, for me, weird behavior with the size of a dds file after the png got converted to dds.

Before I had a chat with some member from FSDeveloper about 16 bit and 8 bit and how the use of a 8 bit albedo can save a lot of file size without visual loss of quality. I wanted to give it a go.

Then I went to my substance painter textures and re-exported them in 8 bit.
Yes, the png that came out then was indeed 1/3 of the size of a 16 bit export.

I applied this one 8 bit albedo to my blender object and exported the gltf.
I thought “amazing, that saves me lots of space”. Until I built the project. Because now it has the identical file size like the one with the 16 bit had.

At one point I took a look at my texture output folder. And to my surprise, nearly every single dds texture had the exact same size. Despite having very different pngs as source, ranging from 20 to 70 mb per image.

Can be seen here, they all have 21,8 mb

unknown.png

Further down I saw some of the textures that have only the half of it, 10,9 mb (not visible in pic). All of them were 4k 16bit. I wondered why on earth some have 21.8 and others 10.9 with the same export settings and had a look at the UV map.

Nothing special, it was filled like the bigger ones. couldn’t see any difference that leads to the double file size.

I discussed this with 3 other ppl now and they confirm this is the case after they build the project too. Amd none of them had an explanation, basically all of em were rather surprised of this.

So my questions are 2 basically:

1 what defines the file-size of a DDS file after it got converted from a PNG.

2 what meaning has 8 and 16 bit png, if after being converted they have the exact same file-size?

Would be great to get some insight here.

2

Weird I also checked one of my add-ons and all but one dds texture file is 683kb’s but the last texture is double at 1,386kb’s.

3

Be sure to read the update in my post :slight_smile:

It’s most likely the albedo that has less. Looks like a normal thing.

1 Like
4

The DDS is not compressed. If the PNG was compressed at first, it will be decompressed into the DDS, that will take a lot of size. Second reason: a DDS is much larger than a PNG because the DDS can contain several versions of the image at smaller sizes, to show at larger distances. This is called the MIPMAP level of your texture. A texture can have 8-12 MIPMAP-levels, all adding to the size.

1 Like
5

Thanks for the reply.

That last part wouldn’t be what i see here though.

Atm it looks like that for me:

Input png size : 80mb → output DDS = 21mb
Input png size : 20mb → output DDS = 21mb

If we take the normal or metal map at least. The albedo is smaller.

So that part that a dds would be bigger automatically is not the case for me.

Also, so you say that the mipmap levels come from the dds converter? I always thought one would have to do it manually.

Sorry to sound doubtful, i just want to understand it :slight_smile:

6

With VS-2019 you get a menu option to generate all mip levels. When you then save your DDS, the levels are included. Main part is of size questions is always compression, I’m actually unsure after reading your answer ! You get DDS files that are smaller. I’ll look into it. btw. mip-mapping is not exponential… the size of a mip-mapped texture is binary on distance, so you have 2048-1024-512-256-128… a result texture with mip-mapping will be about 2x the size of a non-mipmapped texture.

7

(remark scrapped)

8

Hello.
Thanks for the reply. I checked it again and im not so sure anymore if SubstancePainter does what it should do, with the MSFS Export preset installed.

I can choose the bit size on the export settings (in the template) but it doesnt seem to have any influence at all. If i set it to 8 bit there or 16, nothing is changing in file-size for me. It seems like Substancepainter is overwriting the template settings somehow.

But besides that, yes, my DDS files are way smaller than the png texture. Up to 1/4, something like that (the pic shows a lesser difference), depends on the png. The one with 75MB is getting the exact same sie as this one.

image
image721Ă—139 11.8 KB

image

9

I read this again, tried to contribute, but in fact I’m not sure where your question originates from. You’re looking at compiled DDS ? You want to optimize size ? these compiled MSFS textures are shaped to fit into certain GPU buffers. The larger the DDS, the more effective transfer will be. For advanced objects, sometimes textures are grouped, that is you can set the UV-coords in a glbt.bin file to a single texture PNG. So when you have all textures of say, a 747 livery you could get megabytes of DDS ?

These are compiled textures in the Packages subdirectory of SDK project ProjectedMesh. They originate from PNG’s with a smaller size (?)

variousSizes
variousSizes754Ă—316 31.6 KB

10

Yes, ive tried to decrease the size, without changing the resolution. At the same time i saw in the SDK that they suggest to use 16 bit for the metal only (or normal, not sure anymore). At the time i had set everything to export with 16 bit in SP and wondered if i could decrease the package-size by exporting the albedo in 8 bit only.
And by doing that i saw that it doesnt seem to make the slightest difference if i export in 8 or in 16 bit.

That only is affecting the input PNG. After conversion it will have 21 MB. No matter if 8 or 16 bit (where i still dont understand why that is).

And now im here ^^ I mean, its not the most important thing but usually i try to understand how things work.

What is also confusing me is that i cannot see in the file descriptions how many bits it has. The field is simply empty sometimes, other times its showing 48 bit??

image

(the last line shows “Bitdepth 48”)

11

Maybe… this 16-bit format specification (you want 8 bit) could also be hidden somewhere in the glTF, read by MSFS before converting the png texture. Some “pixel type”… I reversed engineered a number of these files… in Blender converted glTF files it sais in the json part (gltf) that “Asobo extensions” are applied to the textures, e.g.

"extensionsRequired":["MSFT_texture_dds"],"extensionsUsed":["ASOBO_normal_map_convention","MSFT_texture_dds","ASOBO_asset_optimized"],"images":[{"extras":"ASOBO_image_converted_meta","name":"nessie","uri":"NESSIE.PNG.DDS"}],"materials":[{"name":"Material.001","pbrMetallicRoughness":{"baseColorTexture":{"index":0},"metallicFactor":0.0,"roughnessFactor":0.5}}]

When looking at glTF bin tiles with converted DDS UV-coords, I noticed some texture coordinates for a simple Blender unit cube are huge (15000+) maybe that indicates a very large square size in GPU memory… some stride … but my DDS-results are NOT that big ! btw if you have 21Mb with 4096x4096 is consistent with 8 bits plus a few mip levels (4096x4096 is 16MB) that 48 bit is certainly very strange. I’ve seen 32 (alpha channel)