Anisotropic shading

Cycles internally has an implementation of the Ward anisotropic BRDF, but it has remained disabled.  There weren't consistent tangent directions across polygon face borders, and so the shading would result in a very faceted appearance.

I've proposed a patch that re-enabled the anisotropic closure node, and adds the computation of consistent tangents across meshes.  It requires the artist to lay out UVs on the mesh, however, or else it results in the object turning completely black.

The tangent machinery calculates tangents based on the change in position along the U direction of the UV layout, so if the artist deliberately creates a UV seam or break, that will also be reflected in the shading.  Buyer beware: the UVs can allow you to carefully control the 'brushed' direction of the surface, but you'll have to strategically hide the seams if they are visually distracting.

Here is a quick test showing the results.  The top-left sphere is just diffuse (for reference), and the top-right greenish sphere is the existing glossy specular, which is not anisotropic.  The other sphere, box, torus, and Suzanne are all using the anisotropic closure, with some fairly simple UVs laid out by yours truly.

On my GTX 460 this took about 3:25 to render, with 1000 passes.  I used the Uffizi lightprobe for the background, with HDR range and importance sampling (my other patches).  The combination makes for some decent metal appearances.

If you look closely, you can spot a seam or two.  The UV sphere is one I generated on my own with a python script (that outputs an OBJ), and I did so in order to very carefully control the UV layout at the poles of the sphere.  Even with that care taken, there is a slight seam apparent at the top.

Edit: 7 months after submitting the change, now that blender 2.64 is released my patch was accepted into trunk.  Brecht added a couple of extra goodies to make sure tangents can be gathered other ways, too.  Thanks, Brecht!

HDR Texture Sampling (pt 2)

I had proposed a patch for HDR texture sampling a ways back, and Brecht has committed it (with a few small modifications).  I feel like there's a texture slot bug lurking in there that I may need to fix, but I'll have to verify that.

Essentially, the change allocates 5 of the 100 texture slots to be full floating point textures.  Generally the data set there will be linear (and Brecht changed the monikers for those to be "color" vs. "non-color" instead of linear vs sRGB).  Any source texture that is naturally a float format, such as EXR or 32-bit float TIFF, or HDR, will automatically get one of those slots.

A couple of things to keep in mind:

1. You've only got 5 full-float texture slots, so be judicious in your use of them.  Any textures you don't want using the those slots need to be saved in a format that is not floating point on disk, and they will land in the regular texture slots instead.
2. Anyone who was using the 100 slots before for non-float textures, though, is in for a surprise; they've lost 5 regular (non-float) texture slots.  Never fear, all you have to do is change some textures to a float format (such as EXR) and you'll get back to the 100 total slots that way.

The management is a little bit manual for now, but the long-term strategy for Cycles I think is that texture management will be done in a different way.  Textures will be packed into layered versions, and the sampling of them will occur using a more manual sampling (that is slower but higher quality).  This way the 100 texture limit will be eliminated, and better sampling like anisotropic kernels can be used, even on GPU.