Looking for a simple bmp to dds converter

[Crusader]

I would really like to switch alot of the excellent portovers from bmp texture files to dds format . I found a program called bmp2dds but there wasn't a manual or instructions included . Keep in mind that it must be simple for a very simple minded person (me). If it involves alot of other programs and changes to " mips and maps" or whatever they are called I may have to quit before I get started . LOL
I realize it may involve alot of time for one AC's conversion but as I stated , if it is simple enough and not complicated , I have plenty of time . Any other program suggestions other than the one I mentioned above welcome if you think it would be easier .

Thanks , ( 0318 Eastern---time to "hit the rack" as we use to say in the military---this is what happens when you are retired---you don't give a damn what time it is)

Rich

[Crusader]

Found this on a search here at SOH . Thanks Bjoern . Havn't had a chance to read through everything . It looks like I might just have to pick an AC in airplane folder to experiment with and if I screw it up , so be it . I am just looking for a step by step way to convert as I am VERY new to this .

Rich


http://www.sim-outhouse.com/sohforum...ure+conversion

[jankees]

DXTbmp will do this for you quite nicely.
Just open, flip vertically (button in lower left hand corner) and save.

but seriously, why would you want to do it, if it is so much work?
FSX will read bmp's without a problem, the textures are identical, the only difference is that the textures are flipped, which means they will load one millisecond faster than normal bmp's.
So unless you are taxing your system, I wouldn't bother, I still have heaps of bmp textures in my FSX without any problem, and I can see no difference.

[guzler]

Found this on a search here at SOH . Thanks Bjoern . Havn't had a chance to read through everything . It looks like I might just have to pick an AC in airplane folder to experiment with and if I screw it up , so be it . I am just looking for a step by step way to convert as I am VERY new to this .

Rich


http://www.sim-outhouse.com/sohforum...ure+conversion

I use this and highly recommend it, incredibly simple and takes seconds to convert each texture folder. Never had any problems with it.

[bruce448]

try this batch file that I made a while ago

http://www.mediafire.com/file/2d9r7g...67/bmp2dds.zip


Just place the 2 files into your texture folder that you need converting and double click on the bmp2dds.bat file, the rest will be done for you.

Bruce

[Crusader]

Thanks all for the above . So if I understand it right , there is no visual--quality advantage to switching . My system displays the bmps well and I don't think they effect performance (fps) that much . I always thought there was some type of advantage other than size .

[Crusader]

DXTbmp will do this for you quite nicely.
Just open, flip vertically (button in lower left hand corner) and save.

but seriously, why would you want to do it, if it is so much work?
FSX will read bmp's without a problem, the textures are identical, the only difference is that the textures are flipped, which means they will load one millisecond faster than normal bmp's.
So unless you are taxing your system, I wouldn't bother, I still have heaps of bmp textures in my FSX without any problem, and I can see no difference.

Thanks jankees ,

I consider you one of the premier painters in the FS world . I have a ton of your paints .

Rich

[italoc]

Hi Rich
Jankees is 100% correct: don't bother, bmp are perfectly ok in FSX !!
Italo

[PRB]

DXTbmp will do this for you quite nicely.
Just open, flip vertically (button in lower left hand corner) and save.

but seriously, why would you want to do it, if it is so much work?
FSX will read bmp's without a problem, the textures are identical, the only difference is that the textures are flipped, which means they will load one millisecond faster than normal bmp's.
So unless you are taxing your system, I wouldn't bother, I still have heaps of bmp textures in my FSX without any problem, and I can see no difference.

That's a great idea! Saves a step. Thanks, jankeeys.

[BASys]

Hi Folks

Please DO NOT convert texture types !

FS reads the texture.extension calls from within the model file.

FS then searches specifically for those explicitly named texture.extension files.



By converting AND renaming files, (e.g. from .BMP to .DDS)
you're adding TWO extra disk file-seeks
for every single texture renamed.

Doing so utilises lots of CPU & I/O cycles.



If just converting types, (i.e. retainining developers original texture.extension),
it'll have a relatively minor FPS impact.



For a detailed explanation, please see FSDeveloper - Wiki - Missing Textures.



HTH
ATB
Paul

[Bjoern]

Thanks Bjoern .

No problem.

Please DO NOT convert texture types !

I don't quite get your point.

I've converted all of my AI aircraft textures to .dds (.dds also works with non-native aircraft models) and don't have any problems at all.
The model file looks primarily for the texture name, not necessarily the extension. Otherwise, using file formats such as .psd for development in GMax/Max would drive FSX nuts looking for the proper texture format once the model is in-sim.

[BASys]

Hi Folks

I've converted all of my AI aircraft textures to .dds (.dds also works with non-native aircraft models) and don't have any problems at all.

Bjoern -
Just because you haven't noticed any obvious problem,
doesn't mean that your system isn't doing lots of unnecessary disk-seeking.

The model file looks primarily for the texture name,
not necessarily the extension.

Sorry but you're misinformed.

Please read the wiki article.

Otherwise, using file formats such as .psd for development in GMax/Max
would drive FSX nuts looking for the proper texture format once the model is in-sim.

Thats an incorrect assumption.

FSX also natively supports lots of legacy formats.



HTH
ATB
Paul

[mjahn]

Read the Wiki, interesting test.

What are the consequences for modellers, I wonder? Personally, I use ordinary bmp's (and sometimes jpg's) for mapping, but use dds in the sim itself. Should I, prior to final compilation, change filenames in the Material Editor so as to read xxx.dds, in order to shorten the search cycle?

