[!] If you've released a texture mod, or plan to, please rea

Post » Sun May 27, 2012 3:03 pm

Well there you go then. Just about every normal I've seen in texture mods has them, but if they're not needed, a good chunk of memory could be saved on every normal.

This is incorrect. Mip maps are necessary for almost every texture. Removing mipmaps from normal maps would have a horrible effect on the clarity of the image. Not using mipmaps would result in a "shimmering" effect as seen on the image here: [img]http://www.shinvision.com/wp-content/uploads/2009/06/mipmapping-egz.png[/img]

If mipmaps are removed, the pixels on the left example would be constantly moving. This would be very noticeable on normal maps; from what I've seen normal maps included in most texture packs are done rather badly and are incredibly noisy.

I have posted a link to this thread on Polycount forums (it's a forum dedicated to video game art that is populated with game industry professionals), hopefully some of them will contribute to this thread. I appreciate the idea of making texture packs because I do believe that they suffer from being low resolution, but at the same time a vast majority of texture packs could look a lot better and could be done more efficiently.


Some random thoughts:

Unfortunately, creating texture replacers for objects that had their normal maps baked from highpoly models is pretty much pointless. Their diffuse textures can be tweaked, but modyfing their normal maps in Photoshop will often produce technically incorrect results. Objects like that rely on normal maps NOT to add surface detail, but to define the shading of a lowpoly object and bring it closer to its highpoly version. Upscaling normal maps and overlaying noisy detail on top of it can make it appear slightly sharper, but in most cases it will produce worse results than rendering the normal map at a higher resolution. Here's a massive article about normal mapping in current generation video games: http://wiki.polycount.com/NormalMapThe article also has links to tutorials that deal with the subject in more detail.


I will try to contribute to this thread every now and then. Compared to some of my peers, I may not have a lot of professional games industry, but looking at texture packs posted here I often spot plenty of simple mistakes that could be fixed pretty easily and elevate the quality of textures to a higher level.


Edit:

Here's a link that discusses DXT formats. http://wiki.polycount.com/DXT
There should be no difference in the colour reproduction between DXT1 and DXT5. The only major difference between the two is that the latter supports 8-bit alpha, at the cost of being twice the size of a DXT1 texture.
User avatar
Isaac Saetern
 
Posts: 3432
Joined: Mon Jun 25, 2007 6:46 pm

Post » Sun May 27, 2012 10:10 am

This is incorrect.
My apologies. Seems i was basing my assumption on PS not asking me if i wanted to load them as not having them. I changed my settings so the dialog appeared regardless and loading mip maps for normals does indeed show that vanilla normals have mip maps. My mistake.
User avatar
Lucie H
 
Posts: 3276
Joined: Tue Mar 13, 2007 11:46 pm

Post » Sun May 27, 2012 10:26 am

My apologies. Seems i was basing my assumption on PS not asking me if i wanted to load them as not having them. I changed my settings so the dialog appeared regardless and loading mip maps for normals does indeed show that vanilla normals have mip maps. My mistake.

Sorry if I sounded harsh; these things can be confusing so there's no need to apologise. I'm hoping to contribute what I know so its easier for you guys to make these things. I could use a good texture pack ;)
User avatar
joseluis perez
 
Posts: 3507
Joined: Thu Nov 22, 2007 7:51 am

Post » Sun May 27, 2012 3:30 am

How can a DXTC1 format saved with a 4 BPP format have remotely the same color pallette of a DXTC 3/5 with 8 BBPS. That's one of the MAJOR reasons the file size is considerably larger. Aside from there being an Extra channel being Alpha which is 8bit

8bit RGBA is essentially 24+8bit (32bit) texture... where as 4bit RGB is 12bit without alpha texture, 13bit if 1bit alpha is included.

I'm not expert at all..... but trying to understand the formats and how the differences are beyond just the very basic and exluded details...

So obviously there needs to be more information provided.
User avatar
TWITTER.COM
 
Posts: 3355
Joined: Tue Nov 27, 2007 3:15 pm

Post » Sun May 27, 2012 5:30 pm

How can a DXTC1 format saved with a 4 BPP format have remotely the same color pallette of a DXTC 3/5 with 8 BBPS. That's one of the MAJOR reasons the file size is considerably larger. Aside from there being an Extra channel being Alpha which is 8bit

8bit RGBA is essentially 24+8bit (32bit) texture... where as 4bit RGB is 12bit without alpha texture, 13bit if 1bit alpha is included.

I'm not expert at all..... but trying to understand the formats and how the differences are beyond just the very basic and exluded details...

So obviously there needs to be more information provided.

I don't think the 4bit and 8bit settings determine per pixel depth but rather over all image depth. When I load a dxt1 dds into PS and look at it's mode it still says 8bit rgb(which is the per pixel color depth). For a 4096 image to have full overall image 8bit depth, every single one of the nearly 16.8 million pixels would have to be a different color. I doubt too many textures are sporting more than a few hundred thousand colors.

I could be wrong but that seems like the way it is.
User avatar
Crystal Clarke
 
Posts: 3410
Joined: Mon Dec 11, 2006 5:55 am

Post » Sun May 27, 2012 5:39 am

it's not if a texture is able to use all 16.8 million colors.. it's if the saved texture makes use of any one of those colors that isn't available in the lower bit color pallette.

For example.. to simplify it, lets use 256 color pallette (8bit overal color) vs 65355 color pallette (16 bit overal color)

IF you save a 16bit color image in a 8bit color format, whatever colors don't match the 8bit pallette, is downsampled to the nearest color that does fit the 256 color pallette.

I do not beleive DXTC formats have a dynamic method of saving colors where the exact 32bit color pallette is maintained. Frankly i'm not aware of any such format that is capable of this. Although i think it would be ingenius for someone to make one allow for 32bit pallettes to be compressed into lets say a 4 bit pallette or 6 bit or 12 bit with ZERO color/shade impact. Would save a PILE for computational/size requirements.
User avatar
Lovingly
 
Posts: 3414
Joined: Fri Sep 15, 2006 6:36 am

Post » Sun May 27, 2012 2:48 am

I've noticed something about some of the texutre mods uploaded to Nexus. This post is to draw attention to good texture mod packaging practices, and generate discussion on techniques artists can use to create such mods.

Disclaimer: I'm not actually a texture artist myself, though I have some limited experience manipulating textures (re: MMM), so those more knowledgeable than me please feel free to chime in!


The Problem
```````````````

There are so many texture mods of all makes and models that have been released so far, some them fantastic and very professionally made. However I noticed, delving into the files, that some of them have textures saved in the wrong format, while others often forget mipmaps. And given Skyrim is already more demanding memory wise than its predecessors, it's more important than ever to keep an eye on memory usage when using texture mods. Unfrotunately texture mods, especially large ones, if saved using the wrong format can waste a lot of valuable video memory real estate.

When video memory reaches its limit, textures are streamed from main memory causing a huge performance loss. There may be users playing now with texture mods that don't realise the sudden FPS jumps and stuttering they're experiencing are due to taxed video memory on their cards.

But it's not just performance that takes a hit. Visual fiedilty can be sacrificed in order to stay within the limits of video memory. Users are told to run at a lower resolution, or turn down their AA, to recover performance -- but if the problem is a poorly packaged texture mod pushing you past your card's limit, then there may not be a need to do this at all. And if you're an author, keep in mind that if your mod is too demanding people may elect not to use it -- and if you made it to be shared and used, you're losing out from having your work bringing joy to the denizens of Skyrim (read: everyone!)


The Example
```````````````

How important is the correct format? By way of example I'm running a good 30 odd texture mods -- some are large replacers (landscape, NPCs, clothing, armor, weapons for example) while others focus on particular areas (objects, architecture etc). I've selectively chosen them to keep within my video card's memory limit -- 1536MB (Nvidia GTX 580).

Now there are a lot of amazing texture mods on Nexus, but a fair few I've seen so far don't always use the correct texture formats. A high-profile and popular mod (and I don't mean to single you out Chris!) that's done this is Chris2102's Whitrerun HQ Texture Pack.

By default this weighs in at 226M zipped, 487M uncompressed. However for whatever reason, while Chris has saved his textures containing an alpha layer and normalmaps correctly as DXT5, there's a large number of textures without alpha also saved as DXT5 when they can be saved as DXT1 for a significant memory saving. Re-compressing Chris's mod using DTX1 where needed gives us:
  • Default -- 487M
  • Recompressed -- 362M
A saving of 125M -- and remember no image quality is lost. DXT5 and DXT1 look the same, DXT1 just doesn't store alpha. If we presume the majority of these textures are loaded while walking around Whiterun, and if you're already at your video card's memory limit, not only would this prevent stuttering caused by taxed video memory, but it would also leave enough video memory to go from using no AA at all to 8xAA, or enabling SSAO, or using a mod like ENB. Or simply having more video memory to be able to use more texture mods!

And that's just with one mod.

Two other examples I've come across inlcude HQ Towns and Villages where recompressing DXT5 textures without alpha to DXT1 netted a 17M reduction in size (which, given all these textures are used at once, is a saving of 17M in-game) and the Blunt Weapon Enhancement Pack which goes from 90M to a tiny 12M, saving 78M -- here, you might not have all the blunt weapons loaded at once but each one gets a saving of around 3M, so if four different blunt weapons are loaded in a cell that's 12M saved. And, of course, the savings from each of mod add up.

Now before you get too excited, some of the major overhauls -- including the gigantic Skyrim HD and Vurt's Skyrim Flora are both compressed correctly, and there's no savings to be made. But I have, at least in my list, about 18 texture mods -- of just those that I've chosen to download -- that I found I could recompress to gain valuable video memory back.

As an aside, these are all factors that affect video memory usage in addition to textures being loaded:
  • Resolution
  • Anti-aliasing
  • Transparency anti-aliasing
  • Triple buffering
  • SSAO
  • Skyrim: uGrids and extended range tweaks
  • Post-processing mods like ENB
Look at this list as a trade off to what you can and can't have if your video memory is approaching its limit -- let alone the use of more texture mods as well. Thus, there's tremendous benefit for texture mod authors to correclty compress and package their mods -- it not only allow users to use your mod in the first place, but as an author the smaller file sizes means it's quicker to upload too. Win!


The Solution
```````````````

So if you're a texture modder, what are the guidelines to follow?
  • Remember to generate mipmaps (these help reduce GPU load)
  • Save textures as DXT1
  • Save textures with alphas as DXT3 or DXT5
  • Save normalmaps as DXT5
And
  • If you've uploaded a texture mod already, and you're not sure about the formats you've used, please check it and re-upload the mod if necessary.
Deathb0rn has conviniently linked a table of common texture volumes with the resulting file size after compression at various DXT levels -- this way you can usually tell what compression a texture has by its size. http://i255.photobucket.com/albums/hh122/deathb0rnwc3/Skyrim/ResolutionsandCompression.jpg The only thing to add to this is that when a texture is lacking mipmaps, it's usually 33% smaller than the sizes you see in the table.

Again my forays into texture creation are limited, so any input from the experts is welcome here -- for example what about bump maps? Specular? Can normal maps be compressed as DXT1 if they have no alpha? Please share your expertise!

Incidentally, I've been using AMD's The Compressonator to examine textures, generate mipmaps, compare textures and of course recompress them. It's a brilliantly easy tool to use, and its image comparison feature esepcially is fantastic (you can see at a glance what impact different compression levels will have). While I can't confirm this, from what I've read it apparently also produces better quality compressed textures than Nvidia's DDS tools, but I'll leave that for the experts to debate.


isoku chimes in:



Resources
````````````
The Compressonator -- http://developer.amd.com/tools/compressonator/pages/default.aspx
Oblivion DDS guide -- http://cs.elderscrolls.com/index.php/DDS_Files
Wikipedia on DXT modes -- http://en.wikipedia.org/wiki/S3TC
Very Good post I hope it gets sticked somewhere togehter as some other posts about performance ...
User avatar
Hazel Sian ogden
 
Posts: 3425
Joined: Tue Jul 04, 2006 7:10 am

Post » Sun May 27, 2012 11:13 am

it's not if a texture is able to use all 16.8 million colors.. it's if the saved texture makes use of any one of those colors that isn't available in the lower bit color pallette. For example.. to simplify it, lets use 256 color pallette (8bit overal color) vs 65355 color pallette (16 bit overal color) IF you save a 16bit color image in a 8bit color format, whatever colors don't match the 8bit pallette, is downsampled to the nearest color that does fit the 256 color pallette. I do not beleive DXTC formats have a dynamic method of saving colors where the exact 32bit color pallette is maintained. Frankly i'm not aware of any such format that is capable of this. Although i think it would be ingenius for someone to make one allow for 32bit pallettes to be compressed into lets say a 4 bit pallette or 6 bit or 12 bit with ZERO color/shade impact. Would save a PILE for computational/size requirements.

I just did a test and textures saved using all of the following settings...

DXTC1 4bpp | no alpha
DXTC1 4bpp | 1 bit alpha
DXTC3 8bpp | explicit alpha
DXTC5 8bpp | interpolated alpha

...each have 32bpp color depth.

I think this is what makes the DDS format so viable. A DXTC1 compresses the image size down to 4 bpp size but retains the full 32bpp color pallet.
User avatar
Facebook me
 
Posts: 3442
Joined: Wed Nov 08, 2006 8:05 am

Post » Sun May 27, 2012 12:15 pm

Great post with some essential info and very good advices there, Mart! :biggrin:

I have some reservations about switching every texture that doesn't need a transparacy to DTX 1 though, as every form of DTX serves a different purpose. On that note, anyone know if DTX1 is more similar to DTX3 or DTX5? If I do remember correctly DTX5 handles transitions more smoothly, while DTX3 is more precise. It might not be a world of a difference, but I'd still like my textures to come out in the best way they can.
User avatar
latrina
 
Posts: 3440
Joined: Mon Aug 20, 2007 4:31 pm

Post » Sun May 27, 2012 4:33 am

Great post with some essential info and very good advices there, Mart! :biggrin:

I have some reservations about switching every texture that doesn't need a transparacy to DTX 1 though, as every form of DTX serves a different purpose. On that note, anyone know if DTX1 is more similar to DTX3 or DTX5? If I do remember correctly DTX5 handles transitions more smoothly, while DTX3 is more precise. It might not be a world of a difference, but I'd still like my textures to come out in the best way they can.

Here is a small article that explains it:

http://www.fsdeveloper.com/wiki/index.php?title=DXT_compression_explained

There is a difference between DXT1 and DXT3 even in the RGB channel, but it is so tiny that it's not worth it - I'm not even sure it's better, just different. Save your texture in both formats and compare - you will see that a few pixels are different, but both are compressed and DXT3 doesn't look better than DXT1. If you want to get the best result and if you don't care about filesize save as 5.5.5 or even 8.8.8 (you will see quite a noticeable difference when you compare to DXT if you save in these formats). That is not recommended due to the much larger file size though. Usually that is only useful for normal maps that get a lot of artifacts when saved in DXT format - sometimes it's better to downsize the normal map and save uncompressed (or with less compression) instead of getting a lot of ugly artifacts. Probably you've seen the 'no more blocky faces' mod, which is quite popular. The artifacts on the face normals were caused by DXT compression, which happens quite often on normal maps. Bethesda still saves all normal maps compressed, no matter what. For diffuse maps I don't see the point as smaller texture means less detail and more blurriness while same size uncompressed means a huge file size. Plus DXT isn't that obvious when used for diffuse maps.
User avatar
Sheeva
 
Posts: 3353
Joined: Sat Nov 11, 2006 2:46 am

Post » Sun May 27, 2012 4:20 pm

Ah, thanks for the info, Phitt. That article explains it very well, adding it to my bookmarks for reference.
User avatar
Mandi Norton
 
Posts: 3451
Joined: Tue Jan 30, 2007 2:43 pm

Post » Sun May 27, 2012 8:37 am

http://cs.elderscrolls.com/index.php/Choose_the_right_DXTC_compression_algorithm
http://en.wikipedia.org/wiki/S3_Texture_Compression
This may help clear things up a bit.
edit: kasdhfkjsdhfh i'm not awake enough to deal with whatever is going on with the links right now.
User avatar
Kelvin
 
Posts: 3405
Joined: Sat Nov 17, 2007 10:22 am

Post » Sun May 27, 2012 7:17 am

http://cs.elderscrolls.com/index.php/Choose_the_right_DXTC_compression_algorithm
I can't count the number of times I have read that article though admittedly it's been a couple years.
User avatar
City Swagga
 
Posts: 3498
Joined: Sat May 12, 2007 1:04 am

Post » Sun May 27, 2012 6:03 am

So is there a way us end-users can do any of these things on our already installed (and possibly never to be fixed mods)?
  • Save textures as DXT1
  • Save textures with alphas as DXT3 or DXT5
  • Save normalmaps as DXT5
Is there a potentially a script we can run to anolyze every file and compress as necessary?
User avatar
Lew.p
 
Posts: 3430
Joined: Thu Jun 07, 2007 5:31 pm

Post » Sun May 27, 2012 12:35 pm

So is there a way us end-users can do any of these things on our already installed (and possibly never to be fixed mods)?
  • Save textures as DXT1
  • Save textures with alphas as DXT3 or DXT5
  • Save normalmaps as DXT5
Is there a potentially a script we can run to anolyze every file and compress as necessary?
http://www.gamesas.com/topic/1330264-ddsopt-of-use/
User avatar
Syaza Ramali
 
Posts: 3466
Joined: Wed Jan 24, 2007 10:46 am

Post » Sun May 27, 2012 4:45 pm

You will have to manually examine your mods once again, compare the original vanilla textures to the modded version and adjusted the modded version has needed once again. That really is only way to do it once again..

But then again I could be wrong ...Thanks Worm..
User avatar
Rachel Cafferty
 
Posts: 3442
Joined: Thu Jun 22, 2006 1:48 am

Post » Sun May 27, 2012 1:44 am

I have a question about the enchanted item graphical effect that perhaps one of the guru's here could answer. How exactly is it mapped to the weapon or item? I've experimented with changing it, but I'm not happy with the results I've been getting. The alpha channel seems to get plastered all over, in the oddest positions.
User avatar
Janine Rose
 
Posts: 3428
Joined: Wed Feb 14, 2007 6:59 pm

Post » Sun May 27, 2012 7:21 am

DXT1 - 1 bit alpha is also a choice if you have an alpha channel with only black and white (aka no grays).

This is not true. Oblivion did switch shaders based on the DXT-format and for Oblivion DXT1 means "no alpha", not "1-bit alpha", and it uses the shader which doesn't use the alpha-information. The exception is the UI, there you indeed can use "1-bit alpha", but not for assets used in the game itself. Also, the meaning of "no alpha" changes is you have a color-map or if you have a normal-map. For color-maps the alpha-channel may contain transparency, so neutral alpha is white. For normal-maps the alpha-channel can contain specularity, so neutral alpha is black. For color-maps the alpha-channel may also contain a heightfield, so neutral alpha is whichever solid grey (it's a difference-map, no differences, no effect, only waste of GPU-cycles).
If this still holds for Skyrim we have to find out. Anyway, that's what DDSopt is about, don't memorize this stuff, let a tool do it.
User avatar
Danny Blight
 
Posts: 3400
Joined: Wed Jun 27, 2007 11:30 am

Post » Sun May 27, 2012 7:01 am

Thanks for the link to that program Martigen, I just saved over 100mb of space on my harddrive by compressing textures that were saved in RAW or 8.8.8.8 formats when they had no need to be.

Not to mention the performance increases, even though I've got a beast of a machine and haven't noticed the problems yet, why invite them?
User avatar
SiLa
 
Posts: 3447
Joined: Tue Jun 13, 2006 7:52 am

Post » Sun May 27, 2012 12:43 pm

This is not true. Oblivion did switch shaders based on the DXT-format and for Oblivion DXT1 means "no alpha", not "1-bit alpha", and it uses the shader which doesn't use the alpha-information. The exception is the UI, there you indeed can use "1-bit alpha", but not for assets used in the game itself. Also, the meaning of "no alpha" changes is you have a color-map or if you have a normal-map. For color-maps the alpha-channel may contain transparency, so neutral alpha is white. For normal-maps the alpha-channel can contain specularity, so neutral alpha is black. For color-maps the alpha-channel may also contain a heightfield, so neutral alpha is whichever solid grey (it's a difference-map, no differences, no effect, only waste of GPU-cycles).
If this still holds for Skyrim we have to find out. Anyway, that's what DDSopt is about, don't memorize this stuff, let a tool do it.
In Oblivion we had many assets that used DXT1a for 1bit alpha, and it worked fine. Is this to say that behind the scenes the format was somehow promoted to another?
And I disagree, I think it's useful to know these things, so assets can be created properly at the start, rather than going through a compression routine a second time.
User avatar
Franko AlVarado
 
Posts: 3473
Joined: Sun Nov 18, 2007 7:49 pm

Post » Sun May 27, 2012 3:56 am

Aha! this explains why the transparency maps for my rain drops wernt displaying properly.
User avatar
James Hate
 
Posts: 3531
Joined: Sun Jun 24, 2007 5:55 am

Post » Sun May 27, 2012 2:30 am

I'm gonna play Johnny One-note here for a minute. I've been trying to "fix" a mod that seems to work for almost everybody else and does nothing for me. I don't know if it's something unique to my install (which I've re-done) or machine, but I tried to open the DDS files with The Compressonator and could not open them. If I try a batch compress it skips them, saying it can't decompress them.

The DDS files are quite small, 9k in size, and when I open them in Nifskope I can see a very small texture map. It's referenced by a mesh file and stored in a custom directory under the Textures directory.

The mod is the "Glowing Ore Veins 300" mod at http://www.skyrimnexus.com/downloads/file.php?id=193

It doesn't really need compression for size, but I've tried just about everything else to get it to work.

I tried replacing one of the textures with a candlelight texture from another pack (that opens in the Compressonator), to no effect, so it may not be the textures that are the problem. The other texture works as a replacer for the texture it was intended for. I don't know if the DDS file contains internal identification or is just a texture so that may have been a silly attempt.

If anyone has any obvious ideas or if you're just curious about an oddity, I'd appreciate the help. Otherwise, carry on as normal. Thanks.

PS it's a cubemap, which is apparently different in significant ways. I am at the wrong spot on the learning curve here.

PPS Not trying to diagnose the issue here, just whether the DDS files are an issue.
User avatar
Michelle Serenity Boss
 
Posts: 3341
Joined: Tue Oct 17, 2006 10:49 am

Post » Sun May 27, 2012 12:55 pm

SIlly dupe, deleted.
User avatar
Amanda Leis
 
Posts: 3518
Joined: Sun Dec 24, 2006 1:57 am

Post » Sun May 27, 2012 7:30 am

can i "resave" the texture mods with microsoft paint? i know absolutetly nothing about textures or meshes so i would like to do this myself if its fairly straightforward and simple. otherwise its not a big deal since i have a 3GB card.
User avatar
Amy Masters
 
Posts: 3277
Joined: Thu Jun 22, 2006 10:26 am

Post » Sun May 27, 2012 3:11 pm

Thanks for this thread. It has helped me better understand the various DDS formats.
User avatar
Carlos Vazquez
 
Posts: 3407
Joined: Sat Aug 25, 2007 10:19 am

PreviousNext

Return to V - Skyrim