Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: newman on January 20, 2010, 04:35:28 am
-
At the suggestion of some of my fellow Diaspora team members, I've put this issue on the SCP mantis - http://scp.indiegames.us/mantis/view.php?id=2098 - and am now putting it here as well.
I was able to confirm that all fs2 builds I used (in this case 3.6.11 on Diaspora but the problem should be reproducable on any fs2 based project) will shade things differently on mirrored / inverted UVWs, when normal maps are being used (specs and diffuse only work fine). For example, say you just have a plane with a diffuse, spec, and normal map. Inside the plane, you have an inset rectangle. Since it's part of the mesh, it all renders like it's a single plane inside the game, as it should. However, if you invert the UVWs of the said rectangle (but make the texture match), the shading on that part will be completely different and won't match the surroundings.
In order to help with testing, I have created a test pof with speculars, normals, and shine maps. It is a simple cube, each of the 6 sides has one inset polygon. 4 of the inset polygons have inverted UVWs while the top and bottom ones do not. That way you can compare the sides, you should get two sides of the cube shading normally with the inset polygon seamlessly shading with the rest, and 4 sides where the inset polygon shades wrong and thus it's borders are clearly visible. Here's what the cube looks like:
(http://i48.tinypic.com/oz141.jpg)
Shots from the lab:
(http://i45.tinypic.com/32zu904.jpg)
Normal mapping - ON (lab)
(http://i48.tinypic.com/t54wwp.jpg)
Normal mapping - OFF (lab, same side, exactly the same angle)
In my noob opinion, what happens is the shading coordinates for each pixel get inverted alongside the UVWs. Or something.. coder people will know better :)
At any rate, I'm attaching the rar with the cube pof, diffuse spec and a normal map, and the table entry. The same rar is also attached on the mantis issue. Hopefully it'll help and my thanks in advance to anyone who tackles this thing, it's quite a big issue for us artists..
[attachment deleted by admin]
-
I might be wrong, but isn't that to be expected and not very feasible (or maybe even possible) to fix? When the normal map determines which way the normals of each pixel/texel point to, doesn't inverting the UVW's necessarily cause the normals to point in an opposite direction or something?
-
Your normal map is messed up.
Try this normal map, it works fine. (http://www.mediafire.com/?nznljyy33jj)
-
It does indeed. Ok, so how exactly should I save my normal maps then? I used the nvidia photoshop plugin to generate mine in dxt5_nm mode.
-
newman, is it just me or are you pretty new at this whole bussiness? the problem you described would occur with inverted polygons, maybe, on the off chance that you disable backface culling in the ship lab.
also... grey normal map, basically, what were you thinking when you were making it? normal maps arent standard grey maps :p
if you got msn, add me so i can give you some helpfull hints.
-
newman, is it just me or are you pretty new at this whole bussiness?
It's just you, been doing fs2 ships for years :)
Seriously though I used crazybump in the past back when it was free so I guess that didn't create any problems. Never looked at the specifics of saving it in other ways. HT provided some useful links and tips so I'll just have to dig around there. Thanks everyone I'll close the issue on mantis.
-
newman, is it just me or are you pretty new at this whole bussiness?
It's just you, been doing fs2 ships for years :)
Seriously though I used crazybump in the past back when it was free so I guess that didn't create any problems. Never looked at the specifics of saving it in other ways. HT provided some useful links and tips so I'll just have to dig around there. Thanks everyone I'll close the issue on mantis.
xnormal might also be usefull too.
-
(http://img37.imageshack.us/img37/944/seriesoftubes.png)
Obviously, this still happens with a model like that when the middle part of the mapping is flipped (flipped part mismatches the outside non-flipped part), but you'll notice that the series of tubes is still correctly lighted and flat regions are uniformly lit.
-
(http://img37.imageshack.us/img37/944/seriesoftubes.png)
Obviously, this still happens with a model like that when the middle part of the mapping is flipped (flipped part mismatches the outside non-flipped part), but you'll notice that the series of tubes is still correctly lighted and flat regions are uniformly lit.
which is exactly as it should isnt it?
-
also... grey normal map, basically, what were you thinking when you were making it? normal maps arent standard grey maps :p
DXT5nm maps are often called "grey" or "green" normal maps.
It depends on how the color channels are saved.
If the red and blue are filled with black, it's "green", if they're just a copy of the green channel, it's grey.
Just because most image viewers only show you the RGB channels at once, not the alpha channel.
And back to topic: I also think something is wrong with mirrored UVs and normal mapping in FSO.
-
I know something is wrong with them. Peoples perception of it.
When you look at the lightinig in F3 off the top of a Deimos or the underside of an Amazon Advanced, is that a problem with the engine/shaders, or the way the model got wrapped and textured?
When you do a ****e job on wrapping a model, don't complain when the engine doesn't fix it for you. Investigate and make sure you are doing things right according to published examples of how it should be done, not based on your personal opinion of "well, it works so it must be the right way" because chance are, it's not.
Granted, yes. FSO rendering code needs some improvements on what it does. What it doesn't necessarily need is a change in how it does what it does, because it is doing it right, for the most part. There is just so much tied up and tied into it that WHAT it can do is limited.
So when you end up seeing strange results based on what you are doing, don't automatically assume it's the engine that is ****ing it up, please. Find a better way to prove it and show case HOW it's ****ing it up so that we can have better information about where to look in the code to determine if it actually is.
-
Correct me if I'm wrong.. but aren't shader problems a matter for the upgrade team, the authors of the media packes? It has nothing to do with the engine.
PS: Yes there is a slight problem in the reference shaders. We fixed that issue in our custom shaders. I don't exactly remember what it was but I think the issue was that the light vector was multiplied with the tbm-matrix while in fact the view vector was supposed to be multiplied with its inverse (as far as I remember the inverse multiplication can be done in GLSL by simply switching the operands.) The difference was only visible under certain conditions of UV-mirroring and had to do with a wrong orientation of the tangent vector relative to the viewer or something when mirroring was used. Without mirroring the result is mathematically identical.
However this is a very RARE problem and usually doesn't show up because it requires a very specific kind of mirroring to be used which we had only with a very small section on maybe 2 of our ships.
The posts above speak of something totally different and we have checked normal mapping in VERY high detail and I can pretty much say with 99.9% certainty that (except for the very minor issue described stated above) normal mapping works perfectly in the engine.
About the grey normal maps... I agree with some of the previous posters... before complaning about any functionality that handles textures you might want to read up on what DXT is and how normal maps are stored in DXT5nm. There's a reason for the appearance.
-
well, excuse me for not using dxt5nm converter. i prefer to dick around with channels myself, instead of letting the tool do it, ergo i dont get the gray nm + alpha, i get the green + alpha when i'm finished, thank you very muchly.
-
Correct me if I'm wrong.. but aren't shader problems a matter for the upgrade team, the authors of the media packes? It has nothing to do with the engine.
Quite true, and I've been _more_ than happy to address any issue with anybody that is willing to work with me on tracking it down. Thanks to them, we have a passable compromise in the shaders that work on both nVidia and ATI cards (at least in as much as the ATI cards are willing to co-operate).
PS: Yes there is a slight problem in the reference shaders. We fixed that issue in our custom shaders. I don't exactly remember what it was but I think the issue was that the light vector was multiplied with the tbm-matrix while in fact the view vector was supposed to be multiplied with its inverse (as far as I remember the inverse multiplication can be done in GLSL by simply switching the operands.) The difference was only visible under certain conditions of UV-mirroring and had to do with a wrong orientation of the tangent vector relative to the viewer or something when mirroring was used. Without mirroring the result is mathematically identical.
However this is a very RARE problem and usually doesn't show up because it requires a very specific kind of mirroring to be used which we had only with a very small section on maybe 2 of our ships.
2 things. A: Could you define "reference" shaders please? Are you referring to the MediaVP shaders, sdr1119 shaders, or hery's original Unified shaders? (We have way too many sets around here.) and B: Would it be possible for you to share a look at them with me? While it is a rare problem, there are some small reports on the disatisfaction of the specular area of lighting with the current FSU Unified shaders, and if you are talking about what I think you are talking about, it wouldn't hurt implementing that change in the FSU shaders as well.
The posts above speak of something totally different and we have checked normal mapping in VERY high detail and I can pretty much say with 99.9% certainty that (except for the very minor issue described stated above) normal mapping works perfectly in the engine.
About the grey normal maps... I agree with some of the previous posters... before complaning about any functionality that handles textures you might want to read up on what DXT is and how normal maps are stored in DXT5nm. There's a reason for the appearance.
All that is necessary is normal data in Green and Alpha. Saving it explicitly as a DXT5nm is not going to automagically guarantee results. All of the FSU MediaVP normal map files are standard channel managed DXT5 files, for example. I've been getting frustrated lately by folks not seeming to grasp the appropriate utilization of the textures to varying degrees. You need to know about the formats that you save in, not just whether it's a -glow or -shine or -normal. (Quick test: of those three, how many use an alpha channel? If you said or defaulted to all three, fail)
-
Main texture - optionally, if transparency is needed, but that requires also the transparent poly's to be at the top of polygon/point hierarchy in the model, to ensure depth sorting works correctly... (or some such, thats the last explanation i know is sorta valid, altough i never used transparencies in fso)
Glow - completely unnecessary, and only adds size to the file
Shine - optionally, altough its a good idea to include one, as it controls how much the enviroment map reflects in parts.
0 = black = no env map shows
255 = white = env map shows completely, aka mirror effect
Normal - neccesary, since fso reads data from the green and alpha channels. red and blue are ignored.
Creation of fso-compatible normal maps, if going from a bluish one, is as follows select the red channel, copypasta it into the alpha channel, zero out (aka black fill) red and blue.
There are arguments presented by Zacam as to how does this affect normal map quality, and it has been confirmed by Herra Tohtori that there is a visually quantifiable difference between zeroed out red and blue channels and non-zeroed out. I forgot what the concensus was however, which one results in higher quality...
If you are starting from a heightmap, use XNormal or a part of nvidia photoshop plugin to generate a bluish normal map from the heightmap (i'm just calling them bluish)
ALSO, beware of bulk converters like the infamous "DDS converter", they tend to work most of the time, but when alpha maps are in the play, proper results cannot be guaranteed.
nVidia's texture tools are the way to go for proper conversion of textures from tga's (or whatever) to DDS.
And, if you channel manage yourself, you shouldnt use the DXT5nm preset under ANY circumstance.
tl;dr Know your tools and how to use them.
-
Normal - neccesary, since fso reads data from the green and alpha channels. red and blue are ignored.
ignored by the game yes, but it is important what's in them.
Creation of fso-compatible normal maps, if going from a bluish one, is as follows select the red channel, copypasta it into the alpha channel, zero out (aka black fill) red and blue.
If you save to DXT5nm with a working exporter, this should be done as part of the exporting process automatically.
if you do it manually you have to save DXT5, NOT DXT5nm. DXT5nm saving moves the channels around automatically. (That's actually the only difference between DXT5 and DXT5nm. The nm-exporter moves the channels first.
There are arguments presented by Zacam as to how does this affect normal map quality, and it has been confirmed by Herra Tohtori that there is a visually quantifiable difference between zeroed out red and blue channels and non-zeroed out. I forgot what the concensus was however, which one results in higher quality...
To achieve highest quality the red and blue channels must either be zeroed out or a copy of the green channel. As I mentioned any DTX5nm exporter does this automatically, not just the channel moving. If you want to do it manually, move the red to alpha, then either fill red and blue with black or white or copy the green channel to them.
If this isn't done and blue and red contain some kind of non-uniform data the entire DTX5nm process is for nothing. The reason for the invention of DXT5nm was, that DXT is fine for textures but has a too high loss-of-information rate for normal maps. So people came up with a trick. Since a normal vector is always of length 1 (normalized, hence the name) one only needs two of its components. the third can be calculated.
The quality problem of DXT5 is, that all three color channels are compressed together. This ruins precision. For a color that's not important, for a vector it is vital. Therefore one decided to store the first component (red/x) in the alpha (which is compressed by itself) and to keep the second one (green/y) as a color channel. Red was moved because red has a higher loss of information than the other two color channels. Blue is discarded since it is usually near 1 anyway. The other ones are mathematically more intersting. (The fact that the z coordinate of a surface normal is usually the biggest one is also the reason why normal maps appear to be bluish) Now to minimize information loss in the green channel one has to either zero out the rest or copy green to them. That is because the compression works somehow by calculating the difference between the channels. If the other channels are zeroes out or contain a copy of green, the difference only depends on the contents of green. Therefore the information loss is minimized.
So if you don't zero out red and blue you have wasted your time. You could just have stored it as a normal texture since you will have te exact same information loss (theoretically speaking, practically you cannot do that since the shaders will expect the DXT5nm format and will ignore anything in red or blue)
Even worse. YOu have increased the size of the texture to buy the additional alpha channel without gaining the improvement in precision. If you had saved it in DXT1 you'd have had the same bad quality in a smaller texture.
-
you are full of it, so instead of responding to your "post" and disseminate something i ALREADY ****ING WROTE. READ MY ENTIRE ****ING POST BEFORE YOU WRITE YOURS.
-
Uh. Ya'll are seemingly in an accordance with what each of you is saying.
So, what's the fuss?
KK is not full of it.
You know what you are doing.
End comm.
-
I think this thread has outlived its usefulness for now. KK, if you have a bugfixed shader set please get it to Zacam so he can check the MediaVP set. Thanks.