Dds Normal Maps Won't Open With Anything

[ascottk]

I've had this problem before with dds files but I was still able to open them with the gimp's plugin. Irfanview, 3ds max, the gimp, nor anything else will open the normal maps in dds format. I get an invalid compression error with the gimp.

[Dram]

Hmm, perhaps you can use DDS Convertor (should be v2 or something) to convert them to tga first? Then you should'nt have a problem.

[ascottk]

Hmm, perhaps you can use DDS Convertor (should be v2 or something) to convert them to tga first? Then you should'nt have a problem.

 

That program is buggy as hell on my system

[Dram]

Serious? that sux. It works fine on mine. Admittedly I have'nt used it for about 3 months now as I have'nt needed it but yeah.

 

What does it do?

[ascottk]

Serious? that sux. It works fine on mine. Admittedly I have'nt used it for about 3 months now as I have'nt needed it but yeah.

 

What does it do?

 

The built-in file browser doesn't refresh so I have to hunt & peck my way through images.

[Dram]

That's very strange. Mine works fine, so even if I delete something it updates and it disappears etc. Hmm. Well there's plenty dds converting progs, have you tried any others?

[ascottk]

I'm not terribly concerned about it for the moment but I'll take a look around for converters.

[SneaksieDave]

Same on mine. I also am not able to launch the game with DDS normalmaps, and instead need normal TGAs. Assuming this type of behavior will afflict a certain percentage of users, we decided to include 'em both.

[Dram]

Same on mine. I also am not able to launch the game with DDS normalmaps, and instead need normal TGAs. Assuming this type of behavior will afflict a certain percentage of users, we decided to include 'em both.

 

Uhh...he was talking about opening them in an editor such as gimp or photoshop etc.

[SneaksieDave]

Uhh... so was I. I cannot open our DDS normalmaps in anything on my system. Not PS, not nvidia command line tools, and not D3.

 

I also am not able to launch the game...

 

"Also" meant like, "in addition...", as opposed to "me too."

[Dram]

Oh right, sorry

[Gildoran]

I've been using Compressonator, as per Kat's tutorial for compressing D3 normalmaps. Apparently D3 requires an odd compression format: DXT5 with RXGB swizzling. That may be why photoshop isn't able to load it. Compressonator seems to be able to load/save in just about any format, however.

 

If you want to edit images that are in DDS format, you should instead edit the TGA versions of them in the hires repository, then compress them and put the DDS files in the darkmod repository. (in the case of normalmaps, edit the TGA in the darkmod repository, then compress it and put the compressed copy in the dds folder) Editing the DDS files directly is a bad idea, since I imagine it will lead to degrading quality over time.

 

The first time you compress images, make sure that D3 is able to load the compression format you're using, by removing the TGA versions of the images you compressed and testing out the textures. (don't assume D3 can read your compressed normalmaps just because it can read your compressed diffuse/specular maps)

[OrbWeaver]

Is the purpose of separating the TGAs from the DDSs to reduce the checkout times for developers, or to reduce the size of the final download when the mod is released?

 

If it is the latter, it would seem to me to be preferable to put all of the images in the darkmod tree as normal, but when the final PK4s are generated, zip up the textures/ and dds/ folders separately and give the downloader the option of skipping the textures.pk4 if they want a smaller DDS-only download.

 

SneaksieDave - I think I've figured out why you can't load the compressed normalmaps in D3. The unswizzling of RxGB compression takes place in the interaction.vfp fragment shader, which will not run on a Geforce 4.

[Gildoran]

Just out of curiousity, do you have any idea why ID chose RXGB? It seems like a strange way of swizzling things. Is it to give more bits to the red and green channels, since they're more important to normalmaps than the blue channel?

[Dram]

swizzling...wtf...

[OrbWeaver]

Just out of curiousity, do you have any idea why ID chose RXGB? It seems like a strange way of swizzling things. Is it to give more bits to the red and green channels, since they're more important to normalmaps than the blue channel?

 

I never really understood it. There seems to be very little information available on the format, as far as I can make out it just stores the R component in the alpha bitfields, which I guess gives more precision to the R component but doesn't affect anything else. Perhaps they considered improving the precision of a single colour channel to be better than nothing.

 

Here is some interesting information, from http://www.techspot.com/tweaks/doom3/doom-7.shtml

 

