Attention Mod-Makers

[HarvesteR]

Hi,

Just wanted to let everyone know about an important change done on the 0.11 version.

As of version 0.11, all part textures are compressed to DXT format on load, to enable mip-maps and improve performance.

However, one issue has been spotted with 3rd party parts.

On a few textures, the loaded map will appear to be tinged red. That is most probably due to byte-order encoding and alpha channels, so it\'s strongly recommended that all mod-makers check their texture maps, since it\'s very likely that this issue will appear.

We don\'t want to create an alternate way to load textures this time, since this is very important for improving performance.

We apologize for the inconvenience.

Cheers

[CarolRawley]

Oh dear.

[C7Studios]

I\'ve tried everything to get my files to export without going all pink. Tried DDS export from nvidia, photoshop 32 and 64 bit, all different png settings and bit depths. Indexed and non, export as BMP, turned on and off transparency. Even copied the textures to new photoshop files, installed gimp and tried exporting them using that.... Literally nothing works. Anyone having any luck with a method for fixing textures?

[Ninja]

Ill have a look into this after work today textures are a speciality. I shall post a pipeline here when I have it working correctly.

Is this a precursor to hopefully including normal mapping / more complex texture shaders in the future?

[Shedao]

I think I got it fixed!

I\'m not an expert in graphics but windows shows me for every stock part a bit depth of 32bit and for the now red modding parts only 24bit. When trying Photoshop and Irfanview nothing really helped but when simply loading a C7 texture into MS Paint and just save it again the bit depth goes to 32bit. --> loading KSP and it worked!

No idea if this is really an option but you could try.

edit: I tried a few different parts from different mods and all are showing normal colours

[Ninja]

Right I have just had a quick look, all my current parts are fine and showing correctly. C7 yours do indeed show a red tint, to fix this its pretty easy reload the .png files in photoshop, double click your 'background' layer to un-flatten the image then save out again as none interlaced. If you flatten the layers prior to exporting you will find that you will get the red tint issue

Hope this helps just re-saved all your files using this method and they are now showing fine.

[C7Studios]

Thanks for the help everyone. I can confirm that opening the textures in ms-paint and hitting the save button fixes it. I spent all last night trying to get this fixed and tried every way I could imagine. So simple! *face palm* Sincere thanks to everyone for all the help getting this fixed!

