Author Topic: Normal map inverted UVWs shader bug  (Read 7502 times)

0 Members and 1 Guest are viewing this topic.

Offline newman

  • 211
Normal map inverted UVWs shader bug
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:



Shots from the lab:


Normal mapping - ON (lab)




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]
You know what the chain of command is? It's the chain I go get and beat you with 'til ya understand who's in ruttin' command here! - Jayne Cobb

 

Offline zookeeper

  • *knock knock* Who's there? Poe. Poe who?
  • 210
Re: Normal map inverted UVWs shader bug
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?

 

Offline Herra Tohtori

  • The Academic
  • 211
  • Bad command or file name
Re: Normal map inverted UVWs shader bug
Your normal map is messed up.

Try this normal map, it works fine.
There are three things that last forever: Abort, Retry, Fail - and the greatest of these is Fail.

 

Offline newman

  • 211
Re: Normal map inverted UVWs shader bug
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.
You know what the chain of command is? It's the chain I go get and beat you with 'til ya understand who's in ruttin' command here! - Jayne Cobb

 

Offline pecenipicek

  • Roast Chicken
  • 211
  • Powered by copious amounts of coffee and nicotine
    • Skype
    • Steam
    • Twitter
    • PeceniPicek's own deviantart page
Re: Normal map inverted UVWs shader bug
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.

Skype: vrganjko
Ho, ho, ho, to the bottle I go
to heal my heart and drown my woe!
Rain may fall and wind may blow,
and many miles be still to go,
but under a tall tree I will lie!

The Apocalypse Project needs YOU! - recruiting info thread.

 

Offline newman

  • 211
Re: Normal map inverted UVWs shader bug
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.
You know what the chain of command is? It's the chain I go get and beat you with 'til ya understand who's in ruttin' command here! - Jayne Cobb

 

Offline pecenipicek

  • Roast Chicken
  • 211
  • Powered by copious amounts of coffee and nicotine
    • Skype
    • Steam
    • Twitter
    • PeceniPicek's own deviantart page
Re: Normal map inverted UVWs shader bug
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.
Skype: vrganjko
Ho, ho, ho, to the bottle I go
to heal my heart and drown my woe!
Rain may fall and wind may blow,
and many miles be still to go,
but under a tall tree I will lie!

The Apocalypse Project needs YOU! - recruiting info thread.

 

Offline Herra Tohtori

  • The Academic
  • 211
  • Bad command or file name
Re: Normal map inverted UVWs shader bug


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.
There are three things that last forever: Abort, Retry, Fail - and the greatest of these is Fail.

 

Offline pecenipicek

  • Roast Chicken
  • 211
  • Powered by copious amounts of coffee and nicotine
    • Skype
    • Steam
    • Twitter
    • PeceniPicek's own deviantart page
Re: Normal map inverted UVWs shader bug


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?
Skype: vrganjko
Ho, ho, ho, to the bottle I go
to heal my heart and drown my woe!
Rain may fall and wind may blow,
and many miles be still to go,
but under a tall tree I will lie!

The Apocalypse Project needs YOU! - recruiting info thread.

 

Offline DaBrain

  • Screensniper
  • 212
    • Shadows of Lylat board
Re: Normal map inverted UVWs shader bug
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.
--------------------------------------------------
SoL is looking for a sound effect artist
Please PM me in case you want to apply
---------------------------------
Shadows of Lylat - A Freespace 2 total conversion
(hosted by Game-Warden)
----------------------------------

 

Offline Zacam

  • Magnificent Bastard
  • Administrator
  • 211
  • I go Sledge-O-Matic on Spammers
    • Steam
    • Twitter
    • ModDB Feature
Re: Normal map inverted UVWs shader bug
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.
Report MediaVP issues, now on the MediaVP Mantis! Read all about it Here!
Talk with the community on Discord
"If you can keep a level head in all this confusion, you just don't understand the situation"

¤[D+¬>

[08/01 16:53:11] <sigtau> EveningTea: I have decided that I am a 32-bit registerkin.  Pronouns are eax, ebx, ecx, edx.
[08/01 16:53:31] <EveningTea> dhauidahh
[08/01 16:53:32] <EveningTea> sak
[08/01 16:53:40] * EveningTea froths at the mouth
[08/01 16:53:40] <sigtau> i broke him, boys

 
Re: Normal map inverted UVWs shader bug
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.
« Last Edit: January 22, 2010, 08:15:22 am by KeldorKatarn »

 

Offline pecenipicek

  • Roast Chicken
  • 211
  • Powered by copious amounts of coffee and nicotine
    • Skype
    • Steam
    • Twitter
    • PeceniPicek's own deviantart page
Re: Normal map inverted UVWs shader bug
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.
Skype: vrganjko
Ho, ho, ho, to the bottle I go
to heal my heart and drown my woe!
Rain may fall and wind may blow,
and many miles be still to go,
but under a tall tree I will lie!

The Apocalypse Project needs YOU! - recruiting info thread.

 

Offline Zacam

  • Magnificent Bastard
  • Administrator
  • 211
  • I go Sledge-O-Matic on Spammers
    • Steam
    • Twitter
    • ModDB Feature
Re: Normal map inverted UVWs shader bug
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)
« Last Edit: January 22, 2010, 11:09:41 am by Zacam »
Report MediaVP issues, now on the MediaVP Mantis! Read all about it Here!
Talk with the community on Discord
"If you can keep a level head in all this confusion, you just don't understand the situation"

¤[D+¬>

[08/01 16:53:11] <sigtau> EveningTea: I have decided that I am a 32-bit registerkin.  Pronouns are eax, ebx, ecx, edx.
[08/01 16:53:31] <EveningTea> dhauidahh
[08/01 16:53:32] <EveningTea> sak
[08/01 16:53:40] * EveningTea froths at the mouth
[08/01 16:53:40] <sigtau> i broke him, boys

  

Offline pecenipicek

  • Roast Chicken
  • 211
  • Powered by copious amounts of coffee and nicotine
    • Skype
    • Steam
    • Twitter
    • PeceniPicek's own deviantart page
Re: Normal map inverted UVWs shader bug
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.
Skype: vrganjko
Ho, ho, ho, to the bottle I go
to heal my heart and drown my woe!
Rain may fall and wind may blow,
and many miles be still to go,
but under a tall tree I will lie!

The Apocalypse Project needs YOU! - recruiting info thread.

 
Re: Normal map inverted UVWs shader bug
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.

Quote
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.

Quote
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.

 

Offline pecenipicek

  • Roast Chicken
  • 211
  • Powered by copious amounts of coffee and nicotine
    • Skype
    • Steam
    • Twitter
    • PeceniPicek's own deviantart page
Re: Normal map inverted UVWs shader bug
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.
Skype: vrganjko
Ho, ho, ho, to the bottle I go
to heal my heart and drown my woe!
Rain may fall and wind may blow,
and many miles be still to go,
but under a tall tree I will lie!

The Apocalypse Project needs YOU! - recruiting info thread.

 

Offline Zacam

  • Magnificent Bastard
  • Administrator
  • 211
  • I go Sledge-O-Matic on Spammers
    • Steam
    • Twitter
    • ModDB Feature
Re: Normal map inverted UVWs shader bug
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.
Report MediaVP issues, now on the MediaVP Mantis! Read all about it Here!
Talk with the community on Discord
"If you can keep a level head in all this confusion, you just don't understand the situation"

¤[D+¬>

[08/01 16:53:11] <sigtau> EveningTea: I have decided that I am a 32-bit registerkin.  Pronouns are eax, ebx, ecx, edx.
[08/01 16:53:31] <EveningTea> dhauidahh
[08/01 16:53:32] <EveningTea> sak
[08/01 16:53:40] * EveningTea froths at the mouth
[08/01 16:53:40] <sigtau> i broke him, boys

 

Offline chief1983

  • Still lacks a custom title
  • Moderator
  • 212
  • ⬇️⬆️⬅️⬅️🅰➡️⬇️
    • Skype
    • Steam
    • Twitter
    • Fate of the Galaxy
Re: Normal map inverted UVWs shader bug
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.
Fate of the Galaxy - Now Hiring!  Apply within | Diaspora | SCP Home | Collada Importer for PCS2
Karajorma's 'How to report bugs' | Mantis
#freespace | #scp-swc | #diaspora | #SCP | #hard-light on EsperNet

"You may not sell or otherwise commercially exploit the source or things you created based on the source." -- Excerpt from FSO license, for reference

Nuclear1:  Jesus Christ zack you're a little too hamyurger for HLP right now...
iamzack:  i dont have hamynerge i just want ptatoc hips D:
redsniper:  Platonic hips?!
iamzack:  lays