Staticmesh Lighting problems at texture seams

[DavidM]

Hey,
Our problem is this:

Along the red dotted lines (where the texture seam is) the lighting is really ugly. It looks like its unsmoothed there, but that isn't the problem.

This is what it looks like without our material:


The model is built in Maya.

Any suggestions would be very welcome. We are pretty desperate as to why it happens.

[Nathaniel3W]

Did you make a separate lightmap UV? What's your lightmap resolution?

[DavidM]

Did you make a separate lightmap UV? What's your lightmap resolution?

We have the same UV map in channel 0 and channel 1. It makes no difference if we have nothing in channel 1.
Lightmap resolution is 32.



Other facts:
- Without the normal map it doesn't happen!
In other programs the problem gets fixed when sRGB is disabled on the normal map texture, in UDK however the problem gets even worse.
- In UE4 it works flawlessly


Any more ideas? We're pretty desperate

[Chosker]

what's the texture compression you're applying to your normalmap?
also in your material nodes, how is the normalmap applied?

[DavidM]

The Material setup is very basic so far:
http://puu.sh/kIPWD/1fa01ecc84.jpg
For the compression I tried tc_default and tc_normal, makes no difference.
Any more ideas?

I've done this to tons of other models, never had this problem before. Just the work of this one modeler always does these problems.

[Nathaniel3W]

Do you think you could have the R/G channels switched? Or do you need to reverse the brightness of the channels? Those are problems that I've run into when someone else did the normalmaps.

To test out the R/G switch, append G and R (in that order), then append B. To test out the reversed brightness, get a OneMinus node, put your R into it, do the same for G, and then append them. Then test out combinations: 1-R with G, R with 1-G, 1-R with 1-G, G with 1-R, 1-G with R, 1-G with 1-R. (With blue appended last to each of those combinations, of course.)

Maybe one of those will tell you what's wrong, and then you can have the artist redo the normal.

[Chosker]

your material is fine.
the texture compression should be TC_Normal or TC_NormalmapUncompressed. after you change the compression you'll need to recompile your shader, so go and move some node so you can recompile the material
if you want to avoid the material recompilation you should use a NormalParameter node for your normalmap instead of a Param2D.

if that still doesn't work try what Nathaniel suggests. usually it's flipping the Green cannel. to do this there's another option: import the texture again, and in the import dialog there's an option to flip the G channel

[DavidM]

Thanks for the ideas.
But these seem to have nothing to do with it.
Nothing ever changes about the seams.

I just put in an empty normal map for testing, and it still does it: What could that mean?


Without the normal, the problem is gone:

[Nathaniel3W]

Wow. That's pretty tough. Honestly, that looks like a smoothing group problem to me, where some unintended lines got marked "sharp." But I don't know whether smoothing groups change when the normal is hooked up. I don't know whether it would make a difference, but you might want to go back into your 3D editing program and take a look where your sharps are. Also, your normal map looks a little too cornflower colored to me, which suggests import or compression problems. (Once again, I don't think that would make a difference.) This probably won't make a difference, but you could just use a vector 3d (0,0,1) for the normal, and that might at least remove a variable from the equation.

[Nathaniel3W]

Also, is that face reversed? Are those polygons getting placed with their backside on the UV?

[DavidM]

IMO it cannot be a smoothing thing, because then it would also show without a normal map, but that is clean.

Multiplying the normalmap with 0,0,1 makes it look exactly like without a normal map (problem fixed, but no normal data).

I don't know about backside faces, I'll ask.

[Chosker]

are you sure you tried what I mentioned? I've gotten this exact same problem before and fixed it that way
it's not a smoothing group issue, not a backside issue.

multiplying your normalmap with 0,0,1 means you'll get an output of 0,0,1 - which is the default value of not using a normalmap (0,0,1 means the normals are pointing up)

your new empty normalmap, what's the texture compression? and does it have sRGB on or off?

[DavidM]

The compression didn't change anything.
Here the 2 compression settings:




As for the empty normalmap I tried every compression setting with sRGB on and off. No difference whatsoever

[DavidM]

Nathaniel, I tried every combination you mentioned.
This is the setup and it looks pretty much the same with every change.


But the remarkable thing to me is that the empty normal map also produces the same problem.

[Nathaniel3W]

But the remarkable thing to me is that the empty normal map also produces the same problem.

Wait, didn't you say that an empty normal and a (0,0,1) normal fix the problem?

Wow man. I've never seen this forum work so hard on a problem and not fix it. I really don't know what the issue is. I'm honestly just grasping at straws now, but I checked some of my reverse-green materials and found out that I fixed those by multiplying by (1,-1,1), not 1-G, for what it's worth.

Did you say before that this only happens with the work of one modeler? If you send the raw files to another modeler and have him re-export them to fbx and png, that could fix it. Of course, you shouldn't have to do that, but I don't know what else could be done.