.mbm Texture File Converter

[NathanKell]

1. As of KSP 0.20, all assets are loaded independently: all cfg are loaded, all mu are loaded, all mbm/png/tga/jpg/etc are loaded. Every non-cfg asset gets a GameDatabause URL, which is the relative path of the asset, sans extension, starting from GameData. I.e. Squad/Parts/Command/Mark1Cockpit/model (the mu), Squad/Parts/Command/Mark1Cockpit/model000 and model001 and... (the textures).

Only once all assets are loaded are Parts compiled: the cfg is read, to establish what model the part uses (if mesh=blah is used, the first model in the folder is picked; if MODEL{} node(s) are used, the models are explicitly specified.) Then the textures are looked up. The list of textures at the end of the mu is read, with the extension stripped. Then, if using a MODEL node, the node is checked for any texture overrides (i.e. texture = model00, some/other/path/to/another/texture ). If so, that texture is used; if not, then the linker tries to find some texture with the same path (i.e. Squad/Parts/Command/Mark1Cockpit/ ) as the model, with the name (sans extension) as specified in the mu, so if the mu wants model001, the linker will look for Squad/Parts/Command/Mark1Cockpit/model001 in the texture database.

As I said, you must *not* have textures of the same name differing only in extension in the same folder. If you do, then there will be multiple entries of the same name in GameDatabase, and the one that was added first (i.e. with the alphabetically prior extension, m < p when sorting by alpha) will always be the first returned when searching for that URL.

2. That flag determines whether the mbm should be compressed to DXT1/5 (1 if RGB, 5 if RGBA) on load or left uncompressed RGB/RGBA. It is used for GUI elements and for normal maps.

[Krupski]

2. That flag determines whether the mbm should be compressed to DXT1/5 (1 if RGB, 5 if RGBA) on load or left uncompressed RGB/RGBA. It is used for GUI elements and for normal maps.

Not quite sure what you mean. The flag I'm referring to is either 0x00 or 0x01. Does that mean that 0x00 == DXT1 and 0x01 == DXT5?

If so, then I have another question... if the texture is a Targa (TGA) file instead of MBM, it doesn't have that flag. How does KSP know what to do regarding DXT1/5?

I just finished writing a little utility that does MBM -> TGA conversion which is a lot simpler than PNG. All it does is verify that the magic number is 3KSP, then it grabs the width, height and bit depth of the MBM file, swaps RGB to BGR (and copies the alpha channel if the MBM is 32 bit), then writes a TGA header and the bitmap. Presto! It works like a charm.

It doesn't slow down loads like PNG does (because TGA isn't compressed) and I don't have to flip the bitmap upside down like MBM -> PNG requires.

I've already tested it by taking all of my MBM files converting them all to .TGA, then deleting the .MBM files. KSP loads and runs just fine, and I can easily edit any TGA file in Photoshop, Paintshop Pro or Gimp (linux).

It seems to be working just fine.

As I said, you must *not* have textures of the same name differing only in extension in the same folder.

Yes I know that. After I converted my MBM files to TGA, I removed them from where they were and archived them in another directory (just in case).

BTW, I just tried to upload my utility to Curse and now I know why it's called "Curse"... because that's what I did after spending 1/2 an hour creating an account, making a "required screenshot" for a console mode utility and then discovering that they don't accept pre-compiled code (wonder what they think DLL files are?).

I've got a GitHub account where all my other code is... I suppose I could put it up there.

Argh.....

[NathanKell]

Github is great, a lot of us use the Releases system.

As to mbms: no, the flow chart is this:

1. Does it have a 1 for that flag? If yes, go to 5. If no, go to 2.

2. Does it have an alpha channel? If yes, go to 3; if no, go to 4.

3. Compress to DXT5. Done.

4. Compress to DXT1. Done.

5. Leave uncompressed. Done.

Since formats other than MBM don't have the flag, step 1 is skipped, the process starts at step 2.

However, there is a bug in the TGA loader; it goes to step 5 immediately no matter what (ATM fixes this bug). This means that no TGA files will be compressed to DXT on load unless ATM is installed.

Finally, as of .25, there is a big bug in the stock TGA loader; certain images under certain circumstances will simply fail to be loaded, and a white (untextured) object will result. This is a highly dangerous bug, and TGA should not be considered a viable format until it is fixed or unless the user has ATM installed.

[Krupski]

Github is great, a lot of us use the Releases system.

As to mbms: no, the flow chart is this:

1. Does it have a 1 for that flag? If yes, go to 5. If no, go to 2.

