[Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [51258] trunk/blender: Cycles: Anisotropic BSDF enabled, with tangents now computed from the active UV map.

[Morten Mikkelsen]

>
>
> Ok, I can see we have an issue with singularities, but using
> mikktspace does not seem ideal for anisotropic shading. There's still
> many cases where you can line up the tangents quite well at UV seams
> even if the UV's are not connected,


Generally this is not the case. It goes bad at least 95% or more of all
cases where you try to just average tangents from
an unwrap no matter what. Borders are splits when tangents aren't aligned
so odds of this going well are close to non.

results if you average with two neighboring triangles, but not the
> ones on the other side.
>

That's not what happens though. What happens is that all the tangents
surrounding the pole get added together.
What you end up doing is stretching the highlight in a very distorted way
across the entire top row of triangles.



> As I understand it mikktspace is based on comparing UV coordinates,
> whereas we should actually be deciding merge/nomerge based on the
> difference between tangents in UV space, with some threshold.


If you were to try and achieve normal mapping using this approach then I
can confidently tell you it's an awful solution.
The idea has been tried and done to death by many of us game developers
back in the day when the concepts of tangent space were still young.

My recommendation is definitely that you use mikktspace for normal mapping.
You use it for aniso as well if someone wants to use unwrap based tangents.
And if someone wants to use orco then you synthesize the tangents. It's the
only proper/stable/good way to do it.

M.Fox. spend years on aniso in blender, studying various cases, and I am
sure he can tell you first hand the per vertex averaged triangles just
didn't work well.
He was getting errors all the time.