One thing of note on the normal map compression is that generally speaking if you DXT a normal map you get really crappy results. NVIDIA hardware supports palletized compression which yields good compression and normal maps retain hard and round edges really well. Unfortunately this compression does a poor job in other cases and you end up getting splotchy areas. ATI does not support the palletized compression so we needed a better solution. ATI had done some research on various methods of normal map compression and we ended swapping the red and alpha (which is zero in the case of a normal map) channels. This effectively allows the compression to do a much better job and is just 1 extra instruction in the fragment program to move the alpha channel into the red channel. The bottom line on what happens on each card is as follows.

 

All modern NVIDIA and all ATI hardware use the compressed normal maps in Medium and Low qualities with the sizzled components. NV10/20 hardware (GF4MX and GF3) uses palletized normal maps in Medium and Low qualities.

 

That is the answer to why Dave can only use one form of normal compression, and the rest of us can only use the other. They are not selectable options, they are graphics-card-specific requirements.

[SneaksieDave]

Curse you, swizzling!

 

O, unhappy day whenever FM authors produce DDS normalmaps only, thus screwing everyone with a GF4. You'd think, that if id was going to enable such a limitation/problem within their engine, they'd have put some kind of decoder in Doom3 to just convert the DDS versions to normal TGA.

 

Edit: Hay wait! That says MX. No MX shit here; I got the real GF4.

[OrbWeaver]

O, unhappy day whenever FM authors produce DDS normalmaps only, thus screwing everyone with a GF4. You'd think, that if id was going to enable such a limitation/problem within their engine, they'd have put some kind of decoder in Doom3 to just convert the DDS versions to normal TGA.

 

Which is why I am against distributing DDS without the corresponding TGA originals. Not only would a separate download be required for the NV20 users as you say, but the mission wouldn't display correctly if the respective r_use*Compression cvars are not enabled on the client machine (which for most people they won't be).

 

Edit: Hay wait! That says MX. No MX shit here; I got the real GF4.

 

Yeah, I am not sure about that. This is interesting: http://doom-ed.com/blog/2003/01/29/nv30-vs...evelopments-etc, I get the impression that the NV20 does support pixel and vertex shaders, but uses a vendor-specific interface rather than ARB_fragment_program and ARB_vertex_program.

[Gildoran]

Fortunately, we have TGA copies of everything in the hires directory, so if worse comes to worse, we can just copy them over to the main repository before release...

 

Currently we're using both DDS and TGA for normalmaps but only DDS for other images. How do you feel about using only DDS for non-normalmap images? (SneaksieDave doesn't have a problem with those)

 

From experimentation, I've noticed that if use_*compression is turned on, it tries to use the pre-existing DDS files, and only falls back on compressing the TGAs if it's unable to read the DDS files. There seems to be a quality difference between D3's compression and Compressonator's compression; using pre-existing DDS files looks much better, at least with regards to normalmaps. (if you don't provide a DDS, the normals end up with compression artifacts)

 

Wouldn't use_*compression be turned on by default in most machines? (isn't it turned on when in normal quality mode?) New Horizon and I were thinking of setting up the quality modes so that the highest quality level will use DDS or TGA files, whichever is available. I think that entails turning on use_*compression. (though there might be an uncompressed quality mode that would only be accessable if the user had downloaded the TGA texture pack)

[OrbWeaver]

Currently we're using both DDS and TGA for normalmaps but only DDS for other images. How do you feel about using only DDS for non-normalmap images? (SneaksieDave doesn't have a problem with those)

 

Fine in theory, although it might be better just to scale down the diffusemaps (which you can get away with quite easily, unlike normal maps) and include them anyway, just to avoid having to post release notes like "you cannot play this in Ultra mode" (which although not the end of the world, does impact the perceived "professionalism" somewhat).

[Gildoran]

Actually, New Horizon and I were thinking of changing around the quality modes... something like: high quality (behaves similarly to normal quality in D3, since it uses DDS files), medium and low (shrinking images by varying amounts - though that may require TGAs), and possibly ultra/uncompresed. (which would be greyed out if the TGAs weren't included in the release and the user hadn't downloaded a hires pack) Since the textures have higher resolutions, it'd probably be ok to have TDM's high-quality be equivelant to D3's normal quality.

[Domarius]

ascottk, try ACDSee to browse your images... should support DDS.