1 * 1 = 1... right?  And 0 * 1 = 0... innit?

Well, apparently not. The transparency channels on the PoserSurface have no regard for Proper 'Rithmetic.

If I turn the Transparency value to 1, the surface is transparent. Exactly what I would expect.

But if I now plug in a black and white transparency map, the BLACK (value zero) areas of the map are set to transparency = 1 (transparent), and the WHITE (value = 1) areas of the map are set to transparency = 0 (opaque).

So now, at my age, I have to learn some new arithmetic:-  1 * 1 = 0.  And 0 * 1 = 1.

I'm sure everybody realised this long ago except me. Is there anyone else whose sense of decency is offended by this really bad behaviour?

Izi

PS: Taking tongue out of cheek, I suppose the transparency map is inverted (1 - t) before being multiplied by the transparency value.  They might have told me that.  :O)

I think that BB has said that Poser's implimentation of transparency is, well, funky. I know the word 'funky' is not a word he would use, but you catch my drift? Maybe BB will come by and explain it in more technical terms. You can in Bryce use transparency with a water plane and it works fine, but in Poser transparency doesn't 'play well' with reflect and refract nodes.

You figured it out, and it is 'funky'. Occasionally you run into parameters that do not follow the general rule. The general rule is the effective value is (the node plugged in) * (the value typed into the parameter) and the node plugged in is assumed to be 1 when nothing is plugged in.

As you've found, transparency is an exception.

The effective value is indeed (1 - map) * (value typed in). I am highly offended by this. ;-) I do not like pointless exceptions.

I had to deal with this in matmatic. Matmatic provides a function call mix that can take two poser surface nodes and a mask and blend them. It does this by blending all the inputs to the surfaces. However, I have to do complement arithmetic on the transparency data in order to mix the two surfaces correctly. This was a special case that broke the beautifully elegant symmetry of the algorithm I devised for mixing surfaces.

FYI here are some other wierd exceptions.

Most of the x, y, or z scale parameters such as those found on Fractal_Sum do not follow the general rule.

For them, the (node plugged in) value is not assumed to be 1 if nothing is plugged in. Instead it assumes the corresponding model-space coordinate component. Further, the (value typed in) is not multiplied, but divided! By plugging in nodes, I can change those to use other coordinate systems, such as global coordinates (using P nodes) or UV coordinates. But I have to remember that U * k is different when k is a variable than if k is a constant. When k is a constant, typed into the parameter, I have to use 1 / k instead. That is a strange one.

Thanks bb. I suppose they did it like this so that our transparency maps could use the same convention as layer masks in our image editing apps, without having to use an extra node.

Now I can begin to predict what some of those xyz values will actually do, instead of relying on the 'spin and see' approach.

By the way, the word 'weird' is also an exception, at least on this side of the pond.  :O)

LOL. hoo sed i canz spel?