Normal Map issue

nacire

Hey folks, quick question. When baking out my normal maps as of late I'm noticing that the triangulated shading of the low res model is baking into the colors of the normal map. Is this the usual? Anyone know the issue? I've made many normal maps and can't recall this ever being an issue.

I've double checked the low res for any normal issues and it's all clean as is the hi res. UV's are clean too. I've baked the map in Maya and Mudbox.

Rob Galanakis

So the thing with tangent space normal maps is, it uses the model's normal as the "base" normal. Think of how far away from 127,127,256 the color is as how 'severe' the normal change is from the corresponding pixel on the model so that it will 'match' the normal of the high-res. For this reason, things like 90* smooths will result in lots of "triangulated shading" as the normal map needs to take into account the geometry, and thus normals, of the low-res. The only way to reduce this effect is to add more geometry. Either way, it's not something you can help. It means your ouptut could probably be better but if you are doing really low-res stuff with normal mapping there's probably nothing you can do. If it looks good, then it's good.

Eric Chadwick

Like the Prof says, you actually don't want to get rid of those seemingly- low-res triangulated gradients.

If your renderer/game engine is using the tangents/bitangents correctly, the gradients will give you the smooth shading you want.

eld

[ QUOTE ]
...The only way to reduce this effect is to add more geometry. Either way, it's not something you can help. It means your ouptut could probably be better but if you are doing really low-res stuff with normal mapping there's probably nothing you can do...

[/ QUOTE ]


Actually, you can (and I'm still trying to spread it around), it's this method:



Adding geometry is not the only way to go, and a badly shaded lowpoly will in most cases end up with bad shading in the baked result, so bake the mesh with smoothinggroups on the lowpoly to correct the shading and split the UV to have the normalmap correct the seams.

nacire

Thanks for the input guys, I appreciate it.

Eld your method worked perfectly! Thanks man! I was trying to think of a way to combine the soft edged bake with the hard edged bake and it really didn't occur to me to separate the UV's on the hard edges. Genius!

Joseph Silverman

Eld, the results look awesome, but doesn't splitting UVs double the vert count, thereby being exactly the same performancewise as a beveled edge?

Mark Dygert

[ QUOTE ]
Eld, the results look awesome, but doesn't splitting UVs double the vert count, thereby being exactly the same performancewise as a beveled edge?

[/ QUOTE ]eld is talking about splitting off pieces in UV space which doesn't effect the vertex/face count on the actual model unless you actually go and break the faces off on the model. What you do in UV-land doesn't effect model-world, unless you go nuclear. It's kind of an old trick made new. When you want a color to stop on a specific tri edge and not bleed over, you break the edge and leave a gap giving you a crisp clean line. For example, finger nails.

Joseph Silverman

[ QUOTE ]
unless you actually go and break the faces off on the model. What you do in UV-land doesn't effect model-world

[/ QUOTE ]

I'm pretty sure I heard exactly the opposite. The engine has to read those edges as 'seperate', doesn't it?

Ape.of.Gods

So you split the two sides and leave a gap? or can you just "cut" (Maya Term) the edge and that would work? Wouldn't cutting up the uvs into seperate islands leave an edge there and not have it blend? Do you keep the low poly in engine hard edged then?

MoP

SupRore, you're on the right track, but while splitting the UV and smoothing groups does increase the "technical" vertex count, if you bevel the edges instead it will cause more performance issues (to do with how graphics cards sometimes handle very small polygons when they're very small on screen, ie. at long range in-game).

So yeah Eld's method is the best in this case. I asked one of our graphics programmers about this and he said that while the vert count for a split smooth/uv group model is technically as high as a model with bevelled edges, the extra small thin triangles that a bevel adds actually result in worse performance in-game.

Mark Dygert

What engine(s) fractures the mesh along UV seams? You don't need to split the faces off the low poly. Even if you split the faces off, there is a huge difference between splitting geometry off and actually adding geometry by beveling it. The first just adds verts the later adds polys and verts.

Joseph Silverman

Ah, okay, thanks MoP.

Vig: Well, I have no idea of the actual technical side of it, but I imagine it needs some way to draw a 'line', I guess? It has to signify polygon A and polygon B as having a UV seam between them, so doesn't it have to read the vertices between them twice, once as the end of uv island A and once as the end of uv island b? No idea if that's how it actually works, just my weird pseudoscience way of trying to visualize it, after it was explained to me.

Ape.of.Gods

Ok, so I answered my own question, cutting the edge and leaving no gap produces the same results(maybe?) but there is still that one pixel edge of hardlines in the normal map and this is with no smoothing groups.

So do I just try to blur this in photoshop, leave as in and accept there will be a hard edge that will most likely get washed out on a tv?

CubeBake

MoP

Ape.of.Gods: No, you need to split the UVs too, break the UV edges on the same lines that you have made the lowpoly edges hard. If you don't split the UVs you are doing what Eld shows in the 2nd example down, which leads to seam bleeding as you can see.

Ape.of.Gods

Ok, but so you break the uvs in a seperate island, but it doesn't need to be physically apart, does it? And what about the small little hard line in the "Cubebake" example, am I doing it wrong? Elds example is a bit far away so it's hard to tell if he has the same result

StJoris

[ QUOTE ]
What engine(s) fractures the mesh along UV seams? You don't need to split the faces off the low poly. Even if you split the faces off, there is a huge difference between splitting geometry off and actually adding geometry by beveling it. The first just adds verts the later adds polys and verts.

[/ QUOTE ]

Wooh you've got me a bit confused in here. As far as I know the shader doubles the vertices on some surfaces depending on some things like if there is a uv seam, a material break , or a smoothing group change.

Eric Chadwick

Welcome to Splitsville

nacire

[ QUOTE ]
but it doesn't need to be physically apart, does it?

[/ QUOTE ]

I couldn't get the result I wanted until I physically moved them a couple pixels away from one another. This will increase the amount of seams in the color map, but for what I'm doing I don't mind as long as the normal map is working without those wonky shading errors!

Ape.of.Gods

Yep, that did it Nacire, got rid of that 1pixel seam. Awesome.

nacire

[ QUOTE ]
Welcome to Splitsville

[/ QUOTE ]

Thanks Eric, very informative. That leads me to another question. Is Eld's 3rd example worth using over his first example. Doing it this way means there are shading groups, discontinuous UV's and the normal map. Where as the first example is no shading groups, far less discontinuous UV's and a normal map.

Mark Dygert

[ QUOTE ]
Welcome to Splitsville

[/ QUOTE ]
Ahh all cleared up now, thanks. That changes things a tiny bit.

Rob Galanakis

Yes, a UV seam creates a duplicate vertex. A vert can only store ONE normal and ONE uv coord. Thus vertex breaks occur at hard edges AND uv seams AND material breaks.

The issue here though is, you're going to have to break UV seams anyway, being it is a cube and all, so the method shown by Eld is definately best for a cube or something very simple. However, if it is not a cube, and there is no UV seam on said severe edge, you are simply better off beveling, rather than breaking edges, especially for something organic or deforming.

eld

uv's split just as smoothinggroups does, but yields a much more perfect result than having to bevel everything like a madman.

There are cases when beveling should be used, but there's much usefulness in using smoothinggroups for normalmapping.


edit:

my example is mainly for mechanical object, enviromental constructed props, hard edges, things like that, things that has normally been modelled lots of times before with smoothinggroups and a photoshop made bump, not actually baked from a highpoly.

eld

edit 2:

And in all cases of unwrapping cubes or such, you'd end up with an UV seam at many of the places already, even with beveled edges, so they'd still count as more vertices than a split up cube.

MoP

Yes indeed... and like I mentioned earlier, small thin triangles created by bevelling can often be a worse case for a game engine than the additional vertex data created by UV or smoothing splits.

Honolulu_Ninja

So, what way is the correct thing to do?
I've been taught that it's the uv-count that counts in the end and not just the tris. And apparantly some engines have better performance if the angles of the normals are much smoother.

If you can bevel the edges and it has the same effect as splitting the uvs/hard edges on the performance, I would much rather bevel since it adds to the silhouette and removes the smoothing problem completely that you get at the edge of the silhouette even if you use the hardedges/split-uv-method.

MoP

Well obviously the more "artist friendly" thing to do is to bevel it since it can give you more control.

However like I said, a graphics programmer with about 10 years experience developing games for consoles and PC told me that the smoothing group/UV split method was better for performance, since although both methods come to about the same vertex data, the bevelling method creates more long, thin triangles which graphics cards don't deal with very well especially at long range.

Honolulu_Ninja

Mop:So basically,
bevel = Closeranged detailed stuff, characters and unique assets.
hardedges/split-uv = enviroments and props galore

Thanks for clearing that up!