Forum: Poser - OFFICIAL


Subject: Zbrush4r2b displacement in poser pro 2012.. tips?

Gareee opened this issue on Feb 11, 2012 · 48 posts


millighost posted Mon, 13 February 2012 at 6:50 PM

Quote - You've obfuscated nicely!

The single pixel case only demonstrates that you need one extra pixel in each dimension, not twice as many.

Well, you got that one, i thought i could get away with it :-) Complicated explanation below.

Quote - If you have a 100 by 100 normal map, exactly the same information is found in a 101 by 101 bump or displacement map.

By analogy, I can describe a bank account as a series of balances, or as a series of transactions (deltas). Given one I can produce the other. The amount of data is the same.

Consider this bank account.

Initial balance 0

File 1: Subsequence balances - 10, 30, 50, 45, 70

File 2: Transactions - 10, 20, 20, -5, 25

 

Is there any difference in the information? How about the information density? No to both.

Actually yes for the information density. As soon as i know that your balance is 0, i know that your next transaction will be positive. You have only half the choices you normally have. If i would have no idea what your account was, the transaction sequence would carry more information. But this is not the main reason for much larger bump maps, but it is (among others) a reason for a larger sample size.

Quote - But if you ask me to list the transactions, File 2 has them directly, while in File 1 I need a pair of balances to calculate a transaction - information that is directly stored in File 2, but readily reproduced from the data in File 1. There is a difference in efficiency, but not density.

The same is roughly true of normal versus bump map. The bump is in File 1 format - actual balances. The normal is (sort of) in File 2 format - deltas (or slopes).

It would be true, if the maps were 1-dimensional. But they are 2-dimensional, so each value is not only bounded by its left and right, but also from its top and bottom. Imagine your bank account example, but with the additional restriction, that after the second transaction it must have the value 50. You would have no choice of what that transaction could be. If you picture a pixel line in a bumpmap as a sequence of account balances, you could choose freely what each transaction should be and assign the appropriate balance to the pixel. But now you want not only the lines to be account balances, but also the vertical columns to be account balances with the same pixels values. That would not be possible, because the values are already fixed because of the rows.

Another picture: Imagine a little ant running in circles on hilly landscape represented by a height map (bump/displacement map). The ant starts running, climbs hills and visits valleys, but whenever it returns to its starting point it will have moved the exact same amount up as it has moved down. With a normal map on the other hand, the ant could have climbed up all the time and still return to its starting point (almost like Escher's ants). This possibility is essentially what lets normal maps contain more information than bumpmaps.

From an information density standpoint, it would not be necessary to double the resolution in each direction, of course, it would suffice that the amount of pixels would be increased by a factor of 1.4 (sqrt (2)), because the normal map contains more or less twice the data, but that is rather an encoding problem, as you mentioned.