Okay, I suppose it's a good candidate for the silliest question of the year, but how can I avoid my object's faces from "exploding" when I apply a displacement map? I've just started to experiment with displacement maps and so I took a very simple object, a cube, I mapped it (box mode) and then realized a very simple dis-map: it's all filled in mid grey (R=G=B=128) except for a round area filled with a radial gradient going from black to mid-grey. In my mind the rendered result should be a cube with a gradient hole in the corresponding face... That's what I got, but all the faces of the cube literally explode (click image above). I supposed (maybe I'm wrong) that the mid-grey would constitute a sort of baseline, with the displacement taking effect only in the areas with different shades of gray. Surely I'm getting something wrong. I'll appreciate very much anyone who'll care to help. Thanks,        Alberto

do a search for Displacement maps and BagginsBill
you'll find quite a bit on what you need to do already written up :)

In Poser, a zero value (black) represents zero displacement. (I believe that most other apps use mid-grey to represent zero displacement).

So your mid-grey background is creating positive displacement over the whole face.

Before plugging your displacement map into the displacement channel on the PoserSurface node, you have to subtract the exact background RGB value (128,128,128 in your case), using a Math node in the Advanced Material Room view.

Screenshot, in case you're unfamiliar with the Advanced Material Room. The seemingly weird value I have subtracted from the displacement map is 128 / 255.

Attached Link: http://www.drgeep.com/p5/mr/mr.htm

Here's a page from [**This Tutorial**](http://www.drgeep.com/p5/mr/mr.htm) that might help explain displacement.

cheers,
dr geep
;=]

erm Geep? you know thats poser only displacement. the Node inserted above in the example lets you use standard displacement where 128 gray is the zero point (instead of black being zero) and allows you far more control and the use of displacement maps made for other software?

IsaoShi has given the answer. But I'd like to point out some other stuff to think about.

If you're designing a displacement map, you can choose any value you want to mean "No Displacement", and subtract that value.

For example, you could make the entire map white (RGB 255,255,255) to start with, and then anything darker than that represent an inward displacement. You would then subtract 1 from this map, and everything less than 1 becomes a negative (inward) displacement.

Or, if you only are trying to get positive displacement, you could design your map so that the base value is black (RGB 0,0,0) and then you subtract 0, which, if you remember basic math, is completely unnecessary, as x - 0 = x anyway.

Of course, if you're designing a multi-app displacement map, where you plan to use it in Poser and other apps, and those other apps only have one option, where RGB 128 is no displacement, then you must use that strategy and do the subtract as IsaoShi has shown.

Now why is this important? Because the possibility exists to get more detailed displacements than you can get from Mid-Gray=0 alone.

Consider: When Mid-gray = 0, the maximum positive displacement is 255 - 128 = 127. The minimum positive displacement is 1/127. In other words, the dynamic range of your postive displacements is 127:1. You cannot make any delta that is smaller than 1/127. This effect is sometimes called "stair stepping" and is clearly visible in certain kinds of maps.

Similarly, the negative displacement happens in increments of 1/128 of the maximum negative displacement amount.

Here's the point: If you're only needing a positive displacement or a negative displacement, not both, then you are cutting your dynamic range in half, and you are therefore doubling the amount of stair stepping that will appear in the rendered object. Stair stepping is ugly, an artifact that you want to avoid. If you do not need both positive and negative displacements, you should be using the full dynamic range of 255:1, which can be accomplished by choosing white or black as your basis value.

Now, given that the displacement is controlled by an 8-bit grayscale value, it seems that the best dynamic range you can get (and therefore the smallest discrete step) is 255:1. But in a color image there are actually 24 bits, not just 8. It is possible (though perhaps difficult to construct) to use all 24 bits to encode a larger dynamic range. For example, you can get a dynamic range of 765:1 by using all three color channels. For displacements from 0 up to 1/3 of maximum, use red. For 1/3 to 2/3, use red=255 + blue=0-255. For 2/3 to 1, use red=255, blue=255, and green from 0 to 255. When you plug a color map in as displacement, Poser will automatically average the three values, thus giving you 1/3 the size of using 8-bits alone. But we can do better, with some more hackery. We actually have 24 bits, so the theoretical dynamic range of the map could be over 16 million to 1!! In practice, however, this is difficult, because we don't have any such 24-bit encodings supported by Poser. Trying to get it to do one using nodes is also a problem, because even though we can extract the R, G, and B  values and do anything we like with them, before we get them Poser will interpolate points between the pixels in the image. This throws off the numerical interpretations, resulting in discontinuities. However, I designed an encoding that is resilient to the errors produced by interpolation. I had to give up some resolution. But I was able to get 13 bits of resolution, giving a dynamic range of 8191:1.

The thread discussing all this in detail is here:

http://www.runtimedna.com/forum/showthread.php?t=26700

sigh and just when I thought I'd got the idea back to the beginning again... right so midgrey out the window sound of cat squealing and now it's put the zero point to where you need it at the time.

I think I'll give up for now..... it's getting me confused.

Wow, boys!!!!
I'm simply overwhelmed by the number, the speed and the quality of everyone's replies... Yeah, I have to say it again: I'm really speechless!!! Thanks a lot to everyone! Now I'll take my time to read thoroughly (and understand them...) every sigle reply, but the first glimpse is sufficient to make me sure you gave me all the informations I needed ( and even a lot more...). If I don't understand this time how displacement-maps really work ...it's mandatory I start looking for some brain-upgrade kit.
Thanks to everyone,
                                       Alberto

Ask a question that hasn't been asked a 1,000 times before and see what ya get :)

Bump and displacement are right up the list of common questions. It doesnt help that different applications deal with them a bit differently. I use lightwave and the bump maps are inverted. :(

Some of whats been discussed is how you can adjust the 0 point for maps, and get better control over the scale and direction of the displacements. You dont need to worry about that if you just want a single direction change.

BB... I don't know if it's something to to do with the RDNA site rebuild, but the final Matmatic script that you posted in that Node Cult thread (Post 60) appears to have been truncated, and try as I might I can't work out all the bits that are missing. I'm at home with a heavy cold this week, and that isn't helping me to think straight. Could you be a sweetie sometime and repost the whole script, for me and possibly others?
Thank you.

Oh dear. I was super genius when I wrote that, and I don't remember how it works. I don't have it anymore. I posted in the forum, under the mistaken assumption that I could use my Node Cult as a safe always-available repository. Guess not.

Perhaps somebody else has a copy.

Not to worry, I'll see if I can rediscover the lost treasure when I get my sense of direction back.

I popped over to RDNA to ask there, and I see that you already have... thanks!