[Zacam]

Actually, I don't use DTX5_NM at all, I manually channel swap after conversion to a Normal map via the nVidia Photoshop Texture Tools.

[Herra Tohtori]

I think you just reiterated what I just said. But they do not need to be saved specifically as DXT5_NM if the previously mentioned steps are taken.

It sounds like our starting points are in different places. Maybe just different software. When I use the compressionator it spits out a green texture (DXT5 xGxR) using just green and alpha.
Sounds like you end up with blue+red also using dxt5nm.

For someone new to this, dxt5nm has a better chance of success than channel swaping 

It's preferable that people know what they're doing from the beginning, even if they use tools such as selecting dxt5nm as the format... If they just blindly assume they HAVE to select the dxt5nm format as if it were the only thing that worked, they can easily end up in a situation where they save an already functional normal map again into dxt5nm format and, well, since it moves the red channel to alpha and populates red and blue with green channel content, they end up with the same information on all channels as follows:


RGBA -> GGGR -> GGGG

We've had this happen a few times in the past and almost invariably explaining how the system works with the channel information clears up the confusion.

Incidentally at one point it was possible to use TGA files as normal maps, as long as you had the red channel copied to the Alpha channel. I haven't tried this in a while though...

Regarding "green" and "gray" normal maps, the functionality is the same. However, there may or may not be some difference in how well the files compress, which depends largely on the compression utilities used. Using layman's logic it would make sense that loading unnecessary information to Red and Blue channels might affect the compression quality as opposed to full black channels which is just a bunch of zeroes in the file. It doesn't really affect filesizes, but it may have some effect on how the DDS compression algorithms manage to compress the file and how much or how little artefacts are generated in the file. Of course, uncompressed u8888 files aren't affected by this (their filesize is defined only by resolution, amount of channels and bits per channel value), but since we've had good experiences with the green variety of normal maps, we use them for the sake of consistency in the MediaVP's.

Sometimes a small amount of guassian blur can give a smooth bump using a lower intensity.

Experimenting is probably the best way of learning how different gradients work out with different normalmap filters. As a basic rule, sharp change in contrast (from black to white over one pixel change) will result in maximal angle on the normal map. A wider linear gradient will show up as wider linear slope on the normal map. Blurred gradients tend to produce rounded (bell or sine curve) normal map profile.

Also, 4 sample normalmap filter tends to create sharpest transitions, while 3x3, 5x5, 7x7 and 9x9 tend to produce more "rounded" or less detailed normal maps. My experience is that 4 sample and 3x3 work best for small, sharp details, while the 5x5, 7x7 and 9x9 will give better quality of the slope sampling at the expense of resolution. However, if you make the normal map on higher than final resolution, you can use the higher sample filters and the detail will still be preserved adequately...

I would upload sample images but my internet doesn't want to upload files (large packages won't upload, specifically). Perhaps later...

NB: I'm not telling this to you Water, I think you have a pretty good idea of what does what with normalmaps...

* Herra Tohtori takes a look at the Valkyrie

...so... yeah. The tips and tricks section of this post is aimed for Spoon et al.


EDIT:

Here's a few samples of what does what...

Base elevation map:



Here's a few samples about what different things actually do. Hard transitions from black to gray to white, as well as black to white directly; Gaussian 5 pixel blur on the right side; Radial gradient from white to black (linear from center to edge), and 30 pixel gaussian blurred version on the right side of it.

Basically the unblurred radial gradient shows up as a sharp straight-edged cone, whereas blurred one shows up like a rounded missile cover or something like that.


4 sample normalmap:




Worth noticing - change from white to black is equal to change from white to gray or gray to black. 4 sample filter doesn't really bother to take the brightness of the areas into account in this kind of cases. Also, when you zoom into the gradient stuff - especially the radial gradients - you'll notice a lot of artefacting, dithering and stuff like that, which will (if left alone) make the normal map rather fugly in the game itself. Resizing the map to half the size usually tends to smooth out artefacts like that (which is one of the reasons I usually make normalmaps at higher resolution than the final map will be...).

3x3 filtered normalmap:



Smoother on the gradients but slightly thicker on the sharp edges.

5x5 normalmap



Smoother still, thicker still. Same trend continues when the number of samples increases.

7x7 normalmap



Same old, same old...

9x9 normalmap



And this is where GIMP's normal map plugin ends it's offerings pretty much.

In general, blurring tends to lead to "smoothed out" lines and leaving hard contrast changes on the height map usually works better at least for me (unless I actually want smoothed, rounded normal map details... like pipes or dents).

[Water]

Using those methods allows you get parts the way you want. One normal map for deep recesses and another for lower intensity bumps and lines. Then merge them together. xNormal allows you to do this and I'd guess Crazybump would as well. There are three or so ways to do it in photoshop, some better than others.

[Spoon]

At the risk of sounding like a broken record: Thanks a lot!
Your post answered my questions before I even knew I was going to ask them  
Once i'm back from my 5 day trip to Sweden i'm going to put all this information to use and hopefully manage to produce a decent looking ship with pretty normal maps.  

On a unrelated note, i've been using your (Herra Tohtori) lighting settings for a while now (which I really like the look of in game).

[Herra Tohtori]

Using those methods allows you get parts the way you want. One normal map for deep recesses and another for lower intensity bumps and lines. Then merge them together. xNormal allows you to do this and I'd guess Crazybump would as well. There are three or so ways to do it in photoshop, some better than others.

I just stack the layers on top of each other and make #8080ff transparent on the top layer(s)...

