Rhino 6 bug - ShowZBuffer

[Jarek]

Hi Jeff,

First, by making this extra fix this YT item can be closed
https://mcneel.myjetbrains.com/youtrack/issue/RH-37442

Will this fix be a part of the next V6 SR ?

@jeff

What do you use the hires depth buffers for? Just wondering if there’s anything Rhino can do to help facilitate that as well???

We use the ZDepth info to add “fog” or “atmosphere” effect to the screenshots produced from Rhino viewcaptures, mainly for architectural, urban planning and interior design project (so, larger scale models).
This effect can drastically help to “read” the perspective images better and add true depth.
The use so far was very limited due to the tiling effect of hires screenshots; with the fix, if all works as expected, we will use it much more extensively.

Having said that, taking “zbuffer” screenshot and combining it with original screenshot takes place manually outside of Rhino. There are several further developments to consider to make ZBuffer more useful.
One of them is ability to control min-max depth, and not always use scene bounding box. Currently with very large models or scenes with objects very close to camera many times it is hard to achieve a good gradient.
We did have this discussion before and you mentioned some of it is implemented under the hood, but not exposed to UI just yet:
https://discourse.mcneel.com/t/better-use-of-viewport-zbuffer-functionality-please

Better use of viewport ZBuffer functionality please

Hi @Jarek, No control exists to adjust the physical near and far clipping planes…It’s been on the todo list for a long time but just hasn’t found its way to the top… However, I don’t believe this will fix any of the tiling seams…but maybe…won’t really know until it’s tried. I’ve already got in place a way to tell Rhino what the near and far values are (which was an attempt to fix the tiling seams), but it didn’t work. Apparently even having two adjacent viewports using the exact same near and …

There is one more ‘bug’ that has been around in V5 and since in V6 Zbuffer didn’t work I could not tell if it is still around - maybe you can check and see - it is about the clipping plane object in ZBuffer-enable vports.
Currently the Clippingplane objects show in Zbuffer mode unless they are selected; also selecting them seems to ‘narrow down’ the ZBuffer range closer to match clipped area. This clip should show better what I see in V5:
https://www.screencast.com/t/ceWAl9WAO40

The “Ideal” behavior with clipping planes would be to be invisible for ZBuffer and also truly limit the scene bounding box. This way they actually could be used to control the range (via scripting, for starters).

The above would not be needed, if min-max range is exposed in a command or even incorporated into UI.

The very best case scenario is adding “fog” parameter as a part of each ‘display mode’, with ability to control the color and “intensity” (percentage of overlay) or the Zbuffer info over the vport.

Here is the example of the ZBuffer info in practical use. The right-most image now is the effect of manually combined # 1 and # 2, but with “fog” implemented in Rhino based on ZBuffer it could be automated and also used in real-time model presentations or walkthroughs…

–jarek