Actually the problem there is with the quality of the preview of Math_Node_9 (divide) and Math_Node_4 (sine) rather than with the output. A fundemental problem with the math nodes is how to represent arbitrary numerical output as colour intensity, and in the PixelsDigital/Poser material system, they seem to have gone for simply representing values of 0.0 or negative as black (greyscale = 0) and values of +1.0 or greater as white (greyscale = 255), with the intermediate numerical values translating to linear steps between 1 and 254. This is in fact the internal way that colour values are represented in most graphics programs nowerdays. Unfortunately maths functions are by no means constrained by these values (0.0 to +1.0) and therefore there's always the potential that the preview output will not represent a lot of detail from the function. Hence, a pure sinusoidal function which outputs values between -1.0 and +1.0 previews black in all the regions where the function outputs negative values. Furthermore as the gradient of the function output is greatest as it passes zero, there is a very fast (narrow) transition band of intermediate grey values to the high intensity (near white) colours. This is why in your material setup the sinusoid function previews as apparently strong bright bands, rather than a smooth transitional curve even though it does generate a smooth (and discontinuous) displacement when plugged into the shader. The displacement is a signed function so it uses negative values even when the display preview of the maths nodes always represent these as black. In the above setup, running a colour picker over the preview window for node 4 does confirm that much of the preview output for that node is zero (pure black) and while there is a transition from black to high brightness at the band edges, this is extremely sharp because its at those points where the sinusoid output crosses the zero value that the function gradient is at its maximum. Node 12 scales and biases the divide/sinusoidal ouput so that it has positive values and although I've saturated it by adding a bias of 0.8 for visibility rather than 0.5 it does demonstrate that the maths functions are generating values that are not visible in their own preview windows. More specifically, the "tip" is actually visibly present in this node's preview. Because the tip actually has a negative value (even though its sticking up in the displacement) at the output from the divide node (9), it's colour is black and its not visible in that node's preview. Moreover its important to realise that, when it comes to the visibility of features in displacement and bump mapping, its not the actual height of the displacement that matters, rather its the gradient and change of gradient at the discontinuity. Therefore the worst case actually occurs if the discontinuity from a sine function has a displacement value of zero as this is the point at which the gradient of the function, and hence the sharpness of the "tip" is at the maximum. Bill