Note that in the compilation procedure you are allowed to tick boxes such as "Use .BMP Extension" and "Use .DDS files" (both, if you want). Does this have any significance?

[Bjoern]

...

...

I relation to the posts from both of you, I think the most important part of the article is this one...

The search sequence will repeat whenever the model requires a reload.
e.g. If the viewport is cycled from VC/2D to external.

So FSX isn't constantly searching for stuff; only when it's needed.

Judging from the amount of aircraft you will encounter in the FSX skies and the pace at which FSX usually progresses, the performance penalty is negligible.


The question about whether to allow both .dds and .bmp or just one is interesting 'though.

[Bjoern]

A short investigation later...

Note that in the compilation procedure you are allowed to tick boxes such as "Use .BMP Extension" and "Use .DDS files" (both, if you want). Does this have any significance?

No. The model file...

What are the consequences for modellers, I wonder? Personally, I use ordinary bmp's (and sometimes jpg's) for mapping, but use dds in the sim itself. Should I, prior to final compilation, change filenames in the Material Editor so as to read xxx.dds, in order to shorten the search cycle?

...references the file used in the texture slots in the material editor. I've exported and compiled a FSX model with various combinations of the tick boxes of the export module, then opened the .mdl with Notepad. The textures referenced always stayed the same format as specified in the material editor.

So this means if you want to have the shortest search cycle, work with exactly the same formats in (G)Max and FSX. BMP and BMP, DDS and DDS.


But as I've said in my last post, the two extra cycles aren't really relevant since they're just used once to load the model.

[BASys]

Hi Folks

So FSX isn't constantly searching for stuff;
only when it's needed.

Correct.

But the important aspect is, when is it needed ?

Judging from the amount of aircraft you will encounter in the FSX skies
and the pace at which FSX usually progresses,
the performance penalty is negligible.

Location, traffic, & settings dependent.

If you flew around a small low fps-impacting airport with minimal/no traffic,
with your sliders maxed for that location,
then without adjusting any sliders,
flew into a fully populated Heathrow,
you'd likely notice an impact.

The question about whether to allow both .dds and .bmp
or just one is interesting 'though.

The model can have a mix of .bmp and .dds,
and there'll be minimal impact
as long as they match the model's filename.ext calls.

But as I've said in my last post,
the two extra cycles aren't really relevant
since they're just used once to load the model.

IIRC, then no.

For ? both SP1 ? and SP2,
the texture is only retained in VRAM
as long as its required in the viewport, (i.e. visible on screen).

i.e. its discarded when no longer required.



