Forum: Poser - OFFICIAL


Subject: Silly question about DisplacementMaps

pizzone opened this issue on Jan 13, 2010 · 13 posts


bagginsbill posted Wed, 13 January 2010 at 11:55 AM

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


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)