[MAYA 2016] Unlock / Lock normals changes normals? why? is there a fix?
polycounter lvl 6
I have a model and whenever I lock or unlock the normals it changes them. This is an unwanted result.
I need to lock them so that I can make edits to the mesh without breaking the normal map baked onto it. I need to move each vertex along it's normal to make the model 'fatter'.. when I do this, my seamless normal mapped model becomes a seamFUL mess.
Locking the normals SHOULD allow me to do this without breaking the shading...... only if i lock normals the shading on the model changes and becomes all faceted.... even though the vertex normals haven't changed, according to the little normal direction thingy. If I then unlock them, they change yet again and become even more faceted.
I've always known Maya normals are terrible, but is this working as intended? Is there a fix or workaround I could employ . (rebaking is NOT an option).
Even if i try to transfer the normals from a duplicate that isnt broken, the normals copy over incorrectly and look faceted too.
any help would be greatly appreciated.
cheers
Replies
This effectively means that there is now no way for me to check normals in Maya as I can't guarantee at all that they are correct. I now have a scene that is full of Normal map seams (or hard edges) that actually look perfectly ok in the game engine.
Normals in Maya have always been a problem.... surely there is a way to fix this? surely....
cheers
The normals need to be locked because there is a hard geometry edge there in the example (tho once the normal map is applied it will be appear as a smooth edge). if the normals aren't locked, then as you move vertices around the normals recalculate... so those edge normals are no longer at the values they were when the normal map was baked. The effect of this is that the normal map no longer smooths over the hard geometry edge and you can see the seam.
You can scale a mesh uniformly without affecting the normals. anything else will cause the normals to recalculate unless they are locked.
The model is already triangulated and was when it was baked.
I'm thinking it's less a problem with vertex normals and probably has more to do with tangents and bi-normals being calculated incorrectly.
Here is a pic and explanation....
A. Original unlocked normal
B. Unlocked normal that has been moved along the verts normal Axis. (note how now the normals have been recalculated on the geometry (the green lines) and so the normal map can now not possibly be seamless.
C. Original Locked normals.
D. Locked normal moved along the verts normal axis (Note how the normals are still identical to the original, even tho they have moved. this will result in the normal map still appearing seamless)
E. mesh with normal map and unlocked normals (before translation of verts along the normal axis) Note no seams.
F. The same mesh with unlocked normals after verts have been tranformed along the normal axis. (note the big ugly seam now created along the bevelled edge. This is why the normals need to be locked. only it's pointless locking them as locking them changes them, or seems to change something. making it useless.
I feel that you are mistaken in your assumption that the seam shouldn't appear there when transforming the verts along the normals. if the normals are unlocked, then when you change the vertex position, the normal will change.... as there is a UV seam there, unless you had a dynamic normal map that accounted for the change in geo normals... then the seam will appear. that's just how normal maps work. they offset the normal of the geo by the value stored in the nmap. as there is a UV seam, you have 2 opposing values... which become more apparent the more the original geo normals are changed from what they were when the bake took place. if there wasn't a UV seam there then the seam wouldn't appear. i think this is the bit we are missing each other on. but not having the UV seam would cause many other problems.
anyway,.. i feel we may have gotten off track somewhat... as what I was hoping for was a way to Lock the normals without it messing them up. (in the maya viewport).
it all works fine... other than i can't review it in Maya, as Maya displays in incorrectly.
ok. so i found that you can actually display the tangents in the viewport, and it appears that it is in fact those that are getting screwed when I lock the normals.
in the pic, observe how in the locked version, all the tangents have now become misaligned even tho the normals stay aligned.
So, least now I know the cause of the issue, but sadly still no closer to a fix. unless there is a way to lock tangents?
http://radks.blogspot.com/2012/05/maya-normals-locking-and-what-it-does.html
I wonder if lock/unlock is designed to ignore tangents or just an oversight?
The best way to do this is through transfer attributes, sampling by component. So you duplicate, run the transfer and do your edits on the copy. But I just noticed that TA puts the normals in a locked state so you're in the same boat for unlocking. If the asset is final aside from the shape tweaks there's no reason to unlock at this point, no?
late edit: forgot to mention you seem to have two "ghost" shapes attached to your models which should be deleted.
The reason for not wanting to rebake is that we have variations of a base meshes that share the same normal map. so rebaking for the edited mesh will break it for the rest of the variations. This is why locking the normals is so important.
I think the tangent thing is a bug. i posted on the autodesk forums and they seem to think it's a bug... but one that has been there for like .. ever. It only apparently happens if you lock the normals on a hard edge. it then breaks the tangents on all verts connected to that edge. I can't imagine why that would happen by design..... but then I don't design 3d apps for a living so maybe there is a perfectly good reason for it....who knows?
I have tried transfer attributes before. it didn't work, but i'll give it another go today.
You are correct, once I have locked the normals there is no reason to unlock them ever again. I mentioned the unlocking behaviour as i thought it might be relevant, but it turns out that is by design.... or at least expected.
Thanks for taking the time to have a look
Really appreciate it.
cheers