Again IIRC,
above is definitely the case for any -
- scenery object
- terrain texture
- AI traffic simobject
and also for switching between the user A/C's VC and external models.

Whether it applies to user A/C within the VC,
requires further investigation.



Another factor is -
it's not just two extra disk-searches per texture.

It'll usually be six extra disk-searches per texture
as you need to factor in the texture fallback mechanism.

Most liveries only contain repaint-specific textures,
the core textures being held in the fallback folder.



A further factor is -
As virtually every aircraft utilises multiple texture sheets.

You then need to multiply those six extra disk-searches
by the number of texture sheets being called.

e.g. 10 sheets == sixty extra disk-searches

I'm sure there's lots of models out there
which utilise more than 10 textures per VC model,
or more than 10 textures per external model.



One other aspect I've not investigated
is what happens in dawn/dusk lighting.

Are both _T and _LM sheets blended ?



HTH
ATB
Paul

[mjahn]

A short investigation later...
So this means if you want to have the shortest search cycle, work with exactly the same formats in (G)Max and FSX. BMP and BMP, DDS and DDS.

Except gmax rejects dds files, I just checked. So we can't fix it using gmax. Should we hex-edit the mdl file then, replacing .bmp/.psd by .dds? Of course FSDS users might tweak the xfiles ...

Is it worth the hassle? Strange that this hasn't come up before, no? Well maybe it has ...

[BASys]

Hi Folks

Except gmax rejects dds files,
I just checked. So we can't fix it using gmax.

The FSX GMax gamepack won't accept .DDS files on import,
but will generate .DDS, (if selected), when you export.

The key aspect is
that your model's texture calls
should match the texture types you supply.

HTH
ATB
Paul

[mjahn]

Yes that's absolutely right, BASys, point well made. With both options "Use .BMP Extension" and "Use .DDS files" checked on export the model file generates .dds file references, i.e. does not copy whichever source texture types are present in gmax. So I can happily do my mapping in gmax using jpg's and bmp's, and rest assured that FSX will be looking for dds's. Same goes for psd's I assume. Excellent.

(Note, on this view, there isn't any rule to the effect that you should use "same file types" in gmax and in FSX.)

And coming back to Crusader's original question re portover bmp's it would seem that bmp > dds texture conversion is an option after all, utilizing the improved capabilities of DXT5 dds (size and alpha resolution), without any loss due to searching - provided you hexedit the FS9 mdl file and replace all .bmp by .dds. That's the idea at any rate, certainly worth a try. Theoretically then, we could fit out an FS9 model with 2048 or even 4096 px textures? The mind boggles ...

[raptor19]

I have been watching the continuation of this thread with interest as generally with my FS9 portovers to FSX I do two things i.e.

1. Put all the common textures into a "shared" texture folder in order to reduce the overall file
size and then add a texture config file to each much smaller separate texture folder.

2. Change all the textures from .bmp to .dds.

After reading the posts and picking up much interesting information (thanks all and in particular to BASys and the very interesting observations by MJahn) I decided out of interest to edit the model files of one of my portovers with a Hex editor and change all the .bmp references to .dds. Just for the record I use HxD which is a free Hex editor and it literally only takes seconds to open a model file with the editor and then batch replace all the references from .bmp to .dds.

The next stage is to try the aircraft (in my case the Alphasim Crusader) and I was very pleased to note that everything worked perfectly with regards to the aircraft displaying clearly in FSX. It does now seem to load the textures slightly faster than before although the difference in the various flight conditions and locations that I have so far tried appear small without any really accurate measurement method. Still all very interesting stuff!

Regards,

John N

[Bjoern]

...

You've got me beat. I'm converting my AI traffic's textures back to .bmp. :|

Definately better than hand-editing every single model file with a hex editor.

As for user aircraft, it's definately better to work with uncompressed bitmaps (since they can be opened in Windows' image viewer on the fly) when developing.
Okay, you still can edit the .x output file but that's another extra step in the workflow. :/

Except gmax rejects dds files, I just checked. So we can't fix it using gmax. Should we hex-edit the mdl file then, replacing .bmp/.psd by .dds? Of course FSDS users might tweak the xfiles ...

