I was testing the ZBuffer function for a client who wants to use it for laser engraving and I was curious as to it’s accuracy. I found it to be surprisingly accurate, with one small exception – see below.
To test, I created a series of 625 boxes with random integer heights from 1 unit (mm) to 255 units. I then deleted one box to have a “control” 0 level. There are texts in the file which indicate the height of each box. Using the top view, I saved a named view (“Calibrated”) with which to do all the tests. On a separate layer, I put a plane on Z0 that is larger than the Top view extents.
With the plane layer on, I then ran the command ZBuffer and used ViewCaptureToFile to make a PNG (no transparent background). I opened that in Photoshop and checked the pixel values. I found that the 255 height box had a gray value of only 254. The 0 area (no box) was indeed 0 gray value (i.e. full black), but the 1 height box was also 0 gray value. Every other box had its height minus one as a gray value. I can easily remap the 0-254 range to 1-255 using Levels in Photoshop, but that last 1 unit height is “lost in the darkness” forever…
Then I ran the same test without the plane layer on. That produced more interesting results. The 255 height box was still 254 gray, the 0 height area was still 0 gray - but, the 1 height box now jumped to gray value 13, the 2 height box to 14 etc. The progression looks like this:
5 = 16 (+11)
10 = 21 (+11)
20 = 31 (+11)
30 = 40 (+10)
180 = 183 (+3)
220 = 221 (+1)
240 = 240 (+0)
255 = 254 (-1)
So the whole scale is compressed and there is that jump at the bottom from 0 to 13… I thought that this was interesting enough to be worth reporting, or at least to have an explanation… @jeff
Files (I zipped everything because the the files are quite large, even the .png’s):