Nasty Normal Map Seem on stacked UVs

mikezoo

Hola all fellow polycounters!

Been messing around trying to figure out how to avoid this nasty seem I got, and judging by other threads it seems as if others might have the same problem. Two heads better than one, eh?



Because each large panel is the same, I baked the high poly on a low poly panel then, cloned the sections and wielded them together.

Iam trying to find out how i can get rid of those seems in the middle of the model. So far Iam at a loss as whats causing it. Smoothing groups? A baking issue? Perhaps its the stacked Uvs? Not quite sure why.

Any ideas/suggestions would be so great. Thanks a lot in advanced.

Mangled Poly

It would be best if your posted your normal map.

My guess off had would be your smoothing groups.

Have that front wall on its own smoothing group or none at all then it should make a flat normal that you can tile as you are trying to do now. Of course the down side is you will have a minor break in the map along the wall edge but that should be minor or may not even be noticeable.

cman2k

Here's one good way to hack-fix problems like this, thanks to original author warby.

mikezoo

Well Ive tried assigning different smoothing groups like you said and its been the same deal.

One thing I haven't tried yet, it making sure that my smoothing groups match up between my high and low poly meshes. Such as have the front wall be 1 on both my high and low, ect, ect.

ohhhh! exciting stuff! gottta go try it!


Oh WOW cman! thats an AWESOME hack! props to warby. I'll try that too. Dont know if it will work. Shall see!!!

mikezoo

Well, I tested it to see if matching my smoothing groups between my high and low would work, but,,, it dident!

Gosh. Iam sure this is something simple.

They mystery continues!

Mark Dygert

I bet you have some inverted pieces. In the UV editor window go to face mode, and go Select > Select Inverted faces. You'll need to detach and flip those panels that are inverted. Also know that there is a good chance you'll get a seam if you export this to a game since games break geometry along UV seams.

If the pieces aren't flipped, try using another DX shader.

IxenonI

post the normal map. it probably shows where the errors are...

Eric Chadwick

Bake after the cloning and welding step. After finalizing your low-poly mesh, use the Select Inverted Faces command in Unwrap, then Detach Edge Verts, then move the selected faces 1 unit outside the UV square. Then bake the normal map. After this, use a viewport shader that uses the tangent basis properly.

The cloning and welding is probably causing the tangent basis to change, messing up your shading.

mikezoo

Baking after, eh? okay!
I never knew there was a polycount wiki, my god, there's so much to read in there. Thanks for showing me Chadwick.

So baking after. Thats going to be the first thing Iam gonna do when I get back home. Shall see what unfolds!

mikezoo

So alright. Baking after all the cloning and wielding, does seem to solve some strange normal map seems indeed. Differently a good way to go.

But, I seem to run into new issues altogether.

When I bake sections of my highpoly onto my Uved all ready cloned and wielded-lowpoly mesh, many of the areas bake with very funky lighting isssues (Issues that you can still see when rendered out. ) and inverted areas that were baking out fine before, are now,, poo-poo
So thinking on how Iam going to solve this. I belive Iam going to use a combination of baking after cloning and baking out seperate areas and throwing all the maps together in photoshop. Dont know if that will work though

thanks guys!

Mark Dygert

You need to move the cloned pieces out side of the live area when you bake. Its baking each copy/clone to the same space. To get around that you just need to leave one in the live area, bake and then move the others back.

A quick way to do this is to save your layout move your pieces, bake, and load the saved layout.

Or apply another UVW Unwrap modifier, move & bake then delete the modifier when your done.

Sage

you need to offset the uvs of anything that shares the same uv space like Eric mentioned or assign a different material id to anything that isn't mirrored then bake by material id. you would have to assign a different material id to everything that is mirrored as well. Offsetting might be faster though.

mikezoo

Like you said Vig, Thats exactly what Iam doing, but with one execption. Dont know if its a biggie or not.

Quick question.

If I have say, five overlapping Uvs on top of each other, do i need to offest each one of those overlapping Uvs, or do i just need to grab, say four of the cloned ones and offset them 1. Keeping in mind those 4 are still overlapping each other, but not the originals.

Iam even making sense? I would post an example, but Iam not at home.

Thanks you guys for timely and responsive feedback. Helps alot.

Eric Chadwick

Only one layer of forward-facing UVs should be present in the 0-1 square at baking time. Doesn't matter which four of those five overlapping layers you move, as long as there are no overlaps when you bake. Also move off any backwards-facing UVs (the mirrored ones).

Contrary to what Vig posted though, you do not need to move them back into the 0-1 square when you're done baking. As long as you move them exactly 1 unit over, you can just leave them there, saves time if you have to re-bake later.

mikezoo

Horray. Fixed with the combined methods from all you fine, fine people!:)

I left my Uvlayout with all overlapping and backward facing Uvs 1 over from the 0-1. I never threw them back into the 0-1.

Which brings another question to my head. How often do game engines need overlapping and backward facing uvs to be moved off the 0-1 or when you export them ingame, are they in fact required to be all thrown into the 0-1. I know it varrys from engine to engine, but it would be cool to hear any other thoughts about this.

Thanks alot for your help guys!

Mark Dygert

Most of the major engines I've tinkered with support leaving them out in limbo. I move them back out of habit, like Eric pointed out you don't have to move em back if they where moved properly.

Sage

The reason you have to offset them is because of a limitation imposed by the texture baking process. The 3d program looks at it as oh here are the uvs, here is the normals information from the model, in your case then bakes that information depending on your the uvs are. It doesn't care about anything, in other words the programmers that wrote the render to texture process made it useless out of the box for game artist. It just tries to bake things to where you place your uvs that corresponds to the geometry of the model. If you use material ids in max, I find it a long process, you can specify what you want baked. Sometimes it's worth doing it that way. The baker doesn't understand that it's very helpful for game artist to mirror things in the texture. The good thing though it only looks in the 0 to 1 space or this would be more annoying to work around. The reason to not have your uvs off set is because some programs, zbrush for example, hate overlapping uvs, I think it used to crash at some point... I forget what it does when the uvs are offset.

mikezoo

Nice advice.
I never thought of using the material Id for a process of baking. Perhaps that would be useful for very large complicated bakes. (super complex gun/something).

I think I shall check that out, later in the future, in the meanwhile, those Uvs are staying in limbo!!!

SHEPEIRO

i always leave them out of 0-1 as it makes reselecting the baking parts so much easier, but each to there own eh