Rhino 6 bug - ShowZBuffer

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 :slight_smile: … 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
:wink:

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 :slight_smile:
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:

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? :slightly_smiling_face:

-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.

@Jarek

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! :slight_smile:

–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)