2. Does it have an alpha channel? If yes, go to 3; if no, go to 4.

3. Compress to DXT5. Done.

4. Compress to DXT1. Done.

5. Leave uncompressed. Done.

Since formats other than MBM don't have the flag, step 1 is skipped, the process starts at step 2.

However, there is a bug in the TGA loader; it goes to step 5 immediately no matter what (ATM fixes this bug). This means that no TGA files will be compressed to DXT on load unless ATM is installed.

Finally, as of .25, there is a big bug in the stock TGA loader; certain images under certain circumstances will simply fail to be loaded, and a white (untextured) object will result. This is a highly dangerous bug, and TGA should not be considered a viable format until it is fixed or unless the user has ATM installed.

Thanks so much for the info. I've been looking for this for a long time.

I wasn't aware that there was a bug loading TGA files. I do know that there is a problem with 64 bit Linux concerning loading PNG files which requires patching 2 bytes in KSP.x86_64 to prevent (seemingly) random crashes when loading PNG textures. If you're interested, this is the patch data for KSP_linux 64 bit version 0.25 (readers do not apply this patch to any other version - if you need the address for other versions let me know and I'll post them):

root@michael:/usr/share/KSP_linux# fcmp KSP.x86_64_original KSP.x86_64

Reading KSP.x86_64_original (20207816 bytes)

Reading KSP.x86_64 (20207816 bytes)

Comparing KSP.x86_64_original with KSP.x86_64

0099F587: 01 00

0099F58C: 01 00

fcmp: 2 mismatches encountered

The "crash while loading PNG files" problem is discussed here: http://bugs.kerbalspaceprogram.com/issues/752

Oh well, thanks again for the texture loading info!

-- Roger

[MarrusQ]

Well, now that spaceport is dead, how do we get your program?

EDIT: Found it! Google is really an option to consider...

[Krupski]

Well, now that spaceport is dead, how do we get your program?

EDIT: Found it! Google is really an option to consider...

Be careful! If you are trying to use what's on my GitHub page, be aware that it does several things wrong that I am currently fixing (thanks to SUPER helpful info from NathanKell).

You are welcomed to try the current code, but please make backup copies of your originals first (or wait a few days until I finish updating the utilities) since it may not work exactly as you expect.

Thanks.

-- Roger

[Bit Fiddler]

any chance you could do us a recursive run so it will hit every .mbm in our gamedata folder, convert it, and then rename the mbm to .old or something? this way we can mass convert the .mbm in our game data but can always revert with the .old file if needed.

I suppose this may be possible with your utility as is, and a windows batch file somehow?

[Krupski]

any chance you could do us a recursive run so it will hit every .mbm in our gamedata folder, convert it, and then rename the mbm to .old or something? this way we can mass convert the .mbm in our game data but can always revert with the .old file if needed.

I suppose this may be possible with your utility as is, and a windows batch file somehow?

Well, I wrote these utilities in Linux and then cross-compiled them for Windows. The original versions (a year or so ago) did indeed do wildcards so all you had to do was something like:

mbm2png model*.mbm

and the wildcard would expand correctly and do all the files.

Unfortunately, Windows didn't support the wildcards (which didn't surprise me one bit). So, to make the programs work uniformly between OS's, I made them all do single files.

What you can do in Windows (console mode) is something like this:

dir *.mbm /b > convert.bat

This will get a listing of all files that end in ".mbm" and put them into a text (batch) file.

Then you can use a text editor like notepad or something else and add the "mbm2xxx" command to each one, then finally run the batch file. It would go like this:

(1) cd "\Program Files\KSP_win\GameData\Squad\Parts\Engine\liquidEngineSkipper" (this puts you in the folder for the "Skipper" engine)

