[Scooby_Doo]

I have been having "issues" with normal maps and being symmetrical. 

After doing some testing I've found that if the two symmetrical sides are touching AND if you've flipped (via manually or through symmetry modifier) the uvmap then you'll get an odd normal error.

Instead of having the shine appear uniformly over the entire plane, it'll just appear on one half of it and never on the other. Now if the uvmap isn't flipped or the one side as a totally different uvmap section then everythings ok.  Or if it is flipped and neither piece is touching then it's also ok. 

And no, according to Keldor symmetrical normal mapping is suppose to be supported correctly (don't remember if it's tangent space or object space).

I'll upload the sample model to those who need to see the error.

[Zacam]

Or you can look at most of the mediavp models in F3 (Deimos, Amazon Adv to name two off the top of my head) to see it in action.

Quadratic lighting makes it look REALLY nice. In F3. Don't play with it though.. *shudder* Unless you like being blind.

PITA, but the recommendation would be: don't symmetrically flip/mirror UV faces or the normal.

See, the shine factor probably IS there.....and it is probably facing IN to the model. But I could be wrong on that.

Good example of that idea (if that is in fact the case) is the nameplate on the Aeolus.

[Scooby_Doo]

Keldor believes its something to do with the vertex normals not being correct.  And it's not a shine map issue, turn off normal map and the problem goes away.

[Herra Tohtori]

taylor mentioned something about this some time ago.

Basically it's related to how the majority of models uses mirror symmetry on their UV maps, which means that moving from starboard side to port side, the normal map's normals information needs to be reversed, because if you just mirror the normal map like a normal texture and light still comes from the same direction... it's going to make bumps on one side and recesses on the other side of the ship.

Making the shaders deal with the mirror symmetric UV coordinates correctly requires tricky magic (I don't know how many goats have been sacrificed) and has an unfortunate result of causing that little specular lighting problem.*

Good thing is that it's only really visible on large, flat and shiny surfaces, and majority of FS2 ships with large surfaces also has relatively dark shinemaps.


*Although I don't know if it's the shader system in the engine that does this or the shaders themselves.

[Zacam]

Keldor believes its something to do with the vertex normals not being correct.  And it's not a shine map issue, turn off normal map and the problem goes away.

Sorry, I did not mean to confuse. I know the problem is not inherently with the shine map. I am saying that the effect is somewhat shine related because, as Keldor mentioned, that the vertex normals not being correct. I was trying to say that the appropriate effect is probably facing inwards on the problem side, not outward. And the side that is facing outwards is having issues when glFrontMaterialShininess is being applied/calculated.

[Scooby_Doo]

Ya he mentioned that with one of his custom shaders, the vertex normals don't look quite right.  Also in one of my testing with two symmetrical object connected with each other, but using seperated vertices (i.e. two vertices on the same spot, one for the left side, other for the right side) the issue still shows up.  I'm wonder if PCS2 is combining the vertices into one.  Perhaps thats where the vertex normals are getting messed up in.

[Scooby_Doo]

Oh yuck, well this definetely complicates things badly. 

[Nuke]

this is a major problem for nukemod too, since many of my ships were made in the pre-normal-map era and i tend to use a lot of uv mirroring. so normal mapping old ships usually comes with a remodel. a way around this is by using a second uv mapping channel. you would need to use something like max automatically reorganize your uv space into a second mapping channel then you can mirror the **** out of everything in the first chanel, and in the second have every polygon get a dedicated set of space. then somehow use channel 1 for some textures and channel 2 for others, ect. its a big can of worms to open, would require a materials system, many pof upgrades, and some more render code.

i would gladly sacrifice a few goats for this, maybe even a virgin or two.

[Scooby_Doo]

* Scooby_Doo hands Nuke a few goats....

Now virgins might be harder to find 


Actually I kinda found a workaround.  Separate the sides by a very tiny tiny amount.  Create a polygon between those two sides (if your using Max the edit poly's bridge tool works wonders).  Apply a unique uvmap texture to it (it doesn't have to be big or any details, it's just a sliver).  Make sure it's smoothed with both sides.  You'll get a hard line when just viewing normal maps, but begins less visible if you add in shine maps and when viewing with everything (including diffuse) the sliver is practically invisible.

[Scooby_Doo]

Sorry, that hack doesn't seem to work in-game.  It looks great in the F3 viewer, but definetly not ingame.

You can see exactly where the symmetry is done

[Bobboau]

I'm wonder if PCS2 is combining the vertices into one.  Perhaps thats where the vertex normals are getting messed up in.

it does, this should not be an issue though, due to the vertex/index buffers getting rebuilt for every model in game.

[Nuke]

are vertex normals stored at the vertex level or the polygon level? using the latter meathod would probibly allow us to mirror to our hearts content without inverting the bumps. unless of coursei completely misunderstand the concept of tangent space.

[Scooby_Doo]

Keldor found the issue. Apparently it's a shader issue. 

[Talon 1024]

I've found a bit of a workaround for this problem.  You can move the UV coordinates for one half of the ship up above the coordinates for the other half of the ship, like I did below.  Then, the problem should be gone, or at least unnoticeable.

It's not perfect, but it seems to work fine; the seam in the center is slightly visible if you look closely enough.

BTW, will this be fixed in the FSO shader set in the future?

[Scooby_Doo]

One problem with that... at least with Saga's shaders is nothing should go beyond (0,0)-(1,1).

But I like the solution though.