normalmap shifted at uv seam
polycounter lvl 10
Hey folks,
I came upon an issue I've never encountered before and wasn't able to solve yet. Maybe you can help?
The texture is shifted at the uv seam though both lowpoly and highpoly are aligned perfectly fine.
The seam is smoothed edge, so no SG split there. However, the same texture shift comes up with split SGs.
It seams to me this is a problem of the cage - it basically seems like skewing - but the cage is averaged and looks perfectly fine as well. Support geometry didn't change anything, too.
I came upon an issue I've never encountered before and wasn't able to solve yet. Maybe you can help?
The texture is shifted at the uv seam though both lowpoly and highpoly are aligned perfectly fine.
The seam is smoothed edge, so no SG split there. However, the same texture shift comes up with split SGs.
It seams to me this is a problem of the cage - it basically seems like skewing - but the cage is averaged and looks perfectly fine as well. Support geometry didn't change anything, too.
Replies
Here's the wireframe and the uvs (there's a blue edge marked because the left part is mirrored and the respective poly on that side is selected, too):
Unfortunately, I already checked the geometry for errors a few times and there are none. When moving the verts in the uv layout just for checking, everything seems alright, too.
What I actually did after unwrapping it was changing the triangulation of a few quads in that area, but
a) this did not seem to produce the error as I flipped them and rebaked - no change in the bake - and
b) I never read of the triangulation being able to do such things when played with. I could imagine, however, that the UV space of the texture would somehow be stretched/distorted, thus causing the problem. But a) seems to rule that solution out, too...
I'm really at my wit's end...
Manually exporting a cage always throws me the error in xNormal that the cage has different vert count. I tried playing around with the bools in the xNormal triangulator plugin as somewhere stated by Santiago, but that did not solve the vert count error.
3ds Max's normal map seems to be generally a lot better this time. There were several minor issues that seemed to be solved as well with Max's bake. It really seems to me that xNormal is not reading the mesh correctly, most likely the triangulation and mesh normals. And this applies to both .fbx and .sbm. I wonder why?
It does export the cage and it even looks exactly as the one generated in xNormals 3d viewer. As stated above, I believe this is rather an issue of the way xNormal imports and processes the given meshes. how do you generally force triangulate without using editable mesh? I tried Editable patch but it is really buggy and crashes Max a lot. Is there another way without sacrificing the editable poly? Oh before I forget: the .fbx export (latest version, 13.1 I think) "triangulate" option doesn't work for me. Strange as well...
From what I noticed when comparing the two baked normalmaps of 3ds Max and xNormal was that the xN one seems not only to shift the texture at the seam but in general. All shells, the whole texture, seems to be offset 1px to the bottom left... I will email Santiago about this, so he can take a look. Maybe he's got some insider advice.
On a side note those UVs are quite impressively packed. Is there enough padding between the shells?
Yes, that's how I do it. I don't want to sound presumptuous, but is there another way of making the cage in xNormal?
Thanks, I think I spent over 12 hours for this (exterior of a helicopter) and another 8 or so for the interior which you don't see... Much too long in my opinion, but this aims for portfolio, so it had to be as best as I could do it.
Padding is 2 pixels for each shell at a 2k res, so effectively there should be 4 pixels of free space between the shells. There will be a 4k map for close-up shots though.
I never had any padding related issues until now, so I hope this is sufficient?!
there's a uv seam there, so the checker map will not align. As for if it is only the normal map causing the problem: yes, I think so. It is only the one baked by xNormal as stated above. The 3ds max bake is perfectly aligned.
I reset the normals various times already, even tried modified explicit normals - to no avail.
If you're doing everything right, it might be down to some issue with the low poly itself, as dustin suggested. Try looking for duplicated verts, reset xform, apply the normal modifier twice, export then re-import the model, etc. If all else fails, rip out and re-make those polys or upload the low poly so someone else can check it out.
The packing is great, but it might be a bit close. Even if you have 4 pixels padding, as soon as the engine starts using mip maps you'll start to get bleeding on the second or third mip. Might not show up now, but once you get more high contrast areas in the texture I would be surprised if it doesn't show. Further info here: http://wiki.polycount.com/EdgePadding