[Capt'n Skunky]

Harv, any chance we can get an update to the SDK PartsLab to use this new texture code?

Arrr!

Capt\'n Skunky

[Capt'n Skunky]

Ok folks, I have figured out how to get Photoshop to properly save the texture.

You MUST have a transparent part of the image. When you export as a 24-bit PNG and specify it\'s transparent, there MUST be some transparency somewhere or it reverts to a 24bit non-transparent image causing the red tint.

Since the bit order is ARGB, if there is no Alpha channel, it uses the next bit which is the Red bit of RGB and that\'s why everything is tinted Red!

This was driving me NUTS since I couldn\'t even get the MS Paint trick to work!

YAY!

Arrr!

Capt\'n Skunky

[Nanolathe]

I can confirm what Capt\'n says is correct. Every texture should utilise a 'background' that is transparent from now on, rather than Black or Magenta.

[Moach]

if you\'re using photoshop, i have a quick fix for ya!

i\'ve put together a 'droplet' (works kinda lika a batch shortcut deal) which opens the image, converts the 'background' to layer, then saves and closes

i found that if you save a PNG with a locked 'background' layer, PS will automatiically make it into a 24 bit - then you get problems (the infamous redbug)

but if you 'promote' the background to a layer (even if there are no others behind it) it\'ll assume there\'s a possible alpha channel there - and saves as 32 bit - solving the problem once and for all...

so while this only works if you hhave photoshop, it does make life a LOT easier.....

in simple steps:

1 - download droplet

2 - open KSP/Parts folder in windows explorer, search for *.png (using windows 7 here)

3 - set view mode to 'details', right-click the cllumn headers and open the 'select display items' thingy

4 - enable the 'bit depth' item, then have it sort your icons based on it

5 - get all the PNG\'s found under 24 bit, drag and drop onto the droplet icon

6 - have patience while photoshop grinds them down one by one....

7 - ??

8 - profit!

:cheers:

hope this helps :

[Capt'n Skunky]

So you\'re saying it\'s a locked BG that makes PS save as 24bit?

I need to test this. BRB

Nope, it has nothing to do with the BG being locked or not. You MUST have at least 1 transparent pixel or Photoshop\'s PNG export will use 24bit. As soon as I make 1 pixel transparent, locked BG or not, I get a 32bit image.

PS will not create a 32bit PNG if there are no transparent pixels.

Arrr!

Capt\'n Skunky

[Moach]

So you\'re saying it\'s a locked BG that makes PS save as 24bit?

it certainly appears to work that way :

it also seems irrelevant to whether or not you actually have transparent pixels anywhere... unlocking the BG into a layer is what defines it to 32 bit, i figure

and that\'s what the 'droplet' i posted before does - it simply takes each file, promotes the BG to layer and saves it again...

i tested it here and i get no more redbugs - all fixed :thumbup:

[Capt'n Skunky]

I just saved a PNG with a locked BG and 1 transparent pixel and it saved as a 32bit PNG.

You must have that transparency in order for an alpha layer to be exported making it 32bit.

Arrr!

Capt\'n Skunky

[Capt'n Skunky]

Okay, I think I have some more information on the issue. If you open a PNG file directly and use the 'Save' feature, it saves as a 32bit PNG regardless of transparency. If you use the 'Save for Web & Devices...', you need the transparent pixel.

Why there is a difference between the two save methods is beyond me.

EDIT: Arg. I just used the save for web & devices with a layered file, no trans pixels AND a locked BG and STILL got a 32bit image!!

Fucking Adobe! None of this makes any sense or has any logic to it.

Arrr!

Capt\'n Skunky

[Moach]

I just saved a PNG with a locked BG and 1 transparent pixel and it saved as a 32bit PNG.

You must have that transparency in order for an alpha layer to be exported making it 32bit.

Arrr!

Capt\'n Skunky

by unlocking the BG to layer, you get 32-bit regardless of having transparency anywhere (i have verified this by running a batch on ALL my parts which no longer suffer from any redbugs)

so you\'re saying that without unlocking it, you can also get 32 bit depth if you have at least one transparent pixel....

thats nice to know - it appears we have this alternative then :

[Shedao]

Fucking Adobe! None of this makes any sense or has any logic to it.

Then just use MS Paint

[Capt'n Skunky]

Then just use MS Paint

I can get Photoshop to save as 32bit, that\'s not the issue, it\'s trying to figure out why and what makes the difference.

Also, I do not have MS Paint installed on my PC. I\'ve no need for it.

Arrr!

Capt\'n Skunky

[Moach]

Okay, I think I have some more information on the issue. If you open a PNG file directly and use the 'Save' feature, it saves as a 32bit PNG regardless of transparency. If you use the 'Save for Web & Devices...', you need the transparent pixel.

Why there is a difference between the two save methods is beyond me.

EDIT: Arg. I just used the save for web & devices with a layered file, no trans pixels AND a locked BG and STILL got a 32bit image!!

Fucking Adobe! None of this makes any sense or has any logic to it.

Arrr!

Capt\'n Skunky

the 'save for web' thing appears to have a more thorough compressor which may do you a better job in squeezing every byte off the image file.... albeit, for PNG, there doesn\'t seem to be any aditional options compared to the traditional 'ctrl+s' method.... redundant perhaps - confusing, definitely ::

it indeed appears to be more realted to the 'background' status of the image.... if it reads 'layer 0', you get 32 - 'background', and it\'s 24....

meanwhile, the relevance of the transparent pixel remains elusive....

[Capt'n Skunky]

As you say, the Save for Web & Devices is designed to produce the smallest file possible. If there is no transparency, there is no need to save as 32bit so it saves as 24bit to make a smaller file. Now THAT makes sense.

I\'ve always used that option to get PNG files. It seems that using the standard 'Save' command and saving as a PNG will always produce a 32bit PNG regardless of any transparency.

Arrr!

Capt\'n Skunky

[Moach]

(...)

I\'ve always used that option to get PNG files. It seems that using the standard 'Save' command and saving as a PNG will always produce a 32bit PNG regardless of any transparency.

regardless of transparency - yes, but ONLY if you have the BG unlocked - if not, it goes 24-bit too....

so it seems if you\'re saving by ctrl+s, the bit depth is decided upon the status of the BG layer (you can\'t have transparency with it locked), while save-for-web goes by the presence of transparent pixels in the image or not as a rule.....

we appear to be reaching a veredict :thumbup:

[Capt'n Skunky]

Only if the lock is do to opening the PNG file. If you lock that layer manually AFTER unlocking the default lock, you get a 32bit PNG. There is something about that default lock, the little icon is even different. A default lock has a white body where a manual lock is all black.

Go figure.

Arrr!

Capt\'n Skunky

[Moach]

Only if the lock is do to opening the PNG file. If you lock that layer manually AFTER unlocking the default lock, you get a 32bit PNG. There is something about that default lock, the little icon is even different. A default lock has a white body where a manual lock is all black.

that\'s because the default 'lock' isn\'t really just a lock... when PS has a layer set as 'background', it enforces a rule of 'there will be no transparent pixels' to some sense...

if you double-click it, it offers to 'promote' the BG to an actual layer... and from then on, it allows 'end result' pixels to be less than fully opaque, i.e: allows transparent pixels in the final image

adobe livedocs says:

When you create a new image with a white background or a colored background, the bottommost image in the Layers palette is called Background. An image can have only one background layer. You cannot change the stacking order of a background layer, its blending mode, or its opacity. However, you can convert a background into a regular layer, and then change any of these attributes.

When you create a new image with transparent content, the image does not have a background layer. The bottommost layer is not constrained like the background layer; you can move it anywhere in the Layers palette and change its opacity and blending mode.

the presence of such a 'background layer' is the turnkey factor for 24 or 32 bit depth when saving PNG\'s - it being locked or not doesn\'t really matter, as long as it\'s not 'background'

:cheers:

[Capt'n Skunky]

Meh, why they have to make things so complicated! ;P

Arrr!

Capt\'n Skunky

[Moach]

hmm, the DL link for the droplet fix was broken - fixed it: www.moachcraft.xpg.com.br/whatnot/Moach_KSP_TextureFix.zip :cheers: