Thats its really impressive.

Yes quite. I'm rather looking forward to seeing more of this.

Today I discovered that my version of Photoshop doesn't actually save PNG files with alpha/transperency. So that screenshot is actually the exact same texture set as in this image:

http://www.olynick.net/sr2/images/hiigaran-patchy.jpg

The only difference is that it's using the PBRModShipS shader with default (missing, so white fill) alpha channels. The only new texture layer in effect is Roughness and it had the Albedo saturation/lightness adjustment applied.

(Roughly the same view)
https://steamhost.cn/steamcommunity_com/sharedfiles/filedetails/?id=754048344

That should illustrate the difference in visual effect between the old non-PBR shaders and the new PBR shader.

png ignores what's in the alpha LAYER. You need to apply it as a LAYER MASK and apply the layer mask (as premultiplied alpha) It's the only way you can get alpha in a png.

That's... not true, in my experience. PNG files export with alpha just fine, at least in GIMP.

(Proof: Every time I committed an image to ABEM's GitHub repository, it was a PNG made in GIMP without any tinkering with the settings. Lots of alpha there.)

Originally posted by Dalo Lorn:

That's... not true, in my experience. PNG files export with alpha just fine, at least in GIMP.

(Proof: Every time I committed an image to ABEM's GitHub repository, it was a PNG made in GIMP without any tinkering with the settings. Lots of alpha there.)

He's not talking about basic transparency. That works just fine and I've had no problems making PNGs with clear bits in PS CS5 either.

He's talking about an actual alpha layer, which translates into transparency when saved with it included in the PNG. You cannot save a PNG with a discreet alpha channel. I'll see if I can get an image slapped together to demonstrate.

Exactly

Ok. Here's an illustrated example of the issue. I hope it clears things up.

http://www.olynick.net/sr2/images/png/png-cs5-alpha.jpg
The image on the left was saved using the default CS5 PNG format with an alpha channel in place. The black in the alpha channel should be 100 transparent, the white 100% solid - so the blue circle should have a hole in the middle. On the right is the saved image re-opened. As you can see, the saved PNG has discarded the alpha layer data and there is no change to the blue circle.

http://www.olynick.net/sr2/images/png/png-cs5-alphamask.jpg
Here, on the left, the alpha channel is instead applied as a mask directly to the layer (instead of as an alpha channel). On the right is the image re-opened. The mask for the hole has been preserved as the equivalent of alpha channel data.

I believe the above is what Jon was suggesting when he says you need a layer mask. It's a bit clumbsy to my mind but works.

The solution I've been using is to download a photoshop plug-in for PNG format. In my case I went with SuperPNG ( http://fnordware.com/superpng/ ) but any plug-in with the necessary functionality will do.

This is the results with a SuperPNG with Alpha 1 preserved:
http://www.olynick.net/sr2/images/png/png-superpng-alpha.jpg
I had to add the white background because SuperPNG did some odd stuff with the standard transparency/empty space when also using the alpha channel. On the right though you can see that the alpha channel data was preserved in the re-opened image. It should be essentially the same result as Jon's mask layer method, only I personally easier (less chance of confusion) to use the alpha channel. Just don't use the "Clean Transparency" checkbox... bad things will happen in game.

The other thing about SuperPNG is that it offers control over the compression of the PNG file. This is something that we haven't discussed here yet but I have with Jon. By default Photoshop uses roughly the equivalent of SuperPNG's max compression ("Smaller files"). The game has to decompress all PNG files when it loads them into memory and this has a computation time cost. When someone says they're seeing "white boxes" that slowly fill in when the game starts, this is because those white boxes are placeholders while the engine decompresses the image and gets it into memory. With uncompressed PNGs, there shouldn't be any decompression time so things should load significantly faster, although it will depend on how much compressed PNG data is in the loaded mods. Techincally, there is a good chance that compress/decompress routine is losing some data as well (probably some red and blue channel data, according to Jon), so it should be higher fidelity too (although you may not notice). The trade-off is that the uncompressed PNG files are often about x3 as large in filesize so the mod will be larger in filesize to download and store.

I don't know what GIMP offers for options for saving PNG files, but it's possible that it has compression and alpha layer preservation options built in.

If this post is clear enough that it makes sense to everyone reading, then I will probably add the above to a new section of the Shader Guide that covers it. I'm sure Jon will correct me if I mis-termed anything or got it wrong.

I should also note that having to use the alpha layer means that your saved PNG is going to have semi-transparency over most of the diffuse/color data once you save it. I haven't figured out a way to undo this, so it means that editing the PNG can be difficult after the fact. So far, I end up keeping a "master file" PSD for the image and then export a completed PNG version just for game use when I'm done. If I need to make changes, I go back to the PSD and then re-export the new game PNG version when done.

With uncompressed PNGs, there shouldn't be any decompression time so things should load significantly faster,

Hold on for a second here. When it comes to these types of things you can never tell without doing actual real-situation profiling, but speaking in general terms disk IO is quite significantly more expensive than cpu number crunching. Loading time wise I would definitely expect a smaller, compressed, png to load much faster than a larger one because of that.

Hold on for a second here. When it comes to these types of things you can never tell without doing actual real-situation profiling, but speaking in general terms disk IO is quite significantly more expensive than cpu number crunching. Loading time wise I would definitely expect a smaller, compressed, png to load much faster than a larger one because of that.

That's a good point Lucas. Maybe I'm getting a bit ahead of myself here and looking at it in too much of a vacuum. I haven't been able to do a proper test yet to see what the difference might turn out to be. A few files isn't going to tell me anything conclusive and I haven't yet got a large quantity of files set up to judge the impact. I suppose it would also depend on the disk in question, there might be more benefit on a fast SSD but more of a penalty on a slower HDD. I thought it at least warrented a mention though - floating it for discussion and consideration, if you will.

My current project has been done uncompressed so far but is well under half done yet. I may have to actually do a couple shipsets to get a clear picture. My game files and mods for play are all hosted on a Samsung 850 Pro, so I might see a net benefit or I might not. I'll also say that saving an uncompressed PNG file to my HDD work space (4TB 7200 rpm) is considerably faster than saving a compressed one (either SuperPNG or PS PNG) but doesn't account for a non-seqential diskspace or extensive use scenario. Opening also seems marginally faster with uncompressed but it's a much smaller difference.