* Added a Brick Texture Node to Cycles.
* Based on the Blender Internal Brick Texture with some modifications.
* Tested on CPU and GPU (CUDA & OpenCL)
Documentation: http://wiki.blender.org/index.php/User:DingTo/CyclesBrickTexture
ToDo: Only works correct on flat surfaces, like a Plane. If you attach the shader to 3D objects like a cube, the mapping is not correct on the Y/Z vector.
Thanks to Lukas Toenne for fixing a issue I had with the Node code! :)
checked this function against the previous method using random rotation inputs and compared results, while this isnt exactly the same the results are very close and acceptable in both cases, also checked baking actions that the resulting FCurves are good and give matching rotations.
now customdata is interpolated into a temp variable and applied at the end of each layer interpolation function.
So this now works for CDDM customdata interpolation and avoids duplicating the customdata when the source and destination overlap.
result. This wasn't really guaranteed anyway, because of numerical precision and
possible asymmetry in the triangulation, but we can do a bit better.
Now we bias the choice of how to split a quad into two triangles slightly
towards one of two possibilities, so that in case they are equal, floating point
errors do not decide the direction and symmetry is preserved.
Makes it much more responsible, especially when small brushes are used.
Could make sense look into using full multithreaded buffer update when
brush is large enough.
Behaves in exactly the same way as bright/contrast compositor node.
Some code could be de-duplicated, like contrast formula and mask
influence, but wouldn't call it stopper for commit since it's
already needed for grading Mango.
Blender original code (NaN likely) was relying on strcmp to sort the list of controllers.
As it happens, in strcmp 10 < 2, thus the list was never in the right order.
The curious thing is that in 2.49 it worked, but I think it did because the make_unique_prop_names function was called twice. Strange ;)
The solution is to use blender BLI_natstrcmp to do natural sorting
The vertex shapekey index is now no longer copied, and propagation of offsets
in the basis to other shapekeys is disabled if new vertices were added. The
reason being that the propagation will only be done for the old vertices leaving
the new ones behind, and so doing e.g. subdivide + translate on the basis would
create a mess on other shape keys.
