Compressing .MBM textures

[Nsomnia]

All of my mods that used .pngs and .tga formats for their textures I opened in photoshop and enabled compression with no loss in quality BUT a reducion on average of about 15% filesize (sometimes up to 50% on heavily detailed textures). This has made starting KSP that slight bit faster and RAM usage slightly less and we all know how long it takes to load with mods.

The problem I've encountered is a ton of mods use .mbm textures these are not editable in photoshop. Is there a way to either

a) open .mbm textures, compress, and save back to original directory with file size savings.

convert .mbm to .png or .tga and compress them, then back to .mbm with file size savings.

c) convert .mbm to .png or .tga and have the mod use these textures instead, which begs my noob question where is the texture file loaded, in the part.cfg?

.mbms make up over 50% of the total size of textures in my gamedata directory. So this could decrease loading times and RAM usage significantly, as well mods with the right fair use policys I could release the compressed textures for those with older computers or laptops (like myself).

Thank you.

Edit: Found this in some research, if I could convert the .mbms to .pngs or .tgas then I just edit the model.mu to use the new texture "Using a hex editor, I edited the file "model.mu" and near the bottom, changed all the texture filenames from "modelxxx.mbm" to "modelxxx.png". Here's what the text editor looks like after the edit:

0002B7F0   00 08 66 61  69 72 69 6E  67 31 03 00  00 00 00 00  ..fairing1......
0002B800   00 00 00 00  80 3F 00 00  80 3F 00 00  00 00 00 00  .....?...?......
0002B810   00 00 01 00  00 00 00 00  80 3F 00 00  80 3F 00 00  .........?...?..
0002B820   00 00 00 00  00 00 06 65  6E 67 69 6E  65 07 00 00  .......engine...
0002B830   00 02 00 00  00 00 00 80  3F 00 00 80  3F 00 00 00  ........?...?...
0002B840   00 00 00 00  00 03 00 00  00 00 00 80  3F 00 00 80  ............?...
0002B850   3F 00 00 00  00 00 00 00  00 C0 AF C6  3D C0 AF C6  ?...........=...
0002B860   3D C0 AF C6  3D 00 00 80  3F BF CC EB  3E 04 00 00  =...=...?...>...
0002B870   00 00 00 80  3F 00 00 80  3F 00 00 00  00 00 00 00  ....?...?.......
0002B880   00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 80  ................
0002B890   3F 0C 00 00  00 05 00 00  00 0C 6D 6F  64 65 6C 30  ?.........model0
0002B8A0   30 30 2E 70  6E 67 00 00  00 00 0C 6D  6F 64 65 6C  00.png.....model
0002B8B0   30 30 31 2E  70 6E 67 01  00 00 00 0C  6D 6F 64 65  001.png.....mode
0002B8C0   6C 30 30 32  2E 70 6E 67  00 00 00 00  0C 6D 6F 64  l002.png.....mod
0002B8D0   65 6C 30 30  33 2E 70 6E  67 01 00 00  00 0C 6D 6F  el003.png.....mo
0002B8E0   64 65 6C 30  30 34 2E 70  6E 67 00 00  00 00        del004.png....
0002B8F0
---  model.mu       --0x2B780/0x2B8EE------------------------------------------

Could theses tools be of use IE. use MBM2PNG, compress the .PNG in photoshop then use PNG2MBM to convert it back to the origonal texture file called for. Better yet use MBM2PNG (either this online tool or the one posted on the forums I have a copy of) then change the model.mu to use the .png instead of the .mbm for memory, and loading time savings?

MBM2PNG

PNG2MBM

The physical MBM2PNG exe file does this

This program converts Kerbal Space Program texture files (i.e. "model000.mbm")
into PNG files suitable for editing and use in the KSP game.

I also have muedit.exe which is useful

This program converts modifies "model.mu" files by changing the internal
texture filenames from (typically) "modelxxx.mbm" to "modelxxx.png". This
change allows KSP to utilize PNG texture image files instead of the original
MBM files. This program is used in conjunction with "mbm2png".

Basically am I going to see memory reduction and loading time savings by using compressed .pngs instead of .mbms? Being that Squad, KW Rocketry, and Kethane use .mbms this could be significant file size savings, does this lead to loading time and memory savings?

Edited August 14, 2014 by Nsomnia
more info

[NathanKell]

Size on disk is not directly related to size in memory.

On load, KSP will load *all* textures, uncompress them, and then recompress them to DXT1 or 5 (5 if the texture has an alpha channel). There is one exception: mbms which have a "do not compress ingame" flag will be left uncompressed.

There are some loader bugs, which it's unclear if they are still in KSP, namely that some PNGs do not get mipmaps generated for them on load, and that TGAs are left as RGB or RGBA (i.e. uncompressed) rather than compressed to DXT (note that of course this still has nothing to do with whether your TGA was compressed on disk; as I said, *all* files are uncompressed on load first, before *anything* else happens.)

If you see differences in memory ingame from converting files, that's due to the various loaders using more memory and garbage collection not freeing it yet. It will all even out in the end, unless the loaders have memory leaks.

Finally, as of version 0.20 of KSP, since all textures are the same formats ingame, the extension of a texture doesn't matter at all. In fact, models and textures are read in *before* anything else, and *all* models and textures in GameData are loaded, regardless of whether they will be used for anything. Since models are only "tied" to textures after both have been loaded, KSP will look for a texture in the same folder as the mu with the same name-before-extension as is requested by the mu. This is because it's requested from the GameDatabase. If you have multiple files of the same name (but different extension) only one will ever be referenced by models (but both will be loaded and take up space. So don't do this); and if you have a model000.png and the model requests model000.mbm that doesn't matter, because the extension isn't used; what it's actually requesting is "a texture in GameDatabase with the URI /path/to/model/requestedTextureName

That's also so that in a cfg in a MODEL node you can replace textures (i.e. you could do texture = model000, path/to/some/other/texture)

The long and short is, you're pretty much on a fool's errand. Convert away from mbm only if you have limited *disk* space, or if you want to edit the image; if you do convert away from mbm, delete the mbm so that there is only one file.

As you say, because disk read is slower than decompression, it may make sense to speed things up by converting to PNG so KSP has to read less data from the disk (even though it then takes some CPU time to decompress, whereas it takes 0 CPU time to decompress a mbm since mbms aren't compressed).

[CaptainKipard]

... and that TGAs are left as RGB or RGBA (i.e. uncompressed) rather than compressed to DXT...

Could someone please confirm or deny this? I've been using TGAs exclusively.

[Nsomnia]

So basically, by compressing say model000.TGA (32 bit/channel, no RLE compression=4MB) to model000.TGA to 24 bit/channel w/ RLE compression in Photoshop (which brings it down to 393KB) it doesnt matter anyway because KSP is going to decompress (to no RLE @ 24bit/channel=3MB) the textures anyway and switch them back to 32bit/channel (back to 4MB no gains).

So im wasting my time?

Even though it reduces B9's disk space usage by 1/4, ingame memory usage will still be the same no matter how many bits per channel or RLE compression I use on the textures in Photoshop?

[Justin Kerbice]

It would be great to have some inputs from someone who is really deep into GPU stuff and their drivers but AFAIK, GPU can't afford to loose time in compressing/decompressing, and that's explain why the strongest a Gfx card is, the more fast memory it include on board. Think of modern Nvidia card with 4GB inside. Do you really think those 4GB are just there to increase the sell price ? Give money to memory chips manufacturers ?

GPU need to be feed as fast as possible, so models and texture are push into the tube like high pressured gas in the most usable form: uncompressed (and/or converted into some internal, unusable outside, format).

It's not a waste of time to compress them as disk space + reading file from disk are still valuable eve with SSD or fast hard drives.

[NathanKell]

Nsomnia, correct, with the exception Justin Kerbice points out: because disk IO is much more expensive than CPU time decompressing, pngs may load slightly faster than MBMs. But they'll have the same memory usage in the end.

It's not that GPUs can't afford to lose time per se, it's that the *bandwidth* is at a premium and thus you want to compress files such that bandwidth is minimized, while using a compression format that is short-and-constant-time for accessing a given pixel.

[Nsomnia]

Nsomnia, correct, with the exception Justin Kerbice points out: because disk IO is much more expensive than CPU time decompressing, pngs may load slightly faster than MBMs. But they'll have the same memory usage in the end.

It's not that GPUs can't afford to lose time per se, it's that the *bandwidth* is at a premium and thus you want to compress files such that bandwidth is minimized, while using a compression format that is short-and-constant-time for accessing a given pixel.

Thanks for saving me time ill stick with ATM for now, +rep