The next fun feature is going to be water stains. They are driven by gravity so they will be primarily based on a user input ramp whose position is from the Y axis. The interesting part will be getting the "seepage" part right, possibly only making that feature available when tiles are selected.
The color of the stains looks to be a derivation of the original wall color, with the edges being slightly different than the center of the stain. Fresh stains are darker towards the center whereas old stains have lifted the color from the center of the stain and the center is less saturated.

The water stain is based mainly on the Y-axis, the user can change the ramp to control where it goes, as well as paint an attribute on the wall to control where it actually goes.
The shape of the drips are controlled by a noise stretched in the Y direction. Roughness controls the amount and frequency of the smaller drips.
The color is based on the original diffuse of the wall, with changes in the hue, saturation, and value. The user also has the ability to make the center or edges of the stain a different HSV value. This is based on the original intensity of the noise because the center of a noise patch is generally higher in value than the edges.
Now I need to python script the ability to paint attributes so the user doesn't have to set/mess that up, also I need to implement the water stains within the cracks. I think the color attribute from the original water stain will be suitable to control that.

Tile stains have been added! This feature is only available when tiles and water stains are selected. There are two noise functions driving the variation on the tile stains, one large frequency to give broad patterns and a smaller one to break it up and look a bit mouldy.

Next pattern: Bricks. This reference image showcases the displacement of individual bricks, the wearing of the color on the edges of bricks, the change of spec within the grout, and two different colors of brick rows.

To create the individual brick, the user inputs a color or texture map and a grout color. This is fed into a COPs network and rendered to the tmp drive. The file, with alpha to delineate where the "grout" is, is read into the shader, then repeated and offset on the object's UV set. The user also has the ability to change each tile's edge saturation and value, add noise to make little bumps to add air pockets to the bricks, and create wacky edges.

Next I want to be able to change the color of each tile based on a ramp to have the stripes as in the above picture so that the user does not have to apply multiple shaders to one object.

Now there is the ability for super creepy hallways! I will probably make a basic scene like the above hallway to demonstrate the versatility of the shader to go between a clean hallway and a dirty one. Below are renders of the start of a hallway, the user manipulates a ramp mask to tell where the hue, saturation and value shifts should be. With the way I am implementing the color for the tiles, it would be very difficult to make the shader use color mixes rather than a hue shift. This way, only one file is created and that files' aged look, if desired, is preserved. It's just a little more finicky for the user this way.

Now it's time to start making patterns. I've decided to start with a rusted metal type pattern. It has rust and displacement that "corrodes" the metal and tries to layer it underneath the paint. My reference image also has cracks where the paint is trying to flake off and expose the rusty metal underneath, so that and a corresponding displacement is included as well. In order to make the base color look aged, a noisey color correction has been added where the user can alter the hue, saturation, and value of the image or color they input. I have been working solely on the diffuse and displacement changes however and need to make sure that I can transfer these changes over to the spec map.

Specular changes have been successfully added! I am curious if the UI is usable to others though. I've put a specular tab that holds the changes for multiplying the various patterns into the spec map, but I wonder if they should go with the master controls for the patterns.

I think I've finally figured a work around for the occlusion based rust. The color part works fine, it only gets dodgy when I try to implement displacement based off of anything to do with occlusion. Possibly because occlusion takes displacement into account and I'm not quite sure how to bypass that.
My workaround now is to render out a specific occlusion vex variable with a specific mantra. This particular mantra is then wired in to the main mantra node so that it renders before the main one renders so that the file is there. The outputted file is stored on the tmp drive.

I was previously trying to focus on the displacement within the shader and what I really needed to be focusing on was the big picture of what the shader will be used for. It needs to export maps. Maybe I can put some code in to satisfy myself to alter the mantra node if certain maps are not necessary to be outputted.

In any case, the shader now has the ability to output: diffuse, spec, ambient occlusion, height (not pz), and tangent space normals. I am now working on patterns that will effect the diffuse and spec like dust and dirt. To the bat cave!

What the scene is meant to look like: an oblong sphere hovering over a grid.
I've been fooling around with applying displacements from different angles, thinking that I could simulate the spherical nature of the ball.

Just one displacement, there is some "folding" of the geometry that I'm trying to get rid of though it may be severe displacement on simple geometry that's causing it.

Houston we have liftoff!! So no there is some more shape to the displacement other than just up. There is some severe folding within the geometry now. This was done just by applying the same displacement again, piping in the new position and normal vectors from the first displacement into the second one. The displacement maps are still a top down view, using uvs projected from the top.

I broke it a little bit. This is still two displacements but now it's using UV's projected from the side as well as a new height map taken from the side. In the original projection environment, a box had to be added around the scene so that the depth pass had ending values.
The main problem with this technique I think is the folding in the geometry. I'm going to look into render settings and geometry subdivisions to see if this can be taken care of.

Occlusion has been scripted into the otl! It must be added after diffuse, has a catch to make sure diffuse has been created. The user has the option to color the occluded bit, control the spread (through the bias on the occlusion node) and the overall brightness (takes the luminance of the fit node and pipes it through a fit node where the user controls the destination maximum). These parameters are added into a folder inside the diffuse folder which is created after pressing the "Create Diffuse" button.

The rust on a car seems to "grow" from the top down and in cracks where pieces join, then randomly all over the surface. These three types of rust are fairly simple to obtain, from Y point position, an occlusion pass and simple noise multiplied onto another noise of lower frequency for more random variety.

The first images is that of just randomly placed rust, the second is of occlusion based rust, the third of rust placed based on the Y position and then multiplied by noise and the last is all three together. I also added displacement according to where the noise fell, albeit way too much. The occlusion presented a huge problem for this. I  could not directly hook in the noise that was outputted by the occlusion multiplied by a turbulent noise because this resulted in a segmentation fault, aka Mantra Exit Command 11, aka Exit Command of Doom. I had reinstalled Houdini, deleted preferences, tried a new mantra node, and kicked all the stats down to the bare minimum to try and expedite the render. It must be something with the way the occlusion node is talking to the displacement. Eventually I just rendered an occlusion image and used that as a texture to multiply the noise by, thereby giving the above render. Frankly there is so little displacement on that particular type of rust in the reference photo that this may have all been futile.

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.

As I understand it, this is going to be a shader that can output diffuse, height, normal, ambient occlusion and hopefully a rust pass. There will be noise implemented to simulate dirt and scuff marks. The drips will probably have to be some sort of fluid sim that changes the point information on the model to output a kind of mask. This shader will be encompassed as an otl.

But wait. That would make an extremely heavy otl wouldn't it? So as I figure out what nodes and settings to use in the shader, I will be creating python script that will go with the otl to create the nodes when the user pushes a button. Do they want a displacement pass? Check a box and the script should create/modify the rop to output a file, as well as add some sort of displace along normals node, a texture map and a noise for the user to play with.

To start off with this first week, I will make a simple shader that has a color on it that is added to  a simple scene. From this scene I will output a color map, just the straight color meaning that the color needs to be emitted out, and a height map for displacement. After I figure that out, I will put that into an otl and make sure that transferring the shaders from one scene to another with the otl works, then I will implement the shaders in python. Hooray for python!!!

The left image is the original scene, the right is a grid with displacement and color mapped onto it. The displacement map was generated by a depth pass. Once this map was piped in, the ty from the original render cam that is gathering all the information was subtracted from the image and then the image was inverted.

I don't understand where the "wall" is coming from. There are errant pixels somewhere in the render.

I ended up scaling the uvs up 0.02 and translating them -0.01 to get rid of those pixels. I don't think that this is the ideal way to do things but it works and the triangle does not move.