Oh, and by the way. One quirk of the shader system is that the maximum acceptable range of tilt (delta-normal) per axis is apparently not 0-255 per channel (or #00-#ff in hex values), but instead 1-254. Extreme values on red or green channels end up producing black flecks of doom when the normal map is rendered (I suspect it has something to do with division by zero, or tangent of 90 degrees or something like that). Whatever the cause, you need to make sure that when you have the normal map in purple form, check the pixel colour values; if the values show either #ff or #00 for red or blue channels, you need to reduce the contrast a bit to fit the colours within the range that the shaders render correctly.

A simple act of reducing contrast by five or even three or two units does this rather handily. When this is done, re-check that the "level" colour is still at #8080ff. If it's something like #7979ff or #8181ff, it hardly matters - it's close enough to flat to not make any difference, but if it's remarkably lighter or darker it can cause strange things when flat surfaces appear tilted...

If you want to be perfectionist, probe the flat region's colour (let's say it says #7474ee), then add a #8080ff colour layer below the normal map, and make the probed colour of the normal map's flat range transparent, and the correct background colour will be returned. Merge and save, do the channel magic (or save as dxt5nm) and you're done.

[jacek]

I have a little request.. can somebody send me simple .pof file which use normal map 

thanks 

[Zacam]

Uh......wat?

Any pof will use a normal map. The normal map is not attached into the pof, but based on the texture name in the format of $pofdefinedname$-normal.dds.
The engine processes it because of the $pofdefinedname$ part of the file name.

Basically, whatever the basic texture name inside the model is, all of it's extension graphics will load so long as the the requisite -shine, -glow, -normal parts are present.

Example: Myrmidon model is Fighter2T-05. The basic LOD0 texture name specified in the POF matches the model name (though it does not always have to). So, all textures related to the Myrmidon have to be named Fighter2T-05-$type%.dds.

[Herra Tohtori]

Zacam, that explanation confuses me and I know what you're saying. Nob's don't now 'bout $pofdefinedname$ and %type% and other stuff like that... that's what always confuses the hell out of me in Linux man pages too, deciphering the command line options with all the brackets and additional stuff can be a pain in the arse if you don't know how to read the notation.

This is as simple as I can say it:

If a model uses a  texture called texturename, you can make it use shinemap, glowmap, normalmap and height map by adding an identifier to the filename of the texture, not the model itself.

Here's a complete list of how a full set of maps for a single model would look like:

model.pof uses a single texture, aptly named "texture". It will look for files named "texture" that have a suitable extension (DDS or TGA, basically). You should always use DDS files for textures (preferably compressed but uncompressed works just as well, it just uses 4-6 times more memory), so for the sake of simplicity I'm going to use that extension in this example. In testing phase you might want to use TGA files, and that works out just the same, since the texture name stored in the model doesn't even have any reference to extension.

Basic diffuse texture: texture.dds
Shinemap: texture-shine.dds
Glowmap: texture-glow.dds
Normalmap: texture-normal.dds
Heightmap*: texture-height.dds

* Also known as parallax map. Anyway I have to point out that height map is virtually useless for ships due to various problems in how it interacts (or doesn't interact) with the normal maps, so as a basic guideline... don't use this.

[jacek]

Hmm I don't know that in pcs I should load only one diffuse texture but I read Your instructions and made this steps:

1. In pcs2 I load model and one diffuse texture alfa.tga I saved this as alfa.pof
2. I copied alfa.pof to models/
3. alfa.tga and alfa-normal.tga to maps/
4. change ship.tbl
5. run game and I have only ship with diffuse texture.. btw. in lab viewer I don't have option "no normals"

I'm modeler so in this kind of problems I'm total noob   

[Herra Tohtori]

Hmm I don't know that in pcs I should load only one diffuse texture but I read Your instructions and made this steps:

1. In pcs2 I load model and one diffuse texture alfa.tga I saved this as alfa.pof
2. I copied alfa.pof to models/
3. alfa.tga and alfa-normal.tga to maps/
4. change ship.tbl
5. run game and I have only ship with diffuse texture.. btw. in lab viewer I don't have option "no normals"

I'm modeler so in this kind of problems I'm total noob   

For the normal maps to work, three conditions must be met:

1. You need a graphics processing unit capable of using them. Specifically, you need a Shader Model 3 compatible card and drivers. If some extensions are missing, the game reverts to fixed render pipeline, which results in normal maps not being available. Post your graphics card and drivers if problems persist.

2. You need the actual shader files for the game to use. If these are not present. then the game reverts to fixed render pipeline again. A version of these are found in the 3.6.10 MediaVP's, so if you have them activated, this shouldn't be the problem.

3. You need to enable normal maps on Launcher. Of course for this you need a build that supports them but I doubt that's the problem if you use a 3.6.10 build...


If you still have problems, first thing like I said post your GPU and driver configuration, and run a debug build, then post ..\FreeSpace2\data\fs2_open.log here (in code tags or as a link to pastebin.com) so we can see what's going on.

Also, with TGA file you need to make sure that the channels are correctly swapped (red copied to alpha), but otherwise it should work.

[jacek]

I think that the first point is no problem cause I have GeForce Go 7150m and on Nvidia website was written that it supports Shader model 3. I have 3.6.9 build and in luncher I have options like enable glow-map and shine-map but I don't have option enable normal-map. I think that the problem may occure in point 2 cause I have wing commender relase and I'm not sure that I have updated shader files so please tell me names of this shader files and location where I should copy them

[Herra Tohtori]

I think that the first point is no problem cause I have GeForce Go 7150m and on Nvidia website was written that it supports Shader model 3. I have 3.6.9 build and in luncher I have options like enable glow-map and shine-map but I don't have option enable normal-map. I think that the problem may occure in point 2 cause I have wing commender relase and I'm not sure that I have updated shader files so please tell me names of this shader files and location where I should copy them

Yeah, GeForce 7 series card should be good to go.

Version 3.6.9 is at least a hundred years old and does not have GLSL (shader) support and therefore no normal map.

Just for grabbing the shaders, I would at the moment recommend this version which is a bit newer than the ones in the MediaVP's and has some issues fixed (it doesn't really look that much different from the mediaVP's but it has small things like normal maps affecting environmental reflections and not just speculars). I recommend installing the shaders in their own mod directory so you can activate and deactivate them with -mod command line tag as desired.

Then get the 3.6.10 RC1 build and Launcher 5.5d. Wing Commander Saga Demo should work with 3.6.10 RC1... Just be sure to activate the Wing Commander features on the Gameplay options from Launcher.

[jacek]

I install everything as You say and now in lab view I have option "no normals" and after installation of this new shaders I have in game something like normal-map on my model but it was created by shader and base on diffuse texture so my normal map isn't loaded..

I upload You this test box with two textures..
http://www.sendspace.com/file/yu4ujg

If You have some time please try to check it in your FS engine and please let me know what is wrong..

[Herra Tohtori]

Okay, first of all I hope you aren't trying to use JPG file here and it's only used for transfer as a sample because of small size. If you try to use JPG as normal map it won't work, and even if it worked it uses the same amount of memory as TGA or uncompressed DDS file and has lower quality, so it's a lose-lose situation. Even using it in archived form is questionable since it already has compression in-built and therefore does not usually compress very much when it's archived...

As a rule of thumb it's usually better to use lossless formats at the developement phase (TGA or PNG come to mind first and foremost), although it matters very little in this case.

But to get into business: For the normal map to work, you need to save it in a format that FS2 can understand. JPG file has no alpha channel. Normal map system reads information from green channel and alpha channel. If you try to use a JPG file as a normal map, no alpha channel is found, therefore it will not work.

Also, a normal map that looks purple like that will not work, because the channels that hold the relevant normals information are not in correct order. Specifically, you have a full white alpha channel and the actual information is in red and green channels. What you need to do is to manipulate the file so that the red channel information is copied to alpha channel. What you leave in red and blue channels is up to you, but common practice is to either fill them with black (which is what I do) or copy the green channel information into them. The first method results in greenish transparent normal maps, while the second results in gray transparent normalmaps. Functionally, they don't really have any difference when you see them in the game.

Also, when you select the DXT5nm saving option (where nm means "normalmap"), it automatically does this for you and results in a valid, DXT5 compressed normal map. This is a handy way to get results of some kind into the game. But if you require higher quality, you will need to do the channel management manually. Additionally, it is good to know what exactly the program does and it's even better if you can, if needed, manually mimick the results, which is why I am posting the following image which hopefully clears the channel management issue a bit:



If you choose to manually manipulate the channels into correct configuration, you need to then save it to either TGA or DDS format (DDS with either plain DXT5 or u8888 [u=uncompressed]), but do not use DXT5nm, since it would just try to move the channels around for the second time and it would fail badly.


EDIT: I'm going to edit the image in a bit because of clarity reasons.

EDIT2: Edited.

[jacek]

Thank You very much Herra Tohtori  the reason is bad format.. jpg instead of tga. Thanks for all your explanation it was very usefull  please tell me can I take from those shadersvp only files which are responsible for normal-map shadering cause when I'm using all those shader files I have only about 20 fps..

[Zacam]

????

Interesting. As the engine adapts to loading the appropriate file any way based on what your launcher options are.

There is going to be a refresh soon, as part of solving the Installer issues and to accommodate any changes made for 3.6.10 EXE final.

[jacek]

Ok  I never used installer  but It looks like this shader need some optimisation...

[Zacam]

That has (hopefully) been done, and should be in the package Herra linked to you, it just may not be fully over riding the existing ones.

Aw crap. Rename the VP file 3610-ZuperShaderz.vp. It will then appropriately overwrite the shaders in MV_Core.vp.

[Herra Tohtori]

Hmm... If he's using them in a dedicated mod folder (like I suggested) rather than mediavps directory, then it's just a question of which is first on the mod command line.

-mod zupershaders,mediavps would work properly because zupershaders are loaded before mediavps shaders and thus take precedence.

-mod mediavps,zupershaders would not work because they would be loaded after mediaVP's, and the shaders in mv_core.vp would take precedence.

If you put the zupershaders in mediavps folder, the precedence is defined by alphabetical order. So a_zupershaders.vp would work fine, but zupershaders.vp not so much.

[jacek]

I am using extracted core files.. not vp's but I was looking for any shader files and In this old wing commander release I can't find anything it looks like it didn't use any shader except engine shader... BTW. I rename this ZuperShader to a_Zupershader but engine is still really slow...