ShowZBuffer command turns active vieport black - nothing is visible.
Yup.
RH-43885
FYIā¦just fixed thisā¦ and I also made changes/additions so that very large resolution depth buffers can now be captured without any of the tiling artifacts.
5 Likes
This is great news Jeff. Must have been more than 5 years I was wishing for that hires fix!
Actually, itās probably been longer than that 
ā¦ It just never fell onto my radarā¦ It didnāt really fall onto it here eitherā¦but I had an epiphany when fixing the bug and thought āwhat the heckāā¦
Anyways, I appreciate your patience!
-Jeff
Btw @Jarek, What do you use the hires depth buffers for? Just wondering if thereās anything Rhino can do to help facilitate that as well???
-J
I`m not Jarek,
my answer: Eg. Convert 3d model to bas-relief,
so Z-Buffer to -> Heightfield or ZSurf, in other words from 3d to 2.5 D
16 bit depth would still help.
Do you remember the praline displacement discussion with Gustavo (still in the Newsgroup I believe)?
Holger
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 ?
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
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
1 Like
Thanksā¦ Although you can actually turn off the display of the clipping planes at any given time form within the Display Panel, I do understand the reasoning for why they probably shouldnāt show up in a ādepth bufferedā situationā¦ So I went ahead and made that change as wellā¦ Now, clipping planes will not show up at all inside a depth buffered view.
-J
2 Likes
Yepā¦I do remember that conversationā¦and with the latest changes, this might even be very doableā¦ I believe the only formats that support this though are TIFF and TGA ā¦ ??? Or have things changed while my head has been down? 
-J
@Jarek, forgot to mention thisā¦ The fix will be in SR3 (V6.3).
-J
Nice!
Tif is fine, .png should work as well. Targas are seemingly still popular in Games but I havenāt opened one in the last decade.
Thanks Jeff - did you see the difference in ZDepth depending on ClippingPlanes being selected or not?
( per the video clip what I see on my end in V5 ). Obviously the version that takes clipping into account when calculating the ZDepth range would be desirable, so we can control it that way.
In the latest RC3 candidate the hi-res ZBuffer capture doesnāt work well. Itās not tiled anymore, but rather either clipped or completely out-of-whackā¦ @jeff - do you see any problems on your end?
Also, the clippingplanes donāt show anymore (nice!), but if they are selected, the shown zdepth is different than when unselected. Ideally the clipping would be taken into account when calculating the range.
EDIT: with clipping planes present, the hi-res captures seem to work ok on a simple scene with a few boxes. With no clipping planes the capture gets āclippedā closer to the camera, or sometimes looks completely weird.
Hmmā¦Iāll need examples thenā¦ Iām using more than just a couple of boxesā¦ Iām using real scenesā¦and doing captures at 4x and 5x without issue.
So I want examples that seem āout-of-whackā ā¦ Also the selection vs. non-selection issue is most likely an issue with the near and far clipping planes changing. I know Pascal is having issues with this too, and thereās currently a bug about it still on my listā¦so obviously Iāve missed something or havenāt got something right in certain situationsā¦which is why examples and repeatability are key.
Thanks,
-Jeff
Hi @Jeff,
I think I found the issue - the ZBuffer captures get messy if anything is selected in the scene. Otherwise I tried many scenes and settings and all worked quite well. An one-box scene should show the problem (but happens also with more complicated scenes). This one looks similar to the problem @Pascal reported on YT ( https://mcneel.myjetbrains.com/youtrack/issue/RH-37442 ) - I wonder if you remember your box was selected while producing that capture. Here is mine:
hope that helps to make the fix, and move on to Zbuffer Project Stage 2: Let us control the min-max distance! 
ājarek
It makes no difference for me. I use Rhino 6.2 commercial version (2018-3-6), Windows 10 Pro (64-bit) operating system, ThinkPad W530 laptop computer with Intel Core i7 3920XM processor, 32GB RAM, 512GB SSD, Quadro K2000M graphics card, (NVIDIA driver 390.77, 2018-1-23) 15,6 inch LCD (1920x1080).
Hi Jarek - here is makes no difference if my box is selected - I get what your images show if I make a new file with a boxā¦ but if I open a file, it seems correctā¦ still poking. Nope, that is not always true eitherā¦ weird.
-Pascal
Hmmmā¦ Here the problem with selection is consisted.
But looks like there is more to it, thenā¦
@Jeff - attached is my system info in case it helps.
JB_Rhino_SySInfo.txt (1.6 KB)