(2) dir *.mbm /b > convert.bat (this creates a batch file that looks something like this:

ksp_l_midrangeEngine_diff.mbm

ksp_l_midrangeEngine_emissive.mbm

ksp_l_midrangeEngine_fairing_diff.mbm

ksp_l_midrangeEngine_fairing_norm.mbm

ksp_l_midrangeEngine_normal.mbm

Now, open the file with an editor:

(3) notepad convert.bat

(4) Add "mbm2png.exe" to the beginning of each line so the file ends up looking like this:

mbm2png.exe ksp_l_midrangeEngine_diff.mbm

mbm2png.exe ksp_l_midrangeEngine_emissive.mbm

mbm2png.exe ksp_l_midrangeEngine_fairing_diff.mbm

mbm2png.exe ksp_l_midrangeEngine_fairing_norm.mbm

mbm2png.exe ksp_l_midrangeEngine_normal.mbm

Now, save the file.

Lastly, run it:

(5) call convert.bat

It should convert all the files in one shot.

If you want to do your ENTIRE KSP install at once, just use the dir command to send ALL the filenames to the batch file. First, go to the root of the KSP install directory, then type:

dir *.mbm /b /s > convert.bat

The /b switch means "display the filename bare (no size or date info)" and the /s switch means "do all the sub-directories too"

Then add the appropriate utility filename to each line and let it rip.

I should make a utility to process the batch files to add the filename to each line... maybe I will.

Good luck. Any questions, let me know.

[Krupski]

any chance you could do us a recursive run so it will hit every .mbm in our gamedata folder, convert it, and then rename the mbm to .old or something? this way we can mass convert the .mbm in our game data but can always revert with the .old file if needed.

I suppose this may be possible with your utility as is, and a windows batch file somehow?

Check out the stuff here: http://www.hobbytent.com/other/files/mbm_utils.zip

It's the source and per-compiled executables for Windows and Linux. There is also a new utility called "fixbat.exe" which does what I mentioned in the previous post.

You create your batch file by typing "dir *.mbm /b > convert.bat" (or whatever name you want - doesn't have to be "convert"). This gives you a list of every filename that ends in ".mbm"

Now say you want to convert all of the files to PNG... of course you would want to use the "mbm2png.exe" utility. So you need to add it's name to each line in your new batch file. That's where "fixbat.exe" comes in.

You type "fixbat" and it asks you "Enter the name of the batch file: ". You type "convert.bat". Next it asks you "Enter the name of the utility: " and you type "mbm2png.exe".

The program reads in "convert.bat", then line by line adds the utility name to each line, then writes it back out. So, it your batch file had this in it:

model000.mbm

model001.mbm

model002.mbm

it will be transformed into this:

mbm2png.exe model000.mbm

mbm2png.exe model001.mbm

mbm2png.exe model002.mbm

...which is now a usable batch file. All it does is automate the hand editing of the batch file.

Now if only Windows properly supported wildcards, we wouldn't need all this baloney...

[Bit Fiddler]

well not having tried this yet could we just skip a step and do this...

dir *.mbm /b /s | mbm2png.exe

it has been years since I messed with DOS and batch files but now that I look t this I seem to recall this should work. I guess ill go backup my gamedata directory and play with it a bit. see what I can come up with.

just as a side note is there any drawback to the .png conversion? I mean is quality less, longer load times, etc?

Edited November 22, 2014 by Bit Fiddler

[Krupski]

well not having tried this yet could we just skip a step and do this...

dir *.mbm /b /s | mbm2png.exe

it has been years since I messed with DOS and batch files but now that I look t this I seem to recall this should work. I guess ill go backup my gamedata directory and play with it a bit. see what I can come up with.

just as a side note is there any drawback to the .png conversion? I mean is quality less, longer load times, etc?

Interesting idea. The utilities do read the filename from standard input, but piping a bunch of filenames into it won't work because it only "runs through the loop" once.

Also realize that a DOS "pipe" isn't a real pipe... it merely copies standard output to a temporary file then sends the data to the destination. You can't do multiple pipes in DOS (for example, dir | sort | lowercase | etc).

I could, however, quite easily change it to accept as many filenames as are thrown at it (which would make it work the way you suggested).

I'll look into it and incorporate the change if I can.

Concerning PNG files, the only reason to convert a texture to PNG is to be able to edit it with a photo or image editor. Every image editor knows PNG, none know MBM.

A PNG file is compressed and a lot smaller than an uncompressed MBM file, but doing that only saves you disk space.

When KSP loads the textures, if they are PNG, it has to decompress them back into raw bitmaps. So this saves you nothing in memory usage while the game runs, AND it also greatly slows down loading because KSP has to decompress each one.

Converting an MBM to TGA is a lot better, because the TGA is uncompressed (i.e. loads as fast as MBM) and it's a format editable by most image editors.

I'm going to look into converting multiple files with your method. It might work!

[Bit Fiddler]

well I was mostly interested in KSP memory savings. but the ability to make my own textures for parts is another reason I want to convert .mbm. I will just follow this thread for a bit, see what you come up with for converting back and forth between the formats.

[Krupski]

well I was mostly interested in KSP memory savings. but the ability to make my own textures for parts is another reason I want to convert .mbm. I will just follow this thread for a bit, see what you come up with for converting back and forth between the formats.

Yeah, you won't save any in-game memory by using PNG. By the way, I REALLY like your idea of simply being able to shove filenames at the utility and process them, so I modified my utility to do it.

I only did one so far, but if you want to try it and report back, I'd appreciate it. Here's the link:

http://www.hobbytent.com/other/files/new_idea.zip

Here's what's in the ZIP file:

root@michael:~/c-progs/ksp_utils# unzip -l new_idea.zip

Archive: new_idea.zip

Length Date Time Name

--------- ---------- ----- ----

77824 2014-11-23 11:15 mbm2png.exe

5860 2014-11-23 11:15 mbm2png.c

--------- -------

83684 2 files

The EXE is a Win32 executable, the C is of course the source.

You can use it in 3 different ways:

(1) dir *.mbm /b | mbm2png.exe (pipe all mbm files into mbm2png.exe)

(2) mbm2png.exe (it will ask for a filename, convert it, then ask for another. a blank filename [i.e. just press enter] closes the program)

(3) mbm2png.exe model000.mbm (will convert this one file and exit)

You can also create a text file with all of the textures you want to convert (even in different subdirectories), then just do this:

type filelist.txt | mbm2png.exe

--or--

mbm2png.exe < filelist.txt

Not sure if redirecting STDIN works in Windows, but I think it does. Try it!

-- Roger

[swankidelic]

Thanks for this Krupski =) Just used mbm2png a bunch and it worked a treat. Being a filthy casual Windows user, I just used Windows Explorer and dragged .mbm files onto the .exe and it generated the .png in the same directory. One-handed, awww riiiight

I tried the new version as well, and it worked just as well for me but the command line window wasn't as verbose. No bigs. Thanks again!

[Krupski]

Thanks for this Krupski =) Just used mbm2png a bunch and it worked a treat. Being a filthy casual Windows user, I just used Windows Explorer and dragged .mbm files onto the .exe and it generated the .png in the same directory. One-handed, awww riiiight

