Looks like you need to change a cvar to use it, but I think that's fine given the substantial potential differences between the two methods. I certainly don't want to accidentally cause any regressions...
I've been thinking about this patch from time to time and I think there may be some additional performance I can eke out by making some further changes. I will see if I can get some profiling done after I've got the light color temperature patch more ready for prime time.
The skeletal mesh code is still in the diff...I'll be testing more thoroughly later tonight once the engine and shader compiles are finished on my dual-core , I think he just might not have noticed the change so he didn't say anything about it. When I get everything running I'll toss a breakpoint at MikkSetTSpaceBasic_Skeletal and see if it gets hit.
Another nice thing he did was include a BitangentSign parameter that will probably let you use X+Y+Z+ swizzles if you want. Looks like it could be nice for those of us who do lookdev with Cycles render and don't want to compress the normal map twice
Overall it looks like this is still going to be under a teensy bit of further development, but at least it's in master and we'll be able to use it. No more normal map mirroring seams !
Got it running and got an assert while opening up the static mesh editor. Will investigate further later, looks like it has to do with the console variable, maybe it's because I set it in a configuration file. It also looks like Nick didn't capitalize MikkTSpace correctly but I honestly can't blame him. It took me a couple of weeks to figure out the right capitalization myself, honestly. Time will tell whether that was actually the problem (I doubt it but we'll see.)
Looking through it, the code is there to apply MikKTSpace to skeletal meshes, but it's not actually implemented when building the skeletal mesh. Seems it's static mesh only for the time being. Gonna have to be editing back in my own code for a few releases.
I think BitangentSign is essentially the original fSign variable, but renamed to be more clear.
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.
As long as skeletal meshes happen at some point, that will be fine. I know James worked hard to get it working right, and it would be a real shame for that to not get integrated. I think I'm just going to let you guys do your thing for a bit and get my color temperature patch to an integrable and tested state for submission. It's not really the sort of thing that would work well as a plugin I think...
Seems strange not to go all-in while it's a "hidden" feature, but so long as it all makes it in at some stage - hopefully 4.7 - that's what's important.
An update here -- after an internal review by artists MikkTSpace is now enabled by default on both new and existing static meshes. When you update to 4.7 you won't have to do anything special. The engine will automatically recompute tangents with MikkTSpace, assuming the asset has "Recompute Tangents" checked.
Skeletal meshes are a bit trickier because we can only handle import time. We'll update that code as well but have to do a separate review process.
Thanks for your patience
It's a comment by Nick on the pull request, and I found the corresponding commit on Github as well. Still haven't compiled it myself, but there's substantial evidence in the source that indicates that it's happening.
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.
So I've had a recent problem with importing an FBX static mesh (Shed) into UE4. I wanted to check within this thread to see if this error message was something that has been fixed within a patch.
"Shed has degenerate tangent bases which will result in incorrect shading. Consider enabling Recompute Tangents in the mesh's Build Settings."
I'm currently using 4.1.0 and planned to upgrade soon, but wanted to know if a patch has already fixed this problem. I've already enabled Recompute Tangents and I also have checked off exporting Tangents and Binormals within Maya FBX Exporter.
Does it have UVs on all parts of the shed? What do the tangent and bitangent vectors look like in the static mesh editor?
You should definitely hold off on the upgrade until 4.7 final comes out. I think it won't be very long. You could upgrade now and use the preview releases, but I wouldn't recommend that since it's still technically possible although extremely unlikely that things could go very, very wrong and it could be more than another month before 4.7 final is out.
Hello, I'm already asking about this error on UE forum but still wondering there is another way to fix this error "Object has degenerate tangent bases which will result in incorrect shading" or need still make UV for your model for avoid it
and could someone explaine what it means Degenerate Tangets
ZacD: looking at master I see that there's Mikk code for skeletal meshes in Engine/Source/Developer/MeshUtilities/Private/MeshUtilities.cpp. I'll toss a breakpoint on there in the morning and see if any of the methods get called.
ZacD, I've found that as long as you enable the import of Normals and tangents (or whatever. Instead of Compute Normals), and you bake the normal map in xNormal with the "Compute binormals in the pixel shader" box checked, it works very well.
Haven't done any crazy vigorous tests, so it might not be perfect, but for a mechanical skeletal mesh, like a cabinet that opens and closes using animation, it works perfectly.
Yeah and in Epic's typical usecase (50k+ tri characters) the difference is basically invisible. The original tangent space for skeletal meshes is a much better fit for Mikk than the original tangent space for static meshes was.
Replies
I've been thinking about this patch from time to time and I think there may be some additional performance I can eke out by making some further changes. I will see if I can get some profiling done after I've got the light color temperature patch more ready for prime time.
Another nice thing he did was include a BitangentSign parameter that will probably let you use X+Y+Z+ swizzles if you want. Looks like it could be nice for those of us who do lookdev with Cycles render and don't want to compress the normal map twice
Overall it looks like this is still going to be under a teensy bit of further development, but at least it's in master and we'll be able to use it. No more normal map mirroring seams !
I think BitangentSign is essentially the original fSign variable, but renamed to be more clear.
But I'll flag up any issues I find when I do.
Seems strange not to go all-in while it's a "hidden" feature, but so long as it all makes it in at some stage - hopefully 4.7 - that's what's important.
Just as JedTheKrampus said.
"Shed has degenerate tangent bases which will result in incorrect shading. Consider enabling Recompute Tangents in the mesh's Build Settings."
I'm currently using 4.1.0 and planned to upgrade soon, but wanted to know if a patch has already fixed this problem. I've already enabled Recompute Tangents and I also have checked off exporting Tangents and Binormals within Maya FBX Exporter.
You should definitely hold off on the upgrade until 4.7 final comes out. I think it won't be very long. You could upgrade now and use the preview releases, but I wouldn't recommend that since it's still technically possible although extremely unlikely that things could go very, very wrong and it could be more than another month before 4.7 final is out.
https://docs.unrealengine.com/latest/INT/Support/Builds/ReleaseNotes/2015/4_7/index.html
and could someone explaine what it means Degenerate Tangets
ZacD: looking at master I see that there's Mikk code for skeletal meshes in Engine/Source/Developer/MeshUtilities/Private/MeshUtilities.cpp. I'll toss a breakpoint on there in the morning and see if any of the methods get called.
Haven't done any crazy vigorous tests, so it might not be perfect, but for a mechanical skeletal mesh, like a cabinet that opens and closes using animation, it works perfectly.