Yeah, you might be right. So this is the simplest mesh I can think of that clearly shows the issue. Going to start debugging the import process of this and see if I can figure out what's up... (once the damn thing's finished building).
Although, playing with it some more, it seems that your implementation for static meshes is actually better than the implementation for the rigged meshes. They're still showing lighting issues where the static ones are exactly right. I wonder if it's worth throwing the skeletal meshes through this, too. I'll have a play.…
If the merge is wrong, please make another pull request or send me an email detailing specifically what needs doing. Getting this right is super important for everyone. :)
No, you don't have to do anything extra besides set the mesh to be imported with "Import Normals" or "Calculate Normals and Tangents". It only uses reference MikkTSpace for static meshes right now, though, so for skeletal meshes you're out of luck.
Alright, given it a test. So here we have the world normal buffer for the static mesh (on the left) and rigged mesh (on the right) using an xNormal bake from a high poly rounded-edge cube. Spot on :) I'll give it a shot with mirrored meshes in a bit.
Not sure, I'm guessing they know of its existence. It'll need to be tested on their end and possibly checked out by legal team over its usage rights. It's going to make quite a change to all of the mesh assets in a game that use calculated tangents, so it's no small addition.
Yeah, put up your pull request! I really want to see a fix for this soon. After a couple of days working on this, I'm coming to the conclusion that it could be beneficial to integrate Mr. Mikkelsen's code that calculates MikkTSpace tangents. The methods used in ComputeTangents seem mostly OK to me, but if we do fix this…