You will probably use only a single shader for both materials. You can do it with two shaders but then it would become a compositing exercise (blending your images based on a mask).

Within a single shader you can mix two inputs using multiple nodes, the end result is usually the same. For the mix bias you can load in your attribute with the parameter node. This might still look a bit blurry because it is dependent on the base geometry resolution. I would suggest using point clouds to look up the mask attribute which creates a nice sharp and more natural transition since it does a weighted average.

You can take a look at the documentation on this topic here: http://www.sidefx.com/docs/houdini14.0/dopparticles/vexpressions [sidefx.com]

It states: “This is the same VEX expression syntax used in “wrangler” nodes such as the Point Wrangle SOP. However, whereas wranglers affect geometry by directly setting attribute values, particle nodes cannot change attribute values (usually below). Instead, they work by reading parameter and attribute values and then modifying the parameters values accordingly. This lets you change the values of the node's parameters for each particle.”

In your case you can set the forcescale to 1 in the parameter menu and use your old code but just use multiplication instead of directly setting the value:

float lenP = length(@P);

if (lenP > 1.2) {
forcescale *= 5;
}
if (lenP < 0.9) {
forcescale *= -5;
}

I also have the macpro 6core with 2xD700 but with bootcamp to run Windows because I'm stubborn Houdini generally runs fine although there are a few GPU bugs because the bootcamp drivers are apple's responsibility instead of AMD's (As far as I understand).

VEXpressions inside the dop network can't SET values.
forcescale =-5; SETS the value to -5 so it doesn't work.
You can however MODIFY the value. The base value is defined by the parameter in the node. Then you can do:
forcescale -= 5; which subtracts 5 from the base value.

I believe this is impossible because the geo you want to reference isn't written to the IFD which means the shader can't access it.

There was a topic on this a while ago and even the author of that video was asking questions there. It turns out that since H12 you can no longer reference to a channel that is using a local variable in it ($CEX,$CEY, etc..). A method to solve this is to use expressions instead of local variables so that when another node references it, it runs the expression again which evaluates fine. In the case of the centroid you can use centroid(“../path”,D_X) instead of $CEX. Documentation on this expression is here: http://www.sidefx.com/docs/houdini14.0/expressions/centroid [sidefx.com]

Keep primitives also keeps the in-between segments which could cause bad geometry if you fuse it for some reason later. I think it's safer to just use the polycap.

The sweep approach is by far the best way to go since you can edit the curves and still get a nice arch. The problem with the bottoms not lying flat on the ground plane has to do with the orientation of the segments that are being swept over the curve. With the sweep sop you need to provide a backbone that it can aim towards. In this case you need an inset version of your curve. To do this though you need to create a proper vector along which you can offset the curve. Using the polyframe sop gets you far but it's still not perfect.
In this example I used a wrangle to straighten out the normals of the first and last point so that any crossproduct will always be perpendicular to your groundplane. With the sweep sop you also don't need a skin or polycap node, the sweep can do this by itself. (2nd tab called output does this)

Another option that you didn't mention is to use the copy sop. With the copy sop you have to provide your points with orientation attributes instead of a reference curve. You need to first resample your nurbs curve to polygons or the shape won't match the sweep equivalent. Here you do need a skin and polycap node. You don't need to give the polycap node any points/edges in the group field, it can find these by itself with the default “cap all unshared edges if no group” turned on.

There is an image plane preset called “Ray-level” which gives you information about the level of noise in the image. From what I can gather pure white values in this plane mean the renderer hasn't completely satisfied the noise threshold and could use more samples.

Over sampling should be automatically prevented with the ray variance antialiasing. You can set your max rays to something very high but the renderer won't actually use them if it's not necessary.

The brightness and offset in step 2 are just for preview purposes in mplay. You need to recreate those steps in your software to get the same result. Also, does .png even go to 32 bit? You can maybe do the brightness adjustment in houdini and then output the result as .png. Be sure to make actual adjustments to the image and not to the image preview.

Using f@speed * f@timeinc = distance gives you the distance traveled over a single frame, your f@timeinc increment.
If you want the total distance you need to use your total timespan*speed.
If your velocity changes in between frames you could still use f@speed * f@timeinc = distance and keep adding that value to a total distance value.

The expression is called point(), not points() and you forgot to put ,0 (The attribute index, for a single float always 0) after your attribute name.
It should be: point(“/obj/GEO/attribfrommap1”, $PT, “greyscaleColor”,0)*180

You can go into your license administrator, select your licenses and go file>return selected licenses. This frees them up to use on a different machine. Be careful though because you can only do this a limited amount of times. I believe two or three times max.

It seems that field doesn't accept point attribute variables. When you enter $ to get a preview list of the valid variables it only lists global ones such as $F, $T etc.

This seems pretty logical since the mountain SOP runs over the entire geometry and not over each point separately like a wrangle or attribVOP.

If your intersecting geometry has a very basic shape you could create a curve with the outline of your geometry and project it on the other piece of geometry.

This solution is based on wrangles but it deals with the same problem (Add point to group was available as a point wrangle function, it doesn't work in the attrib wrangle)
From the odforce forum:

Also (for anyone curious) you can create groups in Wrangles like this:
//Everything after group_ is the group name, and any point (or prim)
//greater than 0.5 adds that element to the group
@group_foo = 1;

http://forums.odforce.net/topic/21694-sidefx-releases-houdini-14/page-5#entry129427 [forums.odforce.net]

Personally I'd like to know what the new way is to create a local variable name for attributes that are created in the wrangle nodes. For point wrangles there was the addvariablename(“attrib”,“ATTRIB”) function but this doesn't seem to work inside attrib wrangles.

Merging different objects together to render them inside a single object node is often bad for performance and causes the problems you are mentioning.
When you merge objects with different attributes they are often not initialized properly and are therefore not rendered properly.

The best way to approach this is to separate your major elements in different OBJ nodes. You can use the “object merge” SOP to bring in geometry from other OBJ nodes so you can organize them a bit better.

You could dive inside the surface material and use a mix node to combine the point color and the color map and drive the bias with the alpha channel.

The equivalent of the position of the current point is “@P” or just “P”. This is a vector but you can access individual components with “.x .y .z”, so P.x / P.y /P.z.

Most noise functions take a vector as an input so you can define your space deformation beforehand and then plug the new vector in the noise function. Your current expression could look something like this in vex:

vector space = set(P.x*.2,P.y,P.z*.5);
vector space2 = set(P.x*.5,P.y,P.z*.2);
vector space3 = set(P.x*.3,P.y,P.z*noise(space2));
vector noise = hscript_noise(space) + hscript_turb(space3,5);

P+= noise;

I think the hscript_* versions could easily be changed for the vex versions, just look at the help files if the particular noise function you are trying requires more arguments and also in which range it outputs!

I'm not sure which is more efficient but if that is important you should look at getting rid of the cookie nodes unless you are going to use them to create more varied shapes then just L blocks.

Maybe it is intended but with your current expression you have a bias towards the first two possibilities.