ShowZBuffer resolution

If I understand correctly, ShowZBuffer has an 8-bit range between the near and far points of view.
This means I can get 256 steps.
For screen display only, this may be sufficient.

However, it is not enough when I want to do more with the depth information.
When I use such an image for a height field, the steps are clearly visible, especially in flat areas.
For example, consider an engraving on a coin.

I can’t completely eliminate these steps with image manipulation.

I also tried the ZBuffer in Rhino Renderer.
Same depth resolution.

Questions:

  • Are there any built-in means of achieving a finer ZBuffer resolution?
  • If not, can the ZBuffer output be modified to achieve 16-bit resolution, for example?

You need to use Render and save as an EXR. A concern is that many apps will not read the EXR that Rhino saves. I have been informed by @nathanletwory that this is not a Rhino issue. The EXR opens in GIMP and Blender, and then you can resave as another format that suports 16 bit greyscale. However, it is inconvenient.

You can read the thread here:

Having read through that post, I was finally able to export to TIFF.
When used for heightfields, however, I don’t see an improvement in the Z resolution.

Unfortunately you cannot use TIFF from Rhino, if that is what you mean.

The only option to get higher bit depth out of Rhino is EXR.

EXR is 32 bit so you may have to convert it to 16 bit greyscale first before exporting to whatever app you are using to import the 16 bit greyscale image.

Yes, I exported as *.EXR.

In Photoshop I made it 16 bit.
The HDR Toning dialog comes up automatically.
I selected Equalize Histogram.
Then I have visible color banding on my screen.

The color banding becomes worse when I set the image to greyscale.
Then I exported as TIFF 16 bit and used that for the Heightfield.
The result is far from smooth.

I have tried Photoshop with EXR, you cannot use it for this purpose, because of the poor results as I mention in the thread.

Nathan suggest GIMP or Blender. The other programs I have tried that import EXR do not work.

Tried with it now as well - cumbersome when one is used to Photoshop.
Doesn’t matter when a good result is the goal.

Unfortunately the resulting 16 bit TIFFs don’t work well for Heightfield.

Perhaps @nathanletwory has a good idea for getting a nice and fine greyscale image?
2025-10-20_Lily.3dm (435.2 KB)

Hi Charles,

the view based zBuffer does not use near and far point for range of the grey scale. Maybe it uses the frustum (range between near and far clipping plane)?
The distance channel in render worked for me.

You may try OpenEXR · PyPI to read the depth.

Jess

I have not tried the Blender process yet, perhaps that would produce a better result.

Not sure what to look at, but I exported the EXR as 16-bit floats TIFF

then used that as input to _HeightField, looks pretty smooth to me

Remember that the result will depend on the input values given in the sampling dialog.

That’s good.
I don’t get such a nice result.

I think it’s because of my image manipulation.
When I load the EXR in GIMP, I have to adjust the levels.
I must be doing something stupid, I get a a few greyscale steps only.

No wonder HeightField makes steps.

Here’s what I do:

What do I do wrong?
test.exr (201.5 KB)

Your Adjust Levels looks a bit different from mine, I think mine looks a bit smoother.

But your biggest problem is that you’re using the resolution of your image for the sampling, too high. This will not give good interpolation. For this heightfield I’d probably use something like 200x300 for the sampling:

See how high sample counts will result in stepped meshes.

After Render I have this, it looks quite smooth:

Save as EXR from the Render dialog gives me something very different.
My EXR is not smooth.
Regardless in which image processor I try, it always ends up in stairs.
Can it be that the Mac version produces a different EXR output?
I’m on Windows (8.25.25287.14001, 2025-10-14).

Understood now.
I wanted to make it extra good and earned the opposite.
Thanks for the enlightening video!

I have just now tested on Windows as well, I get still nice smooth result.

Also, I think it is better if you just used the resulting EXR directly in the displacement modifier on a simple plane. I get very good results with that:

Since the EXR records the distance from the camera you ‘just’ need to find the lowest and highest value and put them in the modifier - the higher value for black and the lower value for white. You can see how smooth the resulting mesh is in the screenshot.

To get that mesh out you can then just _ExtractRenderMesh

The EXR I rendered out on my Windows machine is: 2025-10-20_Lily.exr (869.0 KB)

I have written a simple Python 3 script for use with Rhino 8 (and probably later, for as long as Python 3 is supported):

convert_distance_to_displacement.py (1.9 KB)

Open the script in _ScriptEditor, and run. It will pop up a file selection dialog. Select one (or more) EXR file(s). The assumption is that you select EXR files that are written by Rhino from the Render Window with the distance data in. If you have a file called mydistance.exr the script will write a converted file as mydistance_hf.exr. Now you can use this as the displacement texture using the displacement mesh modifier on a simple plane. You can keep the black and white points at 0.0 and 1.0 respectively.

Wow @nathanletwory !

I followed all the steps you listed.
The converted file is not as expected.
Here’s what I do:


Displacement of course can’t work with this (I tried).

This is a reduced version of the model I played with:
KillNefertiti_Small.3dm (1.6 MB)
And yes, I tested with this, same effects.

You found a bug. I have fixed that with this updated version: convert_distance_to_displacement.py (2.3 KB)

Fantastic!
Works exactly as expected.
Many thanks.

Too bad the displacement takes so long - but I’m patient as always.

May I ask why the EXR distance output from the Render window is in that strange range?
I’d expect something visible from the start.

It is the actual distance from the camera to where the ray hits geometry. Even with the converted EXR you’ll have data that goes way beyond the 1.0 that regular colors can handle. In Photoshop and GIMP that will turn up as completely white. Which is why most EXRs with distance channel look fully white.

It is necessary to go beyond the regular color range to maintain fidelity of the data. Say you have distances that give you a range of 1000 units, if you put that in 0.0..1.0 range you loose a lot of precision.

The script I wrote gives an EXR that is useful for displacement like a heightmap.

You can try using the original EXR for displacement, you’ll find that it is hard to control. And it isn’t necessarily easy to find the generated displacement mesh, since it could be outside of the viewport due to the distance values.

Here a quick demo of how pre-converted EXR and post-converted EXR work:

distance_vs_hf_exr_visualised.3dm (367.0 KB)

In the file the two on the left are EXR files with distance data directly saved through the Render Window. As you can see, no need to really change them. It is just that those are a bit harder to use. The two on the right have the values inverted to height instead of distance, and the range moved to 0. Easier to handle, but essentially still the same data range.

The range is necessary especially when you have lots of detail you want to capture. Cramming all that in the 0.0..1.0 range means you loose definition.

I hope that makes sense.

I think I understood.
Learned a lot today.
Thank you Nathan.