I tried the new version as well, and it worked just as well for me but the command line window wasn't as verbose. No bigs. Thanks again!

I took out all the verbose stuff. I initially had it in there for debugging purposes - so I could see what it was doing and when.

Now that it accepts multiple files on standard input (and works with drag-n-drop), the utility is now little more than a "black box"... MBM in, PNG out, so who needs all the verbosity?

The program still does all the checks that it did before and still will print a message for any ERROR, but if it's working right, it prints (almost) nothing.

I did have to compromise a bit in the printing department. If someone at a command line simply typed "mbm2png", it would sit there waiting for a filename input. This might look like it locked up or crashed, so I made it prompt the user with "Enter filename: ".

This, of course, caused another problem. When used in "pipe mode", it would just print "Enter filename: " over and over as it pulled in each filename from the pipe (which might be confusing).

So.... I made it echo the filename. This way, it looks right when used in "pipe mode" and it doesn't appear to be locked up if a person types the command name without a filename.

Now that it works, I'll finish the rest of the utilities and put them all up on my GitHub account. I've got 4 utils:

(1) MBM to PNG

(2) PNG to MBM

(3) MBM to TGA

(4) TGA to MBM

...plus the C source code for each (it's free open source).

The XXX to MBM converters also scan the image data and correctly set the "compression type" flag (header offset 0x0C) to 0 or 1 as appropriate (huge thanks to NathanKell for that info!).

These should be all anyone needs to edit and convert textures using Photoshop of Paintshop Pro or Gimp or whatever they prefer.

BTW, thanks for telling me about the drag-n-drop thing. I never thought of that and I didn't even know it would work that way. It's amazing how much a simple suggestion or a simple idea helps with a project like this.

I'll let you know when they are all done.

-- Roger

[Bit Fiddler]

actually I tried the drag and drop on your old version and it worked on it as well. as a drag and drop in windows works just as if you had run the .exe with the dragged file as an argument.

I will play with this new version see what it does if I just hand it my entire gamedata folder.

[Krupski]

actually I tried the drag and drop on your old version and it worked on it as well. as a drag and drop in windows works just as if you had run the .exe with the dragged file as an argument.

I will play with this new version see what it does if I just hand it my entire gamedata folder.

Here's the newest (and hopefully all correct now) utilities on GitHub LINK

Be sure to read the "README.txt" file first (you can read it right from GitHub before you download the ZIP).

There are four utilities:

MBM -> PNG

PNG -> MBM

MBM -> TGA

TGA -> MBM

Give them a try, but be sure you make backups of your originals first - just in case.

I would suggest doing some testing first to be sure it all works the way you want BEFORE doing all of the textures in bulk mode.

Any problems or questions, let me know.