You can tweak every exported .x file with Notepad and derivates and the tweak itself would consist of a simple "Find and Replace" operation on "BMP".
Notepad2 at least is capable of that.

I've just tried it on an exported .x file and XToMDL didn't complain. A look at the compiled .mdl reveals the success as well.
Couldn't test it in FSX yet since Imagetool is still batch converting nearly 10000 texture files.

(I'm working with Max 9 by the way.)

Just for the record I use HxD which is a free Hex editor and it literally only takes seconds to open a model file with the editor and then batch replace all the references from .bmp to .dds.

Thanks for the heads up. All the hex editors I'm using aren't capable of that.

[mjahn]

You can tweak every exported .x file with Notepad and derivates and the tweak itself would consist of a simple "Find and Replace" operation on "BMP".
...
(I'm working with Max 9 by the way.)

Sure, provided your program lets you get at the .x file. Unfortunately, Gmax doesn't.

If you get the .x file via Max or FSDS then Dave Nunez' FSDSTweak is the answer to all tweakers' prayers.

[BASys]

Hi Folks

You've got me beat.

Bjoern -
Not me, its an MS O/S thang.

I'm converting my AI traffic's textures back to .bmp. :|

As its a file-naming I/O issue,
and not a file-contents issue,

You could try an alternative approach -
Just rename your already converted files from .dds to .bmp
so they match the file calls.

N.B. I've not investigated whether there'll be any impact.

Definately better than hand-editing every single model file with a hex editor.

Definitely.



HTH
ATB
Paul

[raptor19]

You've got me beat. I'm converting my AI traffic's textures back to .bmp. :|

Definately better than hand-editing every single model file with a hex editor.

As for user aircraft, it's definately better to work with uncompressed bitmaps (since they can be opened in Windows' image viewer on the fly) when developing.
Okay, you still can edit the .x output file but that's another extra step in the workflow. :/

You can tweak every exported .x file with Notepad and derivates and the tweak itself would consist of a simple "Find and Replace" operation on "BMP".
Notepad2 at least is capable of that.

I've just tried it on an exported .x file and XToMDL didn't complain. A look at the compiled .mdl reveals the success as well.
Couldn't test it in FSX yet since Imagetool is still batch converting nearly 10000 texture files.

(I'm working with Max 9 by the way.)





Thanks for the heads up. All the hex editors I'm using aren't capable of that.

Bjoern,

Changing .bmp references in the model file is simple with HxD Hex editor. The editing process is a "batch" one so that with one click you can change all the texture references within the model file. The procedure is to open the relevant model file with HxD then select "Search". From the dropdown that appears. Then select "Replace" and make the appropriate entries to change from .bmp to .dds. Then make sure that you select "Replace All" and the process of conversion is instant. I have tried to illustrate this on the attached screenshot. If you have not got HxD then it can be obtained from http://download.cnet.com/HxD-Hex-Edi...-10891068.html . HxD also backs up the original model file just in case it isneeded again.

Regards,

John N

[mjahn]

As for user aircraft, it's definately better to work with uncompressed bitmaps (since they can be opened in Windows' image viewer on the fly)

I increasingly often work with jpg's because (1) when set at 100 % quality (an option few users know about) there is little if any difference between paint program original and compressed jpg version, and (2) because file size can have an impact on gmax RAM usage. Naturally, the jpg image isn't my original source file.

Don't take my word for it. Compare these two versions of Rob's DC-2 nose as per paintkit:





Which is the original bmp and which the compressed jpg here?

Solution: Right-click on the pic, try to save it, and check the extension of the proposed filename.

The difference is, the bmp weighs in @ 41,576 bytes, the bmp @ 217,398.

In a 2048 texture the difference is 12 MB vs. 2.1 MB.

Think about it.

You could try an alternative approach -
Just rename your already converted files from .dds to .bmp
so they match the file calls.

I'll stick my neck out and say it's highly unlikely to work. For one thing dds isn't bmp, for another dds is interpreted as upside down.