Well, not really, I'm still pretty young, but still, I'm starting to get ticked off with Normal Maps royally.
Here is my issue, no matter what kind of model I bake, I always get seam issues.
At first, I thought it was me being bad at baking, especially on hard surface models, but honestly, at this point I think it's something else that I must have missed and not thought about because I don't ever recall having this issue with older bakes of mine.
Fun Fact: I use xNormal for baking, if that matters.
As you can see, seams on my model, no idea why they appear there AT ALL!
This is how I UV-mapped my model and baked, and yes, I do also get seams in the middle of my model, but not as bad the previous image.
Another part of my model, this model is less 'stressed' since it's a very relaxed cylinder (EI: no harsh bends), but damn it, it still had problems with seams and it gets worse when a Spec Map is applied!
Honestly, it's starting to vex me, I don't every recall having so much issues baking stuff on my models, and then suddenly, BAM! I'm getting these issues on all of my models.
Anyone have any ideas why? Is the baker? Is it my modeling? It's my UV? I can very well upload my model if anyone wants me to, because honestly, this is really vexing for me.
Replies
What is your final output target? Is it max or a game engine? If its max, then bake in max. If its a game engine, then see how it looks in engine first, then see if you need to change things.
in maya if you export using xnormals sbm format and check off include tangents and binormals i can make xnormal bake using the same tangents as maya's viewport, and once i epxport as fbx for udk, if i use that same option in the fbx formate it will also make udk use something close to maya's tangents.
not sure if syncing xnormal to max is possible like in maya but the 2nd part is.
http://www.3dmotive.com/exportingqualifiednormals/
Basically, to cut it dry, not matter what I use to Bake my Normals (Max or xNormal) I can't get them to get rid of the seams. Baking in Max, while alleviates the problem somewhat, still persists with the issue of the Normal having seams.
passerby: Well, I figured that much, which is what confuses me even more, because no matter what I use to bake my Normals, I always gets seams which show up. I even did that silly thing of UV seams = Hard Edge dance on my mesh, and still, the same normal map.
Fun-Fact: I wanted to act a little clever, and decided to import said Normal Map in Mudbox, and try Smudge/Paint over the seams, but Mudbox lacked any proper smudging tool or any tool that worked properly with Normals and didn't ruin them, so that idea didn't fly.
For a simple portfolio piece you have a lot of choices - one of the safest being baking in the legacy Max baker map type and redering using scanline (non realtime).
If you want realtime and no artefacts I would recommend baking in Maya and displaying using Brice's CGFX shader. Very clean and straightforward - it has long been my favorite.
Another very safe route is baking in Xnormal and displaying in Xnormal too. A bit more annoying to work on while texturing tho.
Regarding Xnormal : I dont think that its bakes are synched with any 3D apps anyways. So if you display that in Max in Maya you will get artefacts especially on non organic models.
If you are targeting at an engine, if it isn't properly synched then yes you will have to be extra careful.
Marmoset could be a good choice too - I would suppose that it is well synched with Maya's baker. And if anything, a model that looks 90% artefact free in Marmoset should be pretty much perfect in Max using the 3PShader in Quality Mode. (EQ will be able to correct any inaccurate information, as I am not 100% sure of that. But I can confirm that Maya and Marmoset 1 worked very well together, didn't try since then)
You could also go oldschool and bake in Doom3 renderbumb and drop your model in simple box map. This is how I did my very first normalmap models and since the engine is perfectly synced with its renderer the bakes are flawless (looking back at it, I'm glad I went that route because I didnt have to worry about artefacts like here back in these days - a blissful ignorance!)
(BTW : by "synched" I do not mean "same swizzles". Swizzles are trivial to identify and are a non-issue, it is just a matter of observation. I am talking of normals and tangents syncing IE the actual math behind the normalmap generation.)
(BTW 2 : Look into face weighted normals, you might be able to find scripts editing your object normals with that technique for improve shading. It can potentially help getting very clean bakes.)
http://www.3pointstudios.com/
(I use my own shader made with shader fx)
You will see all seams in the mesh that are there bc the uv-splits/vertice normals correlate in a bad way. Even without normalmap!
You can fix these seams by changing the uv's or the model (replace vertices, add support edges)
I'm not sure if 3ds max / hlsl is special in that way but I can't check if this also works in maya.
pior: Thanks for the write-up, and I did all that, I tried in Marmoset, Max (dx, scanline, MR), UDK, xNormal AND Blender to render it out. I tried all kinds of bakes, and renders and viewports, still, at the UV seams, I get seams.
I basically made all kinds of Mix-n-Match here and there, the seam remains.
ZacD: Thanks, tried that, but no dice. I even tried 3PS, still no dice. The seam remains. Both same results in Max and UDK.
Visceral: Haha, I wish. I tried that, but the only software I know of which even has smudge I have access to is Photoshop and 3DS Max's Viewport canvas.
So far I found smudge to work wonders on normals and massaging them into shape, but in my case, the Normal Maps are so bent in colors at the seams, that editing them in anyway, makes it worse.
Yes, even the 128 trick to flatten seams doesn't work.
rollin: Thank for the info, although I did some time ago make such a shader, I'm not a big enough expert on the subject matter to know any better about said issue. Did it look something like this?
I always keep in mind when cutting up my UV's, but I'll be honest, I do alot of naked statues and such, so this shader really doesn't help me unless I'm doing something more complicated then a naked character.
Cap Hotkill: Thanks, I just tried it, but it still shows the same issue as in Max's viewport and UDK.
I think I counted about 3/4 different bakes uptill now in my folders, bleh.
Maybe I'm being too paranoid, but no matter what I do, I still get seams.
This is how it looks like, my Normal. The chest part on my character is the heaviest culprit in this:
I decided to upload a portion of my mesh which is having the most issues. Both low poly and high in a Max scene.
http://www.mediafire.com/?kgvic4fkec6kv31
Can be opened with Max 2010, if anyone could take a look, I would very much appreciate it as it's driving me up the wall. I literally came to halt on my porftolio, because every single mesh I bake out has this.
Other seams are harder. It looks like its just a bad placement of these seams. You see, UV islands are rotated and spaced all around, and border edges for these islands go in all possible directions, so when normal map is baked, border pixel just don't match. You can fix it by either straightening border edges vertically or horizontally, or at least aligning islands in a way so their borders run in one or close to one direction. That will not remove the seams, but they probably be less noticeable.
Sorry for my english, hope this make some sense.
Thank you alot, my good Sir!
SsSandu_C: Hey, thanks for the test, I looked the Bake and it's very clean. While the seams aren't obvious, I can still see the them, is this me being very OCD and picky, or is this normal?
For example, here is my latest bake without anything fancy. 3DS Max, rotated shells for U/V color transition, one SG and all that, in shader.
No other map gives me this issue, at least, from what I could see in my Bakes, just curious if it's normal?
Honestly, is it me? Am I being too picky? Does it matter? I'm hiding the best I can my UV seams around crevices, flat and sharp surfaces on my model, so the seams can be less obvious and be easier to control and manage, but even so, I can still see the seam.
Or am I just bad at this?
PS: Does it matter if I use a Cage or Ray bake? I used both, and they both come out with the same UV seams, so maybe I did something wrong in my mesh?
You need to zoom in super close to even notice it, and there isn't even a diffuse map on it yet. Once you get a texture, there is no way in hell you'll even know it's there.
if this is for a game model no-one would ever notice that.
It's just in my head, if the math used to create the texture is = to the end product math being used to display said texture, then there is no reason for said texture to have ANY issues.
Gosh, I so wish we could harmonize normal maps.
As everyone said these seams are acceptable, and when you have your diffuse applied it will be even less apparent.
Marmoset isn't properly synced to anything unfortunately, baking in maya and then doing "lock normals" before export may be the closest bet for marmoset display as well as setting hard edges to uv seams helps. Also make sure to export your model with the Maya plugin, using OBJ may be less predictable.
Really, to get a properly synced, realtime viewport display for your art, you have essentially two options that are widely available to the general public(I say this as there are a variety of studios who have propriety engines and solutions).
A. Bake in Max, use 3point shader with QM, even the free lite version.
B. Bake in Maya, use Maya's standard material system(IE: blinn or something). YMMV with 3rd party Maya shaders.
If you know you're using a workflow that ISNT synced, simply place your uv seams in the least obvious places... Hell, you should always do this, so you don't waste time fixing texture seams on areas you'll never notice.
A. Place seams on the least likely viewed part of model
B. Place seams along natural highpoly seamlines or intersections
C. Place seams along areas which do not have a high amount of detail
D. Avoid using an excessive amount of uv seams on organics, often times a slight bit more deformation in your uvs is worth less uv seams, for technical and practical reasons.
see this:
http://www.polycount.com/forum/showpost.php?p=1355044&postcount=2161
and this:
http://www.polycount.com/forum/showpost.php?p=1375390&postcount=583
No baker that I know of is synched with UDK
You're correct, no baker is synched with UDK currently.
EDIT: OK, so this is the question I have now, why don't people create the correct tangent 'bakers' for their software before releasing it? It doesn't make sense, atleast make the information easy to access so people know. I just found out today thanks to EQ that UDK is NOT synched with anything except Max's old kaput baker for a lack of better terms.
And no, old kaput baker wasn't fun to work with, reason it died a painful death...hopefully.
For example, from what I gathered, CE3 and Doom3 had their own bakers for this very specific reason, while UDK doesn't, or it did have one, but not even Epic used it or liked it, and in some cases, they even used xNormal for baking about a year ago or so.
Yet at the same time, no one uses Morton Tikk's (xNormals and Blenders) tangents currently because it's too new, but xNormal does have it's own SDK released to public, so people can create their own math in C++ for their app if they so wish for the tangent.
Why doesn't (for example sake) Epic write down the math and make it available with UDK for xNormal baking since no other software matches their tangents? Not only is it faster and saves time, but their work is cut in half, plus, in spirit with UDK being free to download, it would accompany xNormal just fine.
Please note that I use xNormal and UDK as examples. Hopefully, you guys get the gist.
I mean why would ANY company out there make this more complicated then necessary? Is there a reason? For me, this is on par with the stupidity (sorry about that, real frustrated here) with saying "Flip green channel for compression issues" when the correct answer should be "Make it half and uncompress it" or "Store green channel in Alpha for better compression ratio" if that is a thing anymore.
Same thing with software manufacturers, like Autodesk. Instead of fixing and giving options to their bakers in their respective software, which represent correct 'values', they just said "Oh, Mudbox is our standard, so will try to work from there", when last I say, Mudbox had less then flattering results in baking. Hell, they still didn't include a correct Bump to Normal converter in Mudbox for painting detail in your Bump Map.
I mean honestly, does Mudbox even have a standard to which it is synched too? Maya perhaps? I don't know, and I don't care for that since it's locked.
There some things which are more logical, and have a decent explanation behind it, but having software in which it doesn't have an external 'helper' which even matches up to the math internally in the engine is just bizarre (and that was on the more flattering words I could find).
EarthQuake, how did you guys do it in Brink? What there a baker's you guys used which matched up 100%, or did you guys have to really compensate in post-bake workdown? Everytime I fire up Brink, and study the models, I cannot believe on how well the normal maps look on it, so I was curious.
Needless to say they weren't fun to work with.
I also would love for Epic to just release a proper tangent basis setting file for xNormal, but for some reason they don't seem to care about the issue (my impression). Sorry, I wish I could help create a xNormal tangent basis calculator for UDK but I don't think I'll ever bother to learn C++ or at least not any time soon.
Mudbox is following Maya's tangent basis according to some posts in the Why you should NOT trust 3ds Max's viewport normal-map display! thread (around page 21). See this.
In all seriousness if you don't need any of UDK's major features you might want to consider just displaying your work in Max's viewport using 3point shader or Blender's game engine using xNormal bakes for portfolio work. Obviously this isn't a solution if really need UDK or are making an actual game...
Thing is, I would like make in my free-time, a small game if possible (something really simple) so I try and get my hands dirty with UDK whenever possible, but my strengths are as a person, the art area of things (sculpting, sketching, shaders, etc) so I always try to compensate my lack of other technical areas with what I know best to make up for it.
So yeah, I'm kinda hung up on UDK, especially the shader stuff. Guess till Epic 'fixes' this stuff, I'll look at another engine. I heard Unity is more compatible with xNormal, especially with FBX tangent export for baking.