A Better Texture
Soul_Rider
Mod Bean Join Date: 2004-06-19 Member: 29388Members, Constellation, Squad Five Blue
Mod Bean Join Date: 2004-06-19 Member: 29388Members, Constellation, Squad Five Blue
NS2 material files (textures) are encoded in the microsoft .dds texture format using the NS2 builder. This builds files using the Nvidia DDS plugin. Paint.Net is a paint program which natively saves to .dds files, and originally being a microsoft student project, it benefits from using better .dds algorithms. I want to show in this post how to drastically reduce the texture file size, and maybe even improve the visual quality of NS2.
UI Improvements
I am going to start with a UI example. Unfortunately, as this uses transparencies, it doesn't quite show up correctly on the forums, but it does provide a good reference comparison between the source file, the actual NS2 builder version of the dds, and the paint.net dds.
As you can see, the paint.net dds file is much closer to the original PSD file. It has retained much more information and is less blurry. The most interesting thing about this is the file sizes:
Builder dds - 512KB
Paint.Net dds - 384KB
So for build menu icons and other UI elements, we can save file space and improve image quality. Lets move onto non-alpha textures.
Converting NS2 files
As I don't have any NS2 source files to work from, I took an NS2 dds file, and exported it out directly from paint.net. I was expecting a files size saving, but also some image quality loss, as going from dds-dds. The file I chose was materials\kodiak\kod_bark1
The first thing I am going to mention is the file size difference:
Builder dds - 1024x1024 1.33MB
Paint.net dds - 1024x1024 512KB
That is over a 50% saving. What is more, upon further investigation, at 500% zoom, it turns out the file is a 100% exact pixel for pixel replica of the original NS2 file. Same image quality, less than 50% disk space. this was verified by @Kouji_San
This is all well and good, but what I really need is access to a source file, so I can try and prove image quality improvements AND file size savings. @Kouji_San to the rescue again.
Custom Source Files
Kouji is just about to release his new Primal Fade skin, so he decided to build the dds with the normal Nvidia DDS plugin (used from photoshop rather than builder, but gives same results as same plugin), and Paint.net. Kouji overpaints the original dds files, so while they start off as the same quality as NS2, by the time kouji has finished, the image is a much higher quality. So let's see the results:
Beautiful work, and this is/will be available to download on the steam workshop now/soon.
As you can see, the Nvidia plugin is blurry, as seen in the textures in NS2 if you look closely at them, yet the paint.net version is sharper, containing a higher level of detail. Even I was surprised by this difference. So what about the file sizes on this one? Well, we have seen an improvement in image quality, and we also see an improvement in filesize, although not as large in the straight dds-dds conversion:
Nvidia DDS plugin - 2048x2048 - 2.73MB - 8MB (Total files for model)
Paint.Net DDS - 2048x2048 - 2.0MB - 6.0MB (Total files for model)
This saving is more in line with the saving received in the UI icons files, indicating improved visual quality does slightly impact on the savings made in filesize.
What Next?
I am currently working through all the textures used in kodiak, and am going to make a mod using straight paint.net converted dds files, to see if as well as install size, the changes have any noticable difference on loading times and texture memory usage. With the current Texture Memory issues, and the want to monetise through cosmetic skins, I think this is something that should be very seriously investigated. I will continue to update this thread with my findings.
Any comments and feedback are much appreciated.
UI Improvements
I am going to start with a UI example. Unfortunately, as this uses transparencies, it doesn't quite show up correctly on the forums, but it does provide a good reference comparison between the source file, the actual NS2 builder version of the dds, and the paint.net dds.
As you can see, the paint.net dds file is much closer to the original PSD file. It has retained much more information and is less blurry. The most interesting thing about this is the file sizes:
Builder dds - 512KB
Paint.Net dds - 384KB
So for build menu icons and other UI elements, we can save file space and improve image quality. Lets move onto non-alpha textures.
Converting NS2 files
As I don't have any NS2 source files to work from, I took an NS2 dds file, and exported it out directly from paint.net. I was expecting a files size saving, but also some image quality loss, as going from dds-dds. The file I chose was materials\kodiak\kod_bark1
The first thing I am going to mention is the file size difference:
Builder dds - 1024x1024 1.33MB
Paint.net dds - 1024x1024 512KB
That is over a 50% saving. What is more, upon further investigation, at 500% zoom, it turns out the file is a 100% exact pixel for pixel replica of the original NS2 file. Same image quality, less than 50% disk space. this was verified by @Kouji_San
This is all well and good, but what I really need is access to a source file, so I can try and prove image quality improvements AND file size savings. @Kouji_San to the rescue again.
Custom Source Files
Kouji is just about to release his new Primal Fade skin, so he decided to build the dds with the normal Nvidia DDS plugin (used from photoshop rather than builder, but gives same results as same plugin), and Paint.net. Kouji overpaints the original dds files, so while they start off as the same quality as NS2, by the time kouji has finished, the image is a much higher quality. So let's see the results:
Beautiful work, and this is/will be available to download on the steam workshop now/soon.
As you can see, the Nvidia plugin is blurry, as seen in the textures in NS2 if you look closely at them, yet the paint.net version is sharper, containing a higher level of detail. Even I was surprised by this difference. So what about the file sizes on this one? Well, we have seen an improvement in image quality, and we also see an improvement in filesize, although not as large in the straight dds-dds conversion:
Nvidia DDS plugin - 2048x2048 - 2.73MB - 8MB (Total files for model)
Paint.Net DDS - 2048x2048 - 2.0MB - 6.0MB (Total files for model)
This saving is more in line with the saving received in the UI icons files, indicating improved visual quality does slightly impact on the savings made in filesize.
What Next?
I am currently working through all the textures used in kodiak, and am going to make a mod using straight paint.net converted dds files, to see if as well as install size, the changes have any noticable difference on loading times and texture memory usage. With the current Texture Memory issues, and the want to monetise through cosmetic skins, I think this is something that should be very seriously investigated. I will continue to update this thread with my findings.
Any comments and feedback are much appreciated.
Comments
Can we get some details because so far this thread has more work shown on it than the trello topic has had in the past year.
This is coming from someone who has texture loading issues and is excited to see what kind of optimizations are in store.
Filesize reduction at what cost to image quality? Will you still be using the Nvidia DDS plugin, or will you be switching to a dds exporter with more modern algorithms, such as used in paint.net, to improve image quality and filesize?
Will you be working from current dds files, or will you be working from source files?
If from source files, can some of these be shared with me so we can do comparisons on techniques and results, to ensure the best option is chosen, rather than an option?
I thought NS2 was now supposed to be about open development, not cryptic one line 'don't bother doing this I'm doing something similar' type remarks
Also this new DDS plugin can actually convert the files within 2-3 seconds instead of the time it takes for ye'olde 2013 NVIDIA plugin, which is in between 10-15 seconds for 2048x2048 files. On a bloody Overclocked i5 2500K @4.5Ghz with ATI HD5870 nonetheless...
Sidenote:
Hehe "just about to release". Well nooooooooo t yet, this was more of a sneakpeak. Right now I am working on a skinpack for all aliens based on the old NS aliens (nostalgia aliens-like), but this time with more detail. And while I'm at it also fixing some texture errors in the original vanilla NS2 DDS files for this one, they kinda popped out like a sore thumb on this black fade
Primal aliens: These battle hardened veterans have been around since the beginning, indicated by their original skin color. Having endured a lot of battles over the years, they're now covered in scars
But I'll let you guys judge
1) Paint.NET is not functional in command-line format.
Why does this matter? The NS2 Build System. No human involvement is required in order for a full NS2 build to be created. The system automatically parses all of the Art Asset source files and builds them into the relevant "compiled" file format (dds, model, etc.). Any manual intervention by a person would be inherently prohibitive to productivity.
2) I ran a few tests using Paint.NET over a year ago, just as has been posted in this thread. And it was not of any benefit.
Why? Because all of the mip-maps need to be saved into the DDS files. This eliminates the need for Spark to _generate_ the mip-maps at runtime (CPU and time intensive). Part of the load-time improvements made some months ago leveraged this fact (lowest mip-levels are cached now).
As a verification test, I just went through the process of saving the ARC diffuse(albedo) map in the format that the Builder processes them. DXT1 (hence nvcompress "-bc1" option) is used for Albedo/Diffuse maps).
Via Paint.NET [arc.dds] (DXT1 format) with no mipmaps = 2101248 bytes
Via Paint.NET [arc.dds] (DXT1 format) with mimaps = 2797568 bytes
Via Photoshop and Nvidia DDS plugin [arc.dds] (DXT1 format) with mipmaps = 2797586 bytes
Via Builder and nvcompress (DXT1 format) with mipmaps = 2797568 bytes
As you can clearly see, Paint.NET is NOT any more efficient than nvcompress, it is in fact...identical.
There is only so much that can be done within a constrained file format standard (DDS file format).
And no, not generating the mip-map levels into DDS files is not the answer. Why? Because that would require Spark to generate those at runtime, thus increasing load times. Which is very, very bad.
The version of the nvcompress utility that utilizes the Crystal-lib improvements does net _some_ gains in terms of visual quality. However, in the context of how NS2 is actually played (fast-paced twitch), said visual improvements are very rarely noticed by players. And honestly, only help ultra (i.e. 4K) resolution still-shot screen captures.
Now, that is not to say there are specific texture maps that can be improved. The Exo and Female marine specular maps are prime examples. This is what @Obraxis was eluding to in his post. We are _very_ well aware some of the texture maps are inherently wasteful, and are taking steps to eliminate said waste. Just last week, Obraxis, myself, and Matso were reviewing how and why some optimizations haven't worked. On that note, just yesterday, I completed changes to the Art-Segment of the Build Pipeline required in order for texture optimizations to implemented.
P.S. To Modders: While you can save your DDS files manually in your mods (via Paint.NET or other programs), doing so has an inherent cost. All of the Mip-Map levels must be generated at runtime, and you have no control over that. If your mod has a large number of texture files, I strongly suggest you let Builder generate the DDS files as it will automatically generate the mipmaps (i.e. the texture at varying resolutions) in the DDS files, which will help decrease the amount of time your mod's assets take to load and cache.
@Soul_Rider Please do not presume that we are not aware of existing performance & resource utilization issues. Trust me, we very much are. I have done extensive research into this very topic, and if I had found a "quick-fix" as you proposed, it would have been implemented over a year ago. As simple as the Paint.NET method seems, it is actually a false-positive. Nothing in the wonderful world of software is ever "free". There is no quick-fix. There are no miracle cures to our resource ailments. There are always costs to any design decision. And we have made the determination it is more prudent to sacrifice installation footprint size, with client load-times. Hence, the larger, mip-map level calculated DDS files.
For the sake of clarity...I do not presume to be clairvoyant or all-knowing. If anyone has a _viable_ method to reducing runtime memory consumption, I'm always game to hear it. If it's something that can realistically improve the quality or efficiency of NS2, I'm all ears.
1) I was in a rush (working on 2 game projects at the same time leaves me with little time), but I wanted to give you a quick heads up so that you didnt spend all your time doing something which ultimately would be futile and done for you.
2) McGlaspie's post is much more informative and accurate than I could ever give.
Hope this makes sense.
First of all everyone can download the crystal lib based nvcompress tool here: https://drive.google.com/file/d/0B_AoHvDBSRoDMWlTNTdlUjFGeDA/view?usp=sharing (just extract it into your ns2 install folder) .
The major advantage of it beside a slightly better quality is that it's up to 10 times faster on PCs that do not have a CUDA compatible GPU (so all AMD/intel cards).
Beside nvcompress there is also amdcompress: http://developer.amd.com/tools-and-sdks/graphics-development/amdcompress/ which also tends to create slightly better results than nvcompress but can't open psd files.
Also as the OP pointed out correctly is that nvcompress has indeed problems with the newer version of the psd format. Therefor i recommend to save your source files as tga instead of psd to guarantee the best results
If you meant speed as in the context of "Units of Measurement-Scale", then...no, we're not even slightly considering such drastic changes. To do so, would impact damn near everything in the game. From LOS calculations to cyst-chain
FYI, the texture optimizations Obraxis is working on (and has been for over a week), will be _phased in_ (hue hue hue) into future builds as the optimizations merit it (safely).
We're always on the look-out for potentially memory savings.
Pertaining to PSD files, for the usage of mods....always, always, ALWAYS save PSD files in "Maximum Compatibility" format. Otherwise, you run into issues with ncompress (or other programs) not knowing WTF source files are (due to additional data in file header).
@GhoulofGSG9, I do have another question though, the DDSplugin (the slow and old one on non CUDA
1px or 0.5px smart sharpen (or unsharp mask) in the PSD and then having builder do it's thing, seems to kinda do the trick. It looks similar to the Paint.net increased detail, however with sharpening also comes that tad bit grittier look. At first glance though it looks a lot more detailed and appealing compared to that blurry vision we now have. Besides you can always FXAA the crap out of it anyways
Also it seems most spec maps in NS2 (if not all, I didn't check) are compressed using the DX5 method. Causing double the file size, because of that interpolated alpha, I assume. However when using builder/crystalnvcompress, they seem to be compresses into DX1 (1 bit alpha?) files. If that isn't a problem, there is a lot of filespace to save from there, something around 50% for all those x_spec.dss files
5.33Mb vs 2.66Mb for 2048x2048 files
All this talk about TGA files, they seem to be skipped by builder, for whatever reason (tried 16/24/32 bits/pixels uncompressed), I do see the reference in the builder_setup.xml. The "Maximum Compatibility" PSD files do work fine though
So it turns out, when you use Nvidia DDS plugin, it adds a 'blur' to gradients to help hide pixelation. But as you can clearly see from the first image, that blur instead of gradient makes textures a blurry mess.
So even if paint.net uses the same file size when using mipmaps, it does not blur the images. NS2 being blurry is something that has been complained about since day 1, and the cause it seems is the Nvidia DDS plugin.
Is there any chance that the new changes will at least use a plugin that doesn't blur gradients?
Also that can't run paint.net as a command line thing, are you seriously telling me you rebuild the entirety of NS2 materials everytime you make a new NS2 build? I could see a pretty big optimisation in your build process there...
---Edit---
My bad, didn't see the other compression tool Ghoul linked. Certainly an improvement over the standard builder version.
No, but we are NOT going to have McG re-save all the art assets BY HAND every time it DOES get rebuilt. That's ridiculous to suggest.
Also, I don't have a clue what you mean by blurring images... it certainly isn't doing any blur operations to the image.
Here's a small section of "models/props/refinery/docking_clerical_01". PSD on the bottom, dds on the top, magnified by 400%, nearest neighbor resampling. There is NO blurring going on here. Maybe paint.net is doing some kind of sharpening filter?
EDIT: and fyi, I chose this section of the image because when I set the top layer to difference, this section lit up the most... so this is just about the worst case scenario, at least on this image.
Also I made a gif of the fade's he made. The builder skin definitely is smoothed/blurred. This gif is certainly compressed but you can still see.
http://gifmaker.cc/PlayGIFAnimation.php?folder=2016020204W6ii1M35TEElm59Plm9EJk&file=output_YS0hVh.gif
This is stuff I'm making up so if someone knows better please correct me.
The "size" of the model doesn't really matter. Since the "size" of everything in the map is relative to itself you end up with the same thing when you scale everything at once. It's just a different arbitrary value of "size". This is why the units in the mapmaker are arbitrary, they are meaningful relative to one another, but not to anything else.
Some number (say 64) of units in the Editor might be something like 1 meter IRL, but that's only because that scale is observed based on the other models and reference points we have (namely the marine model).
Anyway, point is, there's two factors that determine a texture size. Dimensions and Complexity.
Super Simplified demo:
Size: 1Kb
Size: 4Kb (even though it's just adding in one more color for half of the image, note that it might be more than one color because gif is dumb and has to dither)
Similarly, Simply resizing the plain white gif up by 200%:
Size: 2Kb
Big games these days are mostly due to Massive texture files. Because Big textures look gorgeous. The higher the resolution of a texture, the less you realize it's a texture.
well if comparing gif vs gif, I guess it's legit right
Mostly demonstrating how dimension-size and complexity increase an image's filesize (regardless of format or compression methods and such things that make my overly simplified demo more complicated). Since Textures are images at their heart i figured it would show the point
No it's that Paint.net doesn't create mipmaps, which are needed for various resolutions, that is also the reason is probably retains more detail. It can use that extra dataspace for pixeldetails. The new Builder Crystalnvcompress comes close to the sharpness of Paint.net, can be automated and has mipmaps. So that's what the new way of doing stuff, you do need the nvcompress plugin in your NS2 folder for it to work though.
They have not yet done this conversion, cause there are a few DXT5 interpolated alpha's in the NS2 material folder that eat up more Mb's than they should, when they aren't even using an alpha mask. But all of em are done that way, cause some do use an alpha mask. That is another area where dataspace could be saved.
Time for 64-bits yo
After rereading the whole thread I got that.
Got that now, too.
Yeah you are right. How hard would this be btw. @McGlaspie ?
@Kouji_San, @ChrisStark
Paint.net DOES create mipmaps, it's just I wasn't ticking the box, hence why the file size was smaller.
When you turn MipMaps on in Paint.net, the file size is the same as builder, it is just better quality.
Hope that clarifies it for you.
Alright, but can ya batch it