In order to make this a proper shader I have to rework the spec to utilize PBR spec. Something is wrong with my node network right now I think, when I put it on a fancy model, strange square artifacts appear when I turn up the anisotropic bias/angle. It doesn't show up when I use a surface model SOP rather than build my own.

Above Renders:

• Complex model with default pbrspecular settings
• Complex model with an Anisotropic Bias of 0.4
• Polygon soup teapot to get irregular polygons with default pbrspecular settings
• Polygon soup teapot with Anisotropic Bias of 0.4
• Default teapot with default pbrspecular settings
• Default teapot with Anisotropic Bias of 0.4

I've recalculated the normals for the complex model but that doesn't seem to be doing anything.

So on the left is a surface model plugged in for the specular and on the right is my shader how I've built it. Apparently I've got the basic setup correct because it finally gave basically the same results as the surface model because both shaders show artifacting! Which means it is the model and not me. I still have to finagle the pbr spec to perfectly match the surface model though which will be a bit more dissecting but at least it's beginning to be accurate.

So we're getting somewhere! The spec is working now so I decided to start adding the patterns on and see if the spec holds up. For the most part it does, it works on the object reflections but seemingly not on the light reflections. It still looks a bit glossy on the rust, though it is cutting down a bit.

Today will be spent making high res renders of what the shader can do. I will be going through all the options, making sure they all still work, and setting up default options if necessary.

Problems:

• This shader is so big, it takes forever to render just a straight color. It must be calculating everything at the same time and I don't know how to turn that off.
• Difficulty with making checkboxes animate when not direct parameters

Solutions:

• I think rendering was taking an hour+ not only because the maximum rays were too high but the samples on the occlusion layer were exorbitant as well. Reducing samples to 16 produces only slight graniness and is not really visible unless you are all the way zoomed in. Below are tests done with default render settings and 1.5 shading quality. The rest of the layers render in no time at all.
  

I want to be able to combine the lower two options of concentric circles and the striations to make more of a traditional Damascus pattern. So far, layering has happened rather than forming the stripes around the circles. Time to play with math (using different methods of combining the noise functions) to see if that will fix all my problems.

Success!! Now to figure out which parameters to promote and where to clamp the values. This happened by piping in a ripple sop in between the multiplication of the UVs and the rotated matrix so that there was already that rippled effect before the striations from the noise happened.

I think this looks much more like real Damascus than the previous renders. It also kinda looks like wood, but there is a node for that so I do not think I will use this as a base for making a wood texture, but rather I will use that node.

I've been using callback scripts heavily to change settings within the shader so that the user won't have to. For some reason I always forget to switch the language to python from hscript! That is the first thing I check when my scripts do nothing.

In pseudo code:
If the parameter on this node is equal to one, run the "makePainty" function attached to this node and pass the token "moss".

These are renders of water stains affecting the tile edges. I would like to have them not be so splotchy but when that happens, they are extremely blocky instead with harsh edges rather than a nice falloff. I'm debating trying to finagle it so the image renders how I sort of want it to, or trying to use COPs to change the image, it would have to render along the UVs.

I'm trying to make point based occlusion by passing in occlusion to the point cloud as a variable and then filtering it out to use later. The point cloud gets created but when I use the VEX notation of
$success = pcwrite($file, "occ", $occlusion, "P", P, "N: Vector", N);
The point cloud gets twisted and inverted and lovely like the image to the left. This happens even when the code is simple like:
$success = pcwrite($file, "P", P, "N: Vector", N);
as it is in the actual pcwrite node. I found a pcwrite node that someone else made here, but the code is the same, just containing five elements. I may end up just using that until I can figure out why mine doesn't work.

Apparently the points need to be forced into world space. I must not've had the nodes hooked up correctly but the code

works just fine.

The left hand image is the full render using the right hand image as a spec map. It seems to me that the water drips should have more shine to them. I think they do not because the wall is a flat surface. I could add bump or displacement based on the drips to force them to catch the light. I suppose if they were real stains on the wall and not running water they would have the same or slightly less specularity than the wall.

I've successfully figured out how to edit the otl with python to interactively make nodes when the user wants them as well as updating the UI to reflect the changes within the nodes. Now I'm working on how to make the actual texture look like something. I've done the height map as a displacement map here in the picture but unfortunately it does not capture the information to create a full hovering sphere. This could be bypassed by just not making any holes or we could have  fun and try to project an opacity map from one camera and the displacement from another and see if that will work. Alternatively I could export a point cloud but I'm not sure how that would work, nor do I think it would be particularly efficient for rendering.

The way to apply different images is in fact using UV layers. Imagine that, using layers is a way to layer textures on top of each other. Now I need to figure out the order of how the ROP is accessing the shader. It seems to be displacement, color, opacity. I would like to add opacity onto an object that is already displaced, thereby creating a floating sphere, or at least the illusion of one. I don't think the rounded underside would matter much on a sprite, but the holes letting the light through would be. Possibly I could UV the already displaced object.

After many shenanigans I've found a way to subvert the UVs on the grid. There must be an easier way to do this. My way is to displace along the normals, as you would normally do, then grab the rest position from there and pipe that into a UV project node and translate the position of these new UVs through a UV position node, then going along with the normal texture node going into the surface output. This way is extremely clunky because I could not find a mathematically relevant way to scale and offset the new UVs. I arbitrarily changed them to suit my needs.

The end result is not that satisfying either. The shadow doesn't change unless the opacity takes off half the object, plus I did not get the sweeping bottom curvature of the sphere that I took my projected alpha from.