Selected preview weird behavior in Rhino 6 SR4 viewport

unhandled

(Burak) #1

Hi, I have a problem with selected preview of referenced geometry from Rhino model:

When the GH component is set to “preview on” and selected in the GH canvas I can see the object highlighted in green.

However when I switch to selected preview mode and select the same GH component (either with preview on or off).

The viewport display is set to Wireframe. The preview problem seems to be something like “set to back” draw order kind of thing. When I lock the Rhino geometry, I can see the selected preview in the Rhino viewport.

Is this a bug or is there a setting in Rhino options to correct this issue?

Thanks,
Burak


(David Rutten) #2

I’m assuming that this sentence was supposed to end with something along the lines of “then I can no longer see the preview.”?

It sounds like a z-bumping thing. When two objects are drawn exactly in the same place in 3D, then it’s a toss-up which one will actually ‘win’ and be visible. Grasshopper will bump the z-depth of the viewport prior to drawing selected objects, to hopefully ensure they will appear in front of any competing geometry (either Rhino or other Grasshopper previews).

I’ll have to double check this is still happening in preview-selected-only-mode, but ultimately if you have more than one thing in the same place, you’re going to run into occlusion problems.


(Burak) #3

Thank you for the explanation David,

Definitely it looks like an occlusion problem but this does not happen in Rhino 5.

The GH preview appears behind the referenced geometry unless it is locked in Rhino viewport.


(Burak) #4

Hi David,

Just noticed an other case while working with selected preview.

When I am close enough to the object in rhino viewport, selected preview can be seen. When I zoom out it is no longer highlighted.

Thanks for your help.


(David Rutten) #5

True, in Rhino5 all Grasshopper previews were biased towards the camera. In Rhino6 only selected Grasshopper previews are.


(David Rutten) #6

The problem with z-biasing is that it doesn’t work well if the distance from the camera to the scene is very small or very large compared to the size of the scene. It never has worked well, and it never will either unless someone comes up with a much smarter biasing transform.

I’ve logged an issue under RH-46279, but no guarantees that an actual improvement is possible.