What is the right way to bake normals?
polycounter lvl 7
I've been having a lot of frustrations baking normal maps lately, and rather then spend forever figuring it out for myself, I am sure someone else has already done the legwork already. What is the right way to bake normals?
I have a cube with some indents that I want to bake. Its my understanding that if you don't make the lowpoly mesh all one single smoothing group, it won't bake the smoothed edges. My problem is if I DO make it one smoothing group, I get this horrible rainbow gradient running across it all when I bake the normal, messing it all up.
What am I doing wrong? How do you bake cubes and other hard surface objects?
I have a cube with some indents that I want to bake. Its my understanding that if you don't make the lowpoly mesh all one single smoothing group, it won't bake the smoothed edges. My problem is if I DO make it one smoothing group, I get this horrible rainbow gradient running across it all when I bake the normal, messing it all up.
What am I doing wrong? How do you bake cubes and other hard surface objects?
Replies
Pictures and what software?
Pay attention to how the object looks rendered or in Engine with the normal map properly applied. That is a quick gauge of success or fail a lot of the time.
Sometimes, Sloppy looking map + Sloppy looking low = Corrected final version.
Oh right sorry, its 3DSmax, and here is the bake I did in Xnormal, the ones done in Max dont look any different though, I was hoping Xnormal would suck less, but it didn't work.
Sorry it's huge I didnt think to reduce. There shouldn't be that rainbow gradient, the door is flat. The way it is now, it looks round on the normal map when applied to things. If the base cube is unsmoothed then it looks right, but then it loses all kinds of info at the edges, like I was taught would happen.
You have two options:
1. Add support loops to the edges so you don't get pillowy shading on your low-poly.
2. Give the low-poly hard edges and risk having weird artifacts on your normal map.
Unless this is a hero prop that people are going to be looking closely at, I'd go for option 2.
Also, I see some waviness on one of the smaller pieces on the right. It's the door knob I assume? Is it curved?
The waviness I know how to fix, I was only concerned with getting the door to bake properly here. In the end I ended up adding loops to the low poly, then removing them after the bake and making it hard surface with each face being its own smoothing group.
I don't really feel like I learned anything about smoothing groups or normal maps or baking by doing this, I just used a cheap work around to get a quick and dirty final product. Next time I find a 90 degree angle I need to bake, I'll be just as lost.
The only thing I can recommend is the Polycount wiki:
http://wiki.polycount.com/NormalMap
http://wiki.polycount.com/racer445%20Normal%20Map%20Issues
Normal maps are not human readable and it doesn't matter what they look like at all. what matters is how they render.
If you render that normal map applied to the smooth shaded door in max it will look perfect. How it will look in a game engine however is another issue.
If the engine isn't synced with Max's baker you will see gradients appearing. this is because the normal map will no longer be counter acting the lows dirty shading as accurately as it should be(as the math is different). Neither the baker, the map or the renderer are 'wrong' they are just not compatible.
The quick way to solve this problem is to use smoothing groups to eliminate the shading gradients from the low so that the normal map doesnt need to counter act them.
as it has been said. use smoothing groups, and split your UVs at smoothing group seams.
Once you have done this bake with am 'averaged cage' meaning dont use ray distance use a cage.
I'd just bevel the edges of the door myself. It's a cube - adding bevels will only increase the scene polycount by a tiny amount.
This is false. If it is on a seperate UV island it needs to be a seperate smoothing group. There are scripts to do this or Textools. So UV first, run the script after your uvs are done and it will set your smoothing groups to what your islands are. This isn't the final solution, but this is the starting point. Adding support edges as people have said is still required in some cases.
If it has separate smoothing groups, it needs to also be separate UV islands - not the other way around. Your UV's need to correspond and be split according to how you have smoothed your mesh (which takes practice and knowledge of how the bake-downs will work)
You can technically break your UV's any which way you want, and are not required to split smoothing simply because you decided to split your UVs. BUT, when you split your smoothing, you must ALSO split your UVs to get a clean bake.
Knowing when to and not to split your smoothing is the real trick
because you touch yourself at night
I was wondering, there is a lot of information floating about polycount in dribs and drabs. but is there any 1 cohesive guide to normal map baking covering the subject end to end. I find the wiki a little disjointed, it would be nice to be able to link folks somewhere, and not have to keep rehashing this same thread Ad nauseam
"There are no hard rules however, you must experiment with different approaches to find what works best in your game."
FECK !
I mean there seem to be 2 paths
Engine is synced with baking app. (good times)
bake and be happy.
Engine is not Synced with baking app. (time to compensate)
Smoothing groups/uv splits
And this, no matter what engine your using.
Anyway, this isn't very clear in my head, so i'm gonna re-read every EQ posts.
The smoothing groups are to make the low polys smoothing as artifact free as possible, meaning the normal map wont have to 'counter' the errors. Countering subtle smoothing gradients seems to be where 'un synced' maps fail.
The uv splits are to stop normal values from being interpolated across broad angle changes.
maps spacing, and bleed are for counter mipping.
90% of the work seems to be going to compensate for the fact that the renderer and baker are no synced.
Thanks guys haha.
Sort of right.
When you have a properly synced baker/rendered, you start to run into issues with resolution. IE: if you dont have enough pixels to represent a gradient, say on a long thin triangle, you're better off setting some hard edges so the gradiation on the lowpoly smoothing is less. This issue are compounded as your texture mips down and loses resolution.
This happens with a broken bake pipeline too, you just wouldn't see it through all the smoothing errors.
So in general terms, using hard edges/SGs is just a way to soften the lowpoly normals, to make the normals less extreme so that the image content of your normal map is a bit simpler, this has a few advantages:
A. Helps a good deal with a broken bake pipeline, but honestly not enough to really get great results, you will still need to use 2x or so more geometry than you would need with a properly set up pipeline, on a complex asset.
B. Helps to get rid of "resolution based smoothing errors"
C. Generally will compress a bit better, as you have less extreme gradients in your image content, that will be more noticeable when the blocky DXT compression kicks in.
D. Can make generating content from CrazyBump easier, as you'll get less artifacts from the smoothing when extracting detail/cavity maps.
bingo! I had been wondering what was causing this.