[zookeeper]

Note: I am not interested in workarounds. I have a workaround. I am interested in the answer to my question.



Here's a texturing problem the root cause of which I haven't quite been able to figure out yet: in the attached screenshot, there's a plane built of 16 quads (none of which share any vertices with each other) with the same normal map applied to each one. When the quads are all pointing in the same direction (left image; look at the little red arrows) everything's fine. However, when I randomly rotate each quad 0, 90, 180 or 270 degrees (again, the little red arrows show the orientation of the texture), the normal maps suddenly break in a subtle manner on the quads which got rotated: the pixel normals start pointing in the wrong directions.

The problem is that I don't really know where the problem originates:

1. Is it the model? Maybe the model has wrong tangents/binormals?
2. Is it the engine? Maybe it doesn't calculate tangents/binormals right?
3. Is it the shader? Maybe it doesn't calculate the final direction of the normal correctly?

So, my question is, where is the problem? What would be needed to fix it? It seems clear enough that this isn't an unsolvable problem and that there's actually some way to fix the glitch (if there wasn't, then I don't see how a normal map could ever work on for example a deforming mesh, and obviously there's plenty of engines around which do that).

The normal maps used by the engine are supposed to be tangent-space normal maps, and if I correctly understand what that means then stuff like this should work. Using tangent-space normal maps (as opposed to world- or object-space normal maps) supposedly allow them to work with fancy things like mesh deformations, so what's the deal here? Do we not have tangent-space normal mapping after all, is there a bug in there somewhere or is it because of something else?

I've tried this with several sets of shaders and all of them exhibit the same problem.

[attachment deleted by ninja]

[pecenipicek]

its the UV map



besides, didnt we already go over this problem overall?

[zookeeper]

its the UV map



besides, didnt we already go over this problem overall?

Yes, but no one has so far managed to explain how it could be fixed or even what the problem is precisely and how do other game engines presumably do it.

[pecenipicek]

its the UV map



besides, didnt we already go over this problem overall?

Yes, but no one has so far managed to explain how it could be fixed or even what the problem is precisely and how do other game engines presumably do it.

i did explain it in detail to you over IRC a while ago. i cant find the logs anymore, thanks to the retarded IRC client i used.

i'll whip up an explanation relatively soon-ish tho.

[zookeeper]

its the UV map



besides, didnt we already go over this problem overall?

Yes, but no one has so far managed to explain how it could be fixed or even what the problem is precisely and how do other game engines presumably do it.

i did explain it in detail to you over IRC a while ago. i cant find the logs anymore, thanks to the retarded IRC client i used.

i'll whip up an explanation relatively soon-ish tho.

This?

<zookeeper> even with the latest'ish shaders the normal map still behaves differently based on which way the quad is facing
<pecenipicek2>  oh for...
<pecenipicek2> that should be your cue, shouldnt it?
<pecenipicek2> as in, "intended behavior"
<zookeeper> that kind of intended behaviour doesn't make any sense though
<pecenipicek2> does it look similar to what i linked to you when you view it with the "latest-ish" shaders?
<pecenipicek2> compare this to what you see with your "latest" http://imagebin.org/130788
<zookeeper> yes, that's what i get now
<pecenipicek2> good then.
<zookeeper> http://imagebin.org/130790
<pecenipicek2> learn to work within the "constraints" of that
<The_E> Looks to me like it's working as expected
<zookeeper> so are you saying that you know there's no reasonable workaround for that besides actually workarounding it in the model/texture?
<pecenipicek2> since its all tiled from a single block, the fact of the matter is that depending on how the uv for a particular block is faced, thats the way the shading with normals will go
<zookeeper> i still don't understand why that cannot be compensated for
<zookeeper> i mean, obviously the game/shaders knows which way the texture is facing
<The_E> zookeeper: The basic problem is that there's no non-trivial way to get the orientation data you would need from just the model info and the texture
<zookeeper> The_E, does that mean there's a trivial way?
<The_E> Err
<The_E> No trivial way, was what i meant to say
<zookeeper> anyway, this is still bizarre to me. what would happen if i'd have originally baked the normal map onto a quad which is facing sideways, instead of one that's "correctly" facing up?
<pecenipicek2> what?
<zookeeper> nevermind
<The_E> zookeeper: The problem here is that the texture is being applied mirrored
<pecenipicek2> http://imagebin.org/130792
<pecenipicek2> http://imagebin.org/130793
<pecenipicek2> http://imagebin.org/130794
<pecenipicek2> does tis look "perfect" to what you had in mind?
<zookeeper> yes
<pecenipicek2> good. you know how you can make it work properly?
<zookeeper> yes
<pecenipicek2> dont tile it from a single tex.
<zookeeper> yeah, i can make 4 variations of the normal map
<pecenipicek2> for each orientation, you need a normal map made for that orientation.
<pecenipicek2> its not a bug of any sort, its the way how each and every relatively sane 3D engine nowadays works.
<pecenipicek2> its exactly the same as the issue with the numbers on the herc 2 being written backwards on one side of the model.
<zookeeper> well, the thing is that i thought tangents/bitangents were exactly for storing the info about which way things are facing
<pecenipicek2> they do.
<zookeeper> but that that's still not enough information in this case?
<pecenipicek2> no. Tangents and bitangents are for POLYGONS.
<pecenipicek2> normal maps affect those to give the illusion of depth.
<pecenipicek2> read this. http://en.wikipedia.org/wiki/Normal_mapping
<zookeeper> oh well, i guess i have no choice. meh.
<pecenipicek2> as i told you before, learn to use proper tools and use proper methods.
<zookeeper> so what if i was modelling a room, and wanted to use the same normal map for each wall? it'd be as buggy as my slab now?
<pecenipicek2> yup.
<zookeeper> oh dear.

[/size]

That's far from a detailed explanation especially when 1) it'd be retarded general limitation of normal maps and also because 2) I can't find anything on the internets which would corroborate that. How could the normal maps on a deforming mesh possibly continue to render correctly when the orientation of the polygons keeps changing all the time?

[Zacam]

Possibly by using geometry shaders or a trick similar to it to? And having more than one rendering pass in which to do it in?

But it's still done the same. UV Direction and Normal Tangent Map Direction must be in alignment, pure and simple. Mesh deformation doesn't change that to any degree because it does not affect the uv map in any way.

[pecenipicek]

as i said before, its related to uv mapping.


polygon orientation itself doesnt have **** to do with the breaking normals that happen to you.




in short, dont rotate the uv's, rotate the polygons. and make sure that at first all UV polys are orientated the correct way.

as you've said: "there's a plane built of 16 quads (none of which share any vertices with each other)", this should be trivial to do.

Possibly by using geometry shaders or a trick similar to it to? And having more than one rendering pass in which to do it in?

nope. or not in the case of any sane engine would be my guess

But it's still done the same. UV Direction and Normal Tangent Map Direction must be in alignment, pure and simple. Mesh deformation doesn't change that to any degree because it does not affect the uv map in any way.

corrected

[zookeeper]

as i said before, its related to uv mapping.


polygon orientation itself doesnt have **** to do with the breaking normals that happen to you.




in short, dont rotate the uv's, rotate the polygons. and make sure that at first all UV polys are orientated the correct way.

as you've said: "there's a plane built of 16 quads (none of which share any vertices with each other)", this should be trivial to do.

Well... as I too have said before, that's exactly what I have done:

All the UV's are oriented the same way, all the quads are oriented the same way. It renders correctly like in the screenshot on the left. Then I detach a quad and rotate it. UV's stay intact and exactly at the same locations. Then I attach the quad back. UV's don't change. But now it renders wrong like in the screenshot on the right.

[pecenipicek]

it will only work if you keep the quad detached. if you connect it back, it will share vertices again, and out goes the stuff



make sure all the quads are detached first, in the same object, but not sharing vertices, align the uv's so they are all the same, THEN rotate the quads themselves, not the uv.

[zookeeper]

it will only work if you keep the quad detached. if you connect it back, it will share vertices again, and out goes the stuff

Attaching objects has nothing to do with sharing vertices. I'm attaching the quad back but I'm doing absolutely nothing to the vertices; the vertices of the quad are not getting welded with the vertices of the plane. Each quad is a separate element and doesn't share vertices with any other quad... just like I've said.

make sure all the quads are detached first, in the same object, but not sharing vertices, align the uv's so they are all the same, THEN rotate the quads themselves, not the uv.

Same as above. Doesn't help.

[Col. Fishguts]

it will only work if you keep the quad detached. if you connect it back, it will share vertices again, and out goes the stuff

Attaching objects has nothing to do with sharing vertices. I'm attaching the quad back but I'm doing absolutely nothing to the vertices; the vertices of the quad are not getting welded with the vertices of the plane. Each quad is a separate element and doesn't share vertices with any other quad... just like I've said.

make sure all the quads are detached first, in the same object, but not sharing vertices, align the uv's so they are all the same, THEN rotate the quads themselves, not the uv.

Same as above. Doesn't help.

He's talking about the UV editor, not the geometry editor. If you keep your quads as separate islands ins UV space you can rotate them however you want and then stack them on top of each other. This way you'll get perfext lighting on the normal map, since the engine doesn't now that those quads are sharing vertices and therefore doesn't try to compensate lighting across vertices.

All of this has nothing to do with editing the geometry, it's just in UV space.

[pecenipicek]

it will only work if you keep the quad detached. if you connect it back, it will share vertices again, and out goes the stuff

Attaching objects has nothing to do with sharing vertices. I'm attaching the quad back but I'm doing absolutely nothing to the vertices; the vertices of the quad are not getting welded with the vertices of the plane. Each quad is a separate element and doesn't share vertices with any other quad... just like I've said.

make sure all the quads are detached first, in the same object, but not sharing vertices, align the uv's so they are all the same, THEN rotate the quads themselves, not the uv.

Same as above. Doesn't help.

He's talking about the UV editor, not the geometry editor. If you keep your quads as separate islands ins UV space you can rotate them however you want and then stack them on top of each other. This way you'll get perfext lighting on the normal map, since the engine doesn't now that those quads are sharing vertices and therefore doesn't try to compensate lighting across vertices.

All of this has nothing to do with editing the geometry, it's just in UV space.

NO! THAT DOES NOT WORK WITH NORMAL MAPS DAMMIT!


*is preparing an elaborate explaration on the WHY of it at the moment. please bear with me*

[Col. Fishguts]

it will only work if you keep the quad detached. if you connect it back, it will share vertices again, and out goes the stuff

Attaching objects has nothing to do with sharing vertices. I'm attaching the quad back but I'm doing absolutely nothing to the vertices; the vertices of the quad are not getting welded with the vertices of the plane. Each quad is a separate element and doesn't share vertices with any other quad... just like I've said.

make sure all the quads are detached first, in the same object, but not sharing vertices, align the uv's so they are all the same, THEN rotate the quads themselves, not the uv.

Same as above. Doesn't help.

He's talking about the UV editor, not the geometry editor. If you keep your quads as separate islands ins UV space you can rotate them however you want and then stack them on top of each other. This way you'll get perfect lighting on the normal map, since the engine doesn't now that those quads are sharing vertices and therefore doesn't try to compensate lighting across vertices.

All of this has nothing to do with editing the geometry, it's just in UV space.

NO! THAT DOES NOT WORK WITH NORMAL MAPS DAMMIT!


*is preparing an elaborate explaration on the WHY of it at the moment. please bear with me*

YES IT DOES DAMMIT!

Manually stacking identical polies without merging/welding the vertices in UV space lets you do exactly the kind of UV setup as in the first post, even with normal maps.

[pecenipicek]

In short, the direction in which things point up is well, the arrow. Consider that the up position. The rightmost row is the one that was always untouched.
First picture are all oriented identically, second picture, the three rows starting from the far left are variously oriented.
First row is only polygon orientation changed, polygons are NOT connected to each other.
Second row are polygons where the orientation on the UV-map was changed,  polygons are NOT connected to each other.
Third row are polygons which share vertices, with their UV-map orientations changed.
Fourth row should be untouched polygons.
The above applies for the 2nd picture of the pair.
Now for comparison pictures. Paired on the basis of overall object orientation

Also note, the brightness changes are not the actual problem, highlight orientation is.






The above is FSO behavior.

This is how its supposed to be...
Same method of "reading" the images as above...

These are proper renders out of Cinema4D


The following 6 pictures are taken from xNormals realtime renderer.

First off, OpenGL 1.3 renderer:


DirectX 9, SM3.0 renderer


DirectX 10, SM4.0 renderer




With posting this, i'd like to apologise to zookeeper and Col. Fishguts.

I wasnt aware of the normal map behavior being actually wrong, and i worked under the assumption that it was correct in FSO. Which proved it isnt.



Anyhow, coders eyes should definitely be on this.

[Water]

I wasnt aware of the normal map behavior being actually wrong, and i worked under the assumption that it was correct in FSO. Which proved it isnt.

You're making an assumption that PCS2 doesn't weld the vertices together.

If you separate the quads, it all looks as expected in FSO.

[zookeeper]

Wow, that's a lot of screenshots. Let's wait and see what the coder types have to say...

You're making an assumption that PCS2 doesn't weld the vertices together.

If you separate the quads, it all looks as expected in FSO.

I checked, and yes, it looks like PCS2 does weld vertices; I saved the model to a .pof, opened it, saved as a .dae and imported it back to 3ds Max, and indeed the vertices had gotten welded at some point.

However, that doesn't seem to solve the problem. I separated the quads so that their vertices aren't getting welded, and the normal map issue remains the same (and I tried that both by rotating the quads and by just rotating the UV's).

[Water]

However, that doesn't seem to solve the problem. I separated the quads so that their vertices aren't getting welded, and the normal map issue remains the same (and I tried that both by rotating the quads and by just rotating the UV's).

That possibly points to a problem somehow with Max.

I tested in Blender with the quads separated and rotated. It all looked good.

I also tested by not moving the quads but making each one a sub-object - looked perfect. I don't think FSO is the problem.

[Col. Fishguts]

@pecenipek: Don't worry, a little shouting reliefs stress

I'm also not quite sure how PCS2 handles the differences in welded vs. isolated vertices in UV space when importing a .DAE from Max. I know that the difference clearly shows up in the normal maps, but I don't know where it is stored wether two vertices are welded in UV space or not (since this seems to be independent from their actual position in the mesh).

Maybe a coder can share some insights?

[Zacam]

Just because Results = Looks Great in a modeling program (Such as Max, Blender, whatever) doesn't mean that FSO isn't the problem.

because obviously (if say you manage to make it so that PCS isn't welding things together) if it still looks wrong in-game, then there is one of two things going on:

A: The rendering/modeling programs have it wrong because they just don't care or handle world/lighting positions completely different than anything else or

B: FSO is nerfed in some aspect as to it's Tangent (or Bi-Normal or whatever) space calculations on the model read, or unlike the modeling applications it is not able to read the matrix from the UV (which probably get's stripped on conversion any way)

(While I may be a coder, this area is not exactly my strongest area, so go with the gist of what I'm saying rather than the explicit terms used please, you'll spare all of us some headaches by not arguing the technicalities.)

[Water]

Just because Results = Looks Great in a modeling program (Such as Max, Blender, whatever) doesn't mean that FSO isn't the problem.

The tests I did were done in Blender then looked at in FSO.