Hard Light Productions Forums

Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: zookeeper on February 14, 2011, 09:38:24 am

Title: Normal map shared across differently oriented polygons
Post by: zookeeper on February 14, 2011, 09:38:24 am
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]
Title: Re: Normal map shared across differently oriented polygons
Post by: pecenipicek on February 14, 2011, 09:57:36 am
its the UV map



besides, didnt we already go over this problem overall?
Title: Re: Normal map shared across differently oriented polygons
Post by: zookeeper on February 14, 2011, 10:09:08 am
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.
Title: Re: Normal map shared across differently oriented polygons
Post by: pecenipicek on February 14, 2011, 10:13:12 am
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.
Title: Re: Normal map shared across differently oriented polygons
Post by: zookeeper on February 14, 2011, 10:30:08 am
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?

Quote
<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? :P
<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?
Title: Re: Normal map shared across differently oriented polygons
Post by: Zacam on February 14, 2011, 11:05:41 am

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.
Title: Re: Normal map shared across differently oriented polygons
Post by: pecenipicek on February 14, 2011, 11:12:00 am
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

Quote
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
Title: Re: Normal map shared across differently oriented polygons
Post by: zookeeper on February 14, 2011, 11:31:54 am
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.
Title: Re: Normal map shared across differently oriented polygons
Post by: pecenipicek on February 14, 2011, 11:34:49 am
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.
Title: Re: Normal map shared across differently oriented polygons
Post by: zookeeper on February 14, 2011, 12:21:36 pm
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.
Title: Re: Normal map shared across differently oriented polygons
Post by: Col. Fishguts on February 14, 2011, 01:30:08 pm
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.
Title: Re: Normal map shared across differently oriented polygons
Post by: pecenipicek on February 14, 2011, 01:41:00 pm
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*
Title: Re: Normal map shared across differently oriented polygons
Post by: Col. Fishguts on February 14, 2011, 04:07:34 pm
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.
Title: Re: Normal map shared across differently oriented polygons
Post by: pecenipicek on February 14, 2011, 05:15:45 pm
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.

(http://img808.imageshack.us/img808/4871/screen0026x.th.jpg) (http://img808.imageshack.us/img808/4871/screen0026x.jpg)(http://img715.imageshack.us/img715/2466/screen0027.th.jpg) (http://img715.imageshack.us/img715/2466/screen0027.jpg)
(http://img109.imageshack.us/img109/5001/screen0028.th.jpg) (http://img109.imageshack.us/img109/5001/screen0028.jpg)(http://img404.imageshack.us/img404/8572/screen0029i.th.jpg) (http://img404.imageshack.us/img404/8572/screen0029i.jpg)
(http://img717.imageshack.us/img717/259/screen0030.th.jpg) (http://img717.imageshack.us/img717/259/screen0030.jpg)(http://img262.imageshack.us/img262/755/screen0031.th.jpg) (http://img262.imageshack.us/img262/755/screen0031.jpg)
(http://img573.imageshack.us/img573/9715/screen0032l.th.jpg) (http://img573.imageshack.us/img573/9715/screen0032l.jpg)(http://img291.imageshack.us/img291/9747/screen0033.th.jpg) (http://img291.imageshack.us/img291/9747/screen0033.jpg)

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
(http://img707.imageshack.us/img707/3449/texstufftestnormal.th.jpg) (http://img707.imageshack.us/img707/3449/texstufftestnormal.jpg)(http://img137.imageshack.us/img137/2448/texstufftestorientation.th.jpg) (http://img137.imageshack.us/img137/2448/texstufftestorientation.jpg)

The following 6 pictures are taken from xNormals realtime renderer.

First off, OpenGL 1.3 renderer:
(http://img818.imageshack.us/img818/5001/oglnormal.th.jpg) (http://img818.imageshack.us/img818/5001/oglnormal.jpg)(http://img227.imageshack.us/img227/754/oglorientation.th.jpg) (http://img227.imageshack.us/img227/754/oglorientation.jpg)

DirectX 9, SM3.0 renderer
(http://img267.imageshack.us/img267/1812/dx9normal.th.jpg) (http://img267.imageshack.us/img267/1812/dx9normal.jpg)(http://img833.imageshack.us/img833/3084/dx9orientation.th.jpg) (http://img833.imageshack.us/img833/3084/dx9orientation.jpg)

DirectX 10, SM4.0 renderer
(http://img638.imageshack.us/img638/9678/dx10normal.th.jpg) (http://img638.imageshack.us/img638/9678/dx10normal.jpg)(http://img213.imageshack.us/img213/2081/dx10orientation.th.jpg) (http://img213.imageshack.us/img213/2081/dx10orientation.jpg)



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.
Title: Re: Normal map shared across differently oriented polygons
Post by: Water on February 15, 2011, 01:45:33 am

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.
Title: Re: Normal map shared across differently oriented polygons
Post by: zookeeper on February 15, 2011, 02:12:06 am
Wow, that's a lot of screenshots. :yes: 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).
Title: Re: Normal map shared across differently oriented polygons
Post by: Water on February 15, 2011, 03:29:33 am
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.
Title: Re: Normal map shared across differently oriented polygons
Post by: Col. Fishguts on February 15, 2011, 05:41:29 am
@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?
Title: Re: Normal map shared across differently oriented polygons
Post by: Zacam on February 15, 2011, 11:22:09 am

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.)
Title: Re: Normal map shared across differently oriented polygons
Post by: Water on February 15, 2011, 01:28:31 pm
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.
Title: Re: Normal map shared across differently oriented polygons
Post by: pecenipicek on February 15, 2011, 02:17:26 pm
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.
What do you think did i do? What you are saying right now is that you completely and utterly ignored my main post which demonstrated the thrice damned problem properly.
Title: Re: Normal map shared across differently oriented polygons
Post by: Nuke on February 15, 2011, 02:19:45 pm
id get around this issue with a second mapping channels for uv space. you keep your regular mapping for diffuse textures where you could overlap to your hearts content. in the second channel no two polygons that share the same material are allowed to overlap. normals from the tile map would be combined with the surface normals in the geometry, transformed based on the projection data for the second uv map, and then new normal maps would be generated based on that data, and those maps would be use for normal maps.

this kinda thing ocould probibly be done in max, but you would need support in pof for extra mapping channels. the second uv map set could be generated automatically by max. it might be possible to do the process in the game and stick the new uv projections and generated normal maps in the cache folder, thus no new data need be added to pof. it would allow more effitient use of diffuse textures while supporting flawless normal maps on even heavily tiled and overlapped models.
Title: Re: Normal map shared across differently oriented polygons
Post by: Zacam on February 15, 2011, 02:27:44 pm

Well, it would also be nice to know what POF format stores in terms of readable features from the UV channel to begin with, before we start looking at increasing channels.

And frankly, I'd rather we just start being able to load DAE and be done. But that's probably just me.

And still doesn't address the issue at hand. How are we getting conflicting results here? Started with one person saying it's not working (and everybody saying it's doing what its' supposed to be doing) to now being reproducible by another person (swinging the vote now to 2 people exampling it as there being a problem) to now being 2-to-1 about whether or not we actually have a problem to begin with.

So, I think we need to formulate some sort of standardized way or methodology for "How can this be Reproduced Unilaterally" and "How to Avoid this from Happening Unilaterally" and seeing where that get's us.
Title: Re: Normal map shared across differently oriented polygons
Post by: Nuke on February 15, 2011, 02:40:44 pm
i figure it could be done procedurally in engine without needing to provide extra mapping data. youd need an algorithm for unstacking polygons from the uv map, then re-arange the polygons space them out in a square area, then scale to fit in map space. this uv map channel would be cached externally from the pof file (thus no pof changes neccisary). the next step is to bake the tile normal map into a new texture, while compensating from the variations caused by the surface normals. the game engine would instead of using the normal map that goes with the tile texture, and the mapping channel from the pof, it would used the cached mapping channel and texture. you wouldnt do this for every texture, you would need some way to flag textures that this process should be done on.
Title: Re: Normal map shared across differently oriented polygons
Post by: pecenipicek on February 15, 2011, 03:23:46 pm
i figure it could be done procedurally in engine without needing to provide extra mapping data. youd need an algorithm for unstacking polygons from the uv map, then re-arange the polygons space them out in a square area, then scale to fit in map space. this uv map channel would be cached externally from the pof file (thus no pof changes neccisary). the next step is to bake the tile normal map into a new texture, while compensating from the variations caused by the surface normals. the game engine would instead of using the normal map that goes with the tile texture, and the mapping channel from the pof, it would used the cached mapping channel and texture. you wouldnt do this for every texture, you would need some way to flag textures that this process should be done on.
so, instead of examining the pof format and the converter, and doing something that'd fix this, you propose a totally roundabout way that would A) increase memory useage utterly needlesly, B) be prone to breaking on any burp, C) its just WRONG on so many levels its insane.
Title: Re: Normal map shared across differently oriented polygons
Post by: Nuke on February 15, 2011, 03:54:42 pm
i figure it could be done procedurally in engine without needing to provide extra mapping data. youd need an algorithm for unstacking polygons from the uv map, then re-arange the polygons space them out in a square area, then scale to fit in map space. this uv map channel would be cached externally from the pof file (thus no pof changes neccisary). the next step is to bake the tile normal map into a new texture, while compensating from the variations caused by the surface normals. the game engine would instead of using the normal map that goes with the tile texture, and the mapping channel from the pof, it would used the cached mapping channel and texture. you wouldnt do this for every texture, you would need some way to flag textures that this process should be done on.
so, instead of examining the pof format and the converter, and doing something that'd fix this, you propose a totally roundabout way that would A) increase memory useage utterly needlesly, B) be prone to breaking on any burp, C) its just WRONG on so many levels its insane.

i cant vouch for my sanity, but i dont see memory usage being that bad. memory usage would be about one extra uv map and one texture worth, and is only done on certain textures. no different than if we had multiple mapping channels (which is something many people want and might, in the distant future, be implemented). the initial tile normal map is only ever used to generate another normal map, then it can be unloaded and the other map may be used instead.

then if the pof format is ever amended to support more mapping channels, you could just import the uv map that the game spewed out back into the pof, and continue to use the baked normal map.
Title: Re: Normal map shared across differently oriented polygons
Post by: Water on February 15, 2011, 06:01:12 pm
What you are saying right now is that you completely and utterly ignored my main post which demonstrated the thrice damned problem properly.
Um... no

You demonstrated the problem in FSO. It's real.

After testing I think the problem is PCS2. It has to handle a wide variety of of mesh quality, and it optimizes the mesh, even if you don't want it to.

If the polys are separated or in different sub-objects it works well. However Zookeeper still has the problem even with the polys separated. So there are several choices. First is to export from Max to obj and re-import then create the pof. If that solves the problem then there is a secondary Max issue. Which is a separate but related problem.

Zookeeper if that doesn't work you may need to post the dae/pof/normal map.
Title: Re: Normal map shared across differently oriented polygons
Post by: zookeeper on February 18, 2011, 05:01:31 pm
Here's the testing model. LOD0 has the model with the arrows pointing in the same direction where everything works, and LOD1 has a model with the arrows of the centermost quads all pointing in different directions. The included .dae file is the one which I got when I exported the model from Max. I'm not including all the dozen or so different variations I've tried, since they all still exhibit the exact same glitch.

In case anyone would suggest it; I've also tried Spicious' latest build, which didn't help.

EDIT: And the .png's work just fine. Really. Please don't say anything about how one shouldn't use them.

[attachment deleted by ninja]
Title: Re: Normal map shared across differently oriented polygons
Post by: pecenipicek on February 18, 2011, 05:54:18 pm
In case anyone would suggest it; I've also tried Spicious' latest build, which didn't help.
Confirming this. For future reference the build is PCS2 Alpha Release (Feb 18 2011 19:14:09).

Quote
EDIT: And the .png's work just fine. Really. Please don't say anything about how one shouldn't use them.
i will :p
Title: Re: Normal map shared across differently oriented polygons
Post by: Zacam on February 18, 2011, 09:28:26 pm

Just don't use 16bit PNGs. Apparently those DON'T wor, but I'll be making sure they do when I upgrade libpng which should be within the next couple of weeks. I hope.
Title: Re: Normal map shared across differently oriented polygons
Post by: Water on February 18, 2011, 11:02:57 pm
It tested ok for me, both detail0 and 1

Stab in the dark here, would you have a nVidia card?

(http://i229.photobucket.com/albums/ee67/waternz/mesh/screen0002.jpg)
Title: Re: Normal map shared across differently oriented polygons
Post by: zookeeper on February 19, 2011, 02:54:02 am
It tested ok for me, both detail0 and 1

Just so there's no room for error here: are you sure? It looks ok in your screenshot to me too, but the glitch isn't very obvious from all angles. I've found angles like this to be the quickest way of seeing if anything's wrong.

Stab in the dark here, would you have a nVidia card?

Yes, I do, an n7600GS. :nervous:

[attachment deleted by ninja]
Title: Re: Normal map shared across differently oriented polygons
Post by: Water on February 19, 2011, 04:08:05 am
Re-checked, it's uniform viewed from each corner so that just one triangle of each diamond is visible, they all line up.

Had read about a normal problem around November, when I re-read it, it turned out to be a bit more severe than your one so it may not be related. It was fixed by updating to the latest nVidia drivers.
Title: Re: Normal map shared across differently oriented polygons
Post by: Spicious on February 19, 2011, 05:53:51 am
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.
PCS2 doesn't distinguish between one vertex and two vertices at the same point.
Title: Re: Normal map shared across differently oriented polygons
Post by: zookeeper on February 27, 2011, 09:20:15 am
Firstly, using FSU shaders I can now get the normal map to work right as long as the quads don't share vertices, even if their vertices are in the same points. I'm not sure what has changed; this isn't the first time I've tried this set of shaders and it doesn't matter whether I use the latest PCS2 build or one which is older than this thread. Confusing.

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.
PCS2 doesn't distinguish between one vertex and two vertices at the same point.

Secondly, I can't reproduce the above anymore (regardless of which PCS2 version I use). :confused:
Title: Re: Normal map shared across differently oriented polygons
Post by: Aardwolf on February 27, 2011, 06:27:24 pm
[/lurk]

Here's a bit of info I came across during an attempt to fix FSO's normal mapping implementation:

The tangent-space info is not stored in the POF, but rather the IBX (so it's generated at runtime if there's no cached data for it). It is stored as 4 numbers --- 3 for one of the tangent vectors, and a 4th which I believe controlled whether to flip the second tangent when it was computed. IIRC the second tangent vector is computed in the vertex shader.

[lurk]