Curious - what were the shortcomings?

I like fBm, and I especially like Fractal_Sum (that's my 99% goto node).

However, in this shader I want the user to be able to adjust the scale of both noise effects using a single dial. That means I have to plug a node into both scale inputs, so the user edits that one number. This works fine with Clouds.

With the other types of noise nodes, where there are independent X, Y, and Z scale parameters, you would think you could do the same. But, alas, Poser behaves differently for those nodes. I don't know why.

Here's what it does. Each of those parameters defines the rate at which the pattern evolves in that direction. For example if X_Scale is 1 versus .5, the pattern evolves across the model coordinates space twice as rapidly with the .5 as with the 1. Basically, the input to the noise pattern lookup is X / X_Scale.

However, as soon as you plug any sort of node into one of those scale inputs, the internal use of the model X coordinate is dropped. Instead, the value plugged in is used, then DIVIDED by the scale parameter numeric value. This is totally different than other node parameters.

For almost any node numeric parameter, there is a number and a socket. In general, the value produced by the socket is 1 if nothing is plugged in. The input parameter value (pv) is multiplied with the socket value (sv) so that the effective value is pv * sv. Whatever the underlying function is (f), then the effect produced is f(pv * sv). With me so far?

But with the 3-d noise nodes, it is f(1/pv) if nothing is plugged in, and it is sv/pv (no f used) if something is plugged in.

I don't know if this is making sense to you all, but it's very important. The bottom line is that you cannot get the functions to continue to work if you plug in any node at all.

Knowing this is how they work, I have actually taken advantage of this at times. Consider the fBm node. It evolves the pattern according to fBm(mx/X_Scale, my/Y_Scale, mz/Z_Scale), where mx, my, mz represent model coordinates of the point being rendered. (Model coordinates are those coordinates of the original imported model, not the world coordinates of the prop after it is translated, rotated, and scaled.) Well, what if I want the pattern to evolve according to U and V coordinates, not model coordinates? Simple - I plug in U and V into X_Scale and Y_Scale, and I plug a 0 or some other constant into Z_Scale. This let's me define noise patterns in 2-D UV space instead of 3-D model space. 

If I were designing the nodes, I would not have done this. I would have provided 2-D and 3-D versions of all the noise nodes, not 3-D versions that change their internal logic when you plug in a node.

---

Renderosity forum reply notifications are wonky. If I read a follow-up in a thread, but I don't myself reply, then notifications no longer happen AT ALL on that thread. So if I seem to be ignoring a question, that's why. (Updated September 23, 2019)