All Poser node wires are carrying either just a single number or a bundle of 3 numbers (also called a tuple or a vector or a color or a position or ... depends on your intent of how you plan to use the 3 numbers).

A number inside the shader is always a floating point number, not an integer. It is not restricted to any given range like 0 to 255 or whatever. It can be -808.34873847 or 2 or 1.0000001 or 5.757457495 * 10 to the 30th power. (I honestly don't know the internal size of these numbers - they could be 32bits, 64 bits, or 80 bits, or something else. If we really cared, I bet I could come up with a test that would reveal how many bits are in them.)

A node is asked to produce an output of whatever kind is natural for it over and over again. How many times it is asked to evaluate a number or tuple depends on how many pixels you have in your picture, what the shading rate is, how many reflective or refractive surfaces there are, IDL passes, SSS passes, etc. But when designing a shader, you don't need to care about those things at all.

Whether a node produces a single number or a 3-tuple depends on that nodes job, and does not depend on what you plug into it, nor on why you're using it. Every node is either a scalar (single number) or a 3-tuple. Blender is a tuple. Math is a number. Clouds is a tuple (and usually interpreted as a color, but it could also be converted to a number and interpreted as a displacement to make a rocky terrain.)

The output of one is carried to the input of the next, until all the numbers flow into the root node. The output of the root node is a tuple, and it is used to color a pixel in your render. (If you are subsampling, then several root node results will be combined by weighted averaging to decide the color of a pixel.)

Inputs to nodes usually expect a number or 3-tuple as well and they have a parameter on them you can edit that gets multipled with whatever you plug in. If you plug a number into a number, or a tuple into a tuple, you probably can understand what happens without me telling you.

But if you plug a number into a tuple? Simple - the number is cloned into all three elements. So if you plug the number .5 into Diffuse_Color, that would get cloned and become the "color" tuple .5, .5, .5.

If you plug a color into a number? Simple - the three parts of the tuple are averaged. So if you plug the tuple 1, 1, 0 (yellow) into a number, it becomes (1 + 1 + 0) / 3 = 2/3 or .666666667.

This means that you can freely plug colors into numbers and number into colors. It does not mean that always makes sense. But I can show you so many situations where it does make sense that you'll quickly come to realize how convenient it is that Poser doesn't make us run the data through some stupid converter node like so many other renderers do. It just quietly takes care of the conversion.

If you do not like the conversion from tuple to number, you can write your own wherever you need to. The Component node will pull out any combination of the 3 elements of a tuple and assemble them by weighted sum, or just give you one of the raw numbers which you can then use to do numeric stuff. I use this tactic in skin shaders to pull the red channel value out of the texture and detect hair versus skin.

Numbers and tuples coming out of a node are decided by that node based on its inputs and based on information passed to it from the renderer - the latter are render variables and they change on each iteration of the shader. Much of the information variables passed from the renderer includes stuff we do not have direct access to in the materials - only programmers who make new nodes can reach that info. Some of the information the renderer passes is directly accessible to us as material room shader developers - these are the "variable" nodes such as U_texture_coordinate, V_texture_coordinate, N(ormal), P(oint), etc.

As shader developers, we're only able to perform operations that are offered to us as a node. We can compose and assemble these as we like, but we can't directly reach every feature of the renderer. For example, I can't tell what kind of light is being applied during a render - I can only indirectly sense lights by using lighting nodes such as Scatter, Hair, Diffuse, Clay, Blinn, etc. I am bound by what those nodes do. If I want to do something altogether different that cannot be done by composing existing nodes, I'm stuck.

Many of the nodes have nothing to do with lighting nor with variables. They are simply pattern generators that shader authors find convenient for mimicking natural things. Among these are Clouds, Fractal_Sum, etc.

Other nodes are pure math - they don't have anything to do with generating anything at all or reacting to lights or whatever. They just do simple arithmetic with the inputs and compute an output that, like all nodes, is simply a number or a tuple. How you use them depends on what you're trying to do. For example, if I am making a pattern out of a couple other pattern nodes and I'm blending those, I use a Blender node, and so that node's job is to make a pattern. If I'm combining a Diffuse and a Reflect to create a custom modulated material that has some pixels that are clay and others that are metal, then I also use a Blender, but now its job is a new kind of lighting model, not a pattern generator.

That's enough for now - chew on that for a while.

---

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)