With 2.80 upcoming, I decided to do some experiments, and maybe convert some of the old stuff.
For this first one I know that in Cycles we can’t (yet) do stuff that depends on scene brightness, but Eevee have this awesome Converter/ShaderToRGB node. With that in mind I loaded up the BMW test scene and used Eevee to generate a render where the color changes with how much light that pixel receives.
I now simply mapped that image using window texture coordinates (rarely used) to the main material of the car only, and used the color information to cause a hue shift in colors.
Made my own ShaderBall where the UV is not made for painting on, but for help defining coordinates and aniso tangent space. It’s low poly with subdiv, and I can’t fix some of the stretching errors, particularly when trying to maintain direction. UV has overlaps and not suitable for painting or baking. Ball is basic, the base has some protrusions for SSS tests, a plane with wrong normal (in case I need to account for that), and two thin boxes in the back for SSS estimation and backlighting experiments (strong area light behind). Basic HDR for main lighting.
ShaderBall_AnisoGGX - GGX is fine on its own if you want long stretching on metals with some visible roughness.
ShaderBall_AnisoBechman+GGX - is required if you want a high polish appearance while being able to stretch strong lights (here, the sun). Only GGX doesn’t work at all. Mix factor is 0.01 Beckman. Beckman is 1.5 roughness and 1.0 aniso, where aniso direction is modulated with a stretched voronoi to produce ±0.001 variation. Color and roughness is fixed, and only a bevel node for normals. The GGX can be pretty much whatever.
ShaderBall_Cast - Some kind of cast appearance. The basic idea is using a dense Voronoi/Cells to generate random colors, which is then used to modify normals directly (going through a some stuff that also does normalize). Similar to how you would do carpaint flakes and snow glitter I guess. A “grease topcoat” on top which uses a reduced impact version of the same normals. Nothing fancy.
ShaderBall_WoodenBoardsUsingBricksAndLookupTexture - using three brick generators to control random color generation and variations of brick mortar size. Combined with a high resolution seamless wood texture (pregenerated using Skorupas wood nodes and made seamless), it gives a pretty decent result for staggered boards. Wish the top four parameters could be controlled though.
SSS marble stuff, using a noise generator to randomly mix 4 versions of the same seamless texture (scale and rotation). This group is then called three times with different settings, and using a modified six-planar box mapping node simply projected along xy, yz, and xz. Very versatile way of doing box mapping to very effectively hide texture repeats.
Just a test on using 4D generators to produce loopable generators in 2D space using a circular lookup on UV and #frame for Z and W parameters. Appears to work, but haven’t tested it properly yet:
My method of camouflaging repeats in seamless textures, using differently sized, mirrored, and rotated versions of the same texture and blending between them. This works better than the voronoi scramble when using bump maps, as bump density doesn’t increase or get sharp in the scrambled areas. Finally updated it to use built-in nodes only instead of custom nodegroups:
