A Practical Guide On Normal Mapping For Games
polycounter lvl 10
As we all know, surely, that Normal Mapping isn't easy. There are a lot of problems that can emerge when you try to bake normal maps. I decided to start this guide after being enormously frustrated with the lack of information and the prominence of downright wrong facts on normal mapping. I, as most people, was always confused about this process and had to spend countless hours on searching forums for answers.
With this guide, I tried to encompass everything there is to know about today's process of creating normal maps for games and make it as simple to understand as possible.
The guide was inspired by Joe “EarthQuake” Wilson's work here in the Technical Talk. W
Right now it's Work In Progress, so there's bound to be a lot of mistakes on my part. If there's anything you want to see fixed or added, please inform me and I'll try to do what I can to fix it as soon as possible.
A Practical Guide On Normal Mapping For Games
With this guide, I tried to encompass everything there is to know about today's process of creating normal maps for games and make it as simple to understand as possible.
The guide was inspired by Joe “EarthQuake” Wilson's work here in the Technical Talk. W
Right now it's Work In Progress, so there's bound to be a lot of mistakes on my part. If there's anything you want to see fixed or added, please inform me and I'll try to do what I can to fix it as soon as possible.
A Practical Guide On Normal Mapping For Games
https://docs.google.com/document/d/0B02lElvs8BcvYllmQWpXUGxod3M/edit?usp=sharing&ouid=117284901335317164948&resourcekey=0-qyVFd0vGiqJl56hPbOnRWw&rtpof=true&sd=true
It's a Microsoft Word document, if you download it and open in Word you will get access to Table of Contents, it's very useful.
Hope you like it
Changelog:
Jan.13 2015:
Added 3rd method of dealing with slanted details
Added a simple Troubleshooting section
Jan.11 2015:
Expanded a bit on Baking
Spelling, formatting
Jan.10 2015:
Added explanation of Tangent Space
Expanded a bit on floaters
Expanded on baking
Added UV overlapping section to Building Low Poly
Expanded on Slanted details
Added Table of Contents
Formatting, spelling
Replies
My first quick crit is that the design could be improved, but I won't go in too muhc depth until it's all finished up!
Didn't get a chance to really read over all of it, but I think you could reword the section on '3.Intersecting geometry for combining in low poly' since I didn't totally understand what you were saying until my co-worker explain it to me.
Also for the skewing section I would add in a link to PeterK's skewmesh trick. Here
Looking good otherwise!
AdvisableRobin, will try to add everything in the next revision
Now don't get me wrong, I can tell by reading the document that you know what you are talking about, and you are just basically taking a bit of a shortcut for the sake of things being easier to follow. But still, I feel like there should be at least a note or a special in-depth section explaining further why and how these "gradients" are totally fine when the pipeline is properly setup and synchronized.
The reason why I am pointing this out is simply because I personally had to deal with artists that needed to "unlearn" their fear of normalmap gradients, and that's just a bit of a waste of time really ... especially when the pipeline *is* properly synchronized to begin with
That's what I tried to tell. I said many times in the guide that gradients aren't a bad thing at all and you can get away with most of it if you use a synchronised workflow.
Maybe I should rephrase it a bit, because I never wanted to tell that gradients are bad...
Robin : it depends ! Some engines are pretty liberal with that sort of stuff and go all hardcore on the compression, which impacts surface quality. Some have specific compression flags for normalmaps. And then there's also everything else : like, using high color depth source normalmaps saved to EXR to get the most accurate data as possible before a well optimized compression routine.
On a side note : Frank, thank you for mentioning the triangulation issue. I really, really wish more people knew/understood this
I always assumed that Xnormal is synced with Marmoset 2. I guess it isn't?
As far as I am aware, Source has a perfectly synced solution through Handplane, and IDTech is perfectly synced with itself as it has its own, internal baking tool (not sure if this is still the case tho, but it certainly was back in the IDtech4 days). As far as other engines are concerned, it's a case by case basis really. Both Cryengine and Unreal used to have strong problems in that department for years, but these might have been addressed by now ... maybe ? One thing I can say for sure is that working with a perfectly synced engine really is a huge deal. It simplifies the processes alot, thus saves a lot of time, and it looks good !
Some interesting details being discussed here :
[ame]
Good luck man - this document of yours is already a goldmine of information for anyone starting out. It's very cool of you to put all this together, as it will without a doubt benefit a lot of people !
Max
Maya
Xnormal/Mikktspace
Marmoset (our own standard)
and in 2.07 Unity as well
So you're saying that Xnormal is perfectly synced with Marmoset 2? Just to clarify.
What would be a good example of a non-synced workflow, for demonstration purposes?
Also, does anyone know all possible pairs of Engine-Baker there is that provides synced workflow? I guess that's something that needs to be in the guide...
Yes, if you choose to have TB2 displaying Xnormal/Mikktspace with the preference setting or on a per object. It's not set that way by default.
Great, that's what I was working with when I wrote this guide. So I guess it's safe to say that all the practices written there apply to the synced workflow.
A non-synched workflow would be baking in 3dsmax and displaying in max viewport. This was busted last I checked, but could have been fixed in latest iterations.
I think it could be an idea to include more in-depth technical info in your "Tech Babble" part in the beginning. Explaining what a vertex normal is, how it affects the resulting lighting, what the normal map actually does in the lighting calculation, etc.
The big advantage of Mikk over Max/Maya tangent spaces is that if you reuse UV space in any way, whether it's mirroring a normal map or reusing an element, the shading will always be correct, which isn't the case with Max/Maya tangent spaces. Mikk works for this because its tangent space calculation is order-independent; the tangents depend only on the UV layout and the vertex normals. If you've ever wondered why you get a seam in your shading when you mirror a human face (e.g.) in Max, it's because the tangent basis is order-dependent. Use Mikk instead if you have the option.
Cryengine is still not particularly synced to anything last time I checked, so if you're working with Cryengine it's best to bake in Max and make sure that your vertex normals correctly capture the low frequency details in your high-poly mesh. In fact, it's probably a good idea to do this for Unreal as well, because you'll get less artifacts from texture compression and lower mips.
Is it something related to smoothing groups/hard edges/custom normals? Because when I bake normals, I'll use xNormal with triangulated .obj files including exported normals with hard edges (if needed) with UV splits on those hard edges (custom normals is a work in progress in Blender development, so hard edges/"smoothing groups" are supported only).
EDIT: Sorry for noobish question.
kodde, the primary goal of this guide is to be as easy to understand as possible, I'm trying to avoid unnecessary technical information... That's why it's a Practical guide. I will probably put some links in there for people who want to know more.
Actually, I used a synced workflow throughout the guide, by baking in Xnormal and displaying in Marmoset 2 with proper tangent space selected. As I see it, a synced baker-engine pair won't save you from the worst possible gradients.
Rather than : "a synced baker-engine pair won't save you from the worst possible gradients", it's more like : "a synced baker-engine pair allows you to not even have to worry about what your normalmap looks like".
Now again I totally understand that not every scenario is the same, and in many cases the "tricks" are indeed necessary because things don't always go as planned. But still, I'll take Source/Dota2 as an example. I see artists working with it jumping through all sorts of hoops and hacks (arbitrarily adding hard edges where there is no need for them to begin with, doing funky things to their normalmaps by hand, and so on) even though there is a perfectly synced workflow available (Handplane conversion) that allows users to not have to worry about any of that, saving hours of headaches in the process.
This is why I believe that technical information like the one Jed is providing above is super important, as it helps us understand the very root of issues. After all, game dev is quite technical by nature !
1. Bake Object Space map from Xnormal
2. Convert to Unity tangent space using Handplane
(To be sure, I did that again using Unity tangent space plugin for Xnormal, but that gives the same result)
The result:
moved lighting source a bit
As you can clearly see, I couldn't get away with extreme gradients even using a perfectly synced workflow. I'm pretty sure Xnormal does the same job anyway.
Here is another example related to Source. Many artists are running into the issue highlighted here, which is actually caused by a cool "hack" introduced by Maya engineers and set as default without anyone being made aware of it.
Notice how the normalmap with "strong gradients" is actually the one giving accurately shaded results, as seen at the bottom of the texture. And it just so happens that the part on the middle right has less shading ; but it's irrelevant, because once you know for sure that a given pipeline is accurately synchronized, you don't have to worry about any of that.
I believe that the best course of action is to always keep digging, in order to make the tools more and more reliable. Of course it's good to know of hacks when there is no other choice available ; but the bigger picture is all about making the life of users easier in the long run
This is an issue with the way Unity uses tangents in forward rendering, not with Handplane.
There's a couple of ways around it...
- Use deferred rendering (Pro only).
- Roll your own shaders and convert from tangent to object space in the pixel shader, then do lighting in object space.
- Normalizing the view & light vectors in the pixel shader helps to reduce the effect, but not remove it (but it's a bit easier than rolling your own fully custom shaders).
Still, the new "cool trick" introduced in Maya can cause a lot of issues - I've seen it happen in productions at the studio, and I see artists struggling because of it online too
Can't wait to hear what you think about it.
I already listed this method, it's on Page 19
Download "RNM Normal Map Combiner"
Mari also has this algorithm built-in and of course there's a custom Substance node for it as well here, so there are definitely options that people have when it comes to using this technique.
Oh, I just never heard about these methods before! Thanks for informing me, I'll definitely list them in the guide.
You're welcome, I hope you find it useful.
I had no idea overlapping/mirrored UVs need to be offset on normal map, why is that necessary?
Also, now I'm a bit confused, right now I'm stacking all of the UVs in 0-1 space, no matter the texture map type. Offsetting UVs is needed only when doing the bake for the normal map? not for all of the other types of textures?
I'd recommend just leaving the UVs offset into UDIM 1002 anyway, unless you're working with a megatexture engine that's capable of rendering multi-tile UVs. But that's a pretty special case these days. If your UVs never overlap in 0..1 UV space the baker can't make mistakes.
Every time I bake stuff I almost have to figure out these techniques from scratch as nothing works consistently on everything.
So I've made HP and LP in 3ds max. LP, kas a projection modifier on top of it (edit mesh modifier in between) I export HP and LP as *.SBM.
LP.SBM has the cage built in, so I turn it on in xnormal and bake it. Bakes visually come out without much artifacts and look fine in PS.
Yet in toolbag I can't get it to show up correctly (I presume it wouldn't work anywhere with my setup).
So I've created this image to illustrate what I mean:
Glitches showed up randomly even though meshes are absolutely the same.
Sorry if this is off topic.
EDIT: Yet edges near on top are completely fine and smooth. Must be something about the smoothing groups and how I split the UVs.