There has been a change in behaviors from V5 to V6 that’s significantly affecting our open-source Grasshopper plug-in, Conduit.
The plug-in uses the DisplayConduit to render a HUD to the specified viewports. What has started to happen in V6 is that in the perspective view objects flicker when rotating and zooming, which severely limits the plug-ins versatility. Several of our customers use Conduit regularly as part of their workflow, and are finding that GH definitions that they had relied on for quick feedback for design or for data visualization in client meetings are no longer viable.
It would be great to learn if there’s a workaround I can apply. The version that works fine in V5 had not overridden CalculateBoundingBox which I thought perhaps could help if implemented correctly for V6, but my efforts haven’t altered the behavior. Any guidance would be very much appreciated!
It does look like a camera clipping issue. I modified the display pipeline Draw3dText function to draw some extra elements to see what is happening so it looks like
Hello @stevebaer,
I was wondering if this issue had any updates (re: Display Conduit clipping in V6). Several of our tools are still experiencing problems with Display Conduit “flickering geometry” (that previously worked in V5).
@stevebaer, yes the same issue. It appears that the issue above (re: clipping, flickering) we are experiencing with Display Conduit continues to persist in the most recent builds of Rhino. We have a Grasshopper plugin (Conduit) that makes use of Display Conduits. Many of them still have to rely on Rhino 5 for their work with these tools because of the issue described in this thread. We are unsure of how to proceed.
If so, you are drawing right on the near clipping plane of a viewport and my guess is that every once in a a while numerical imprecision kicks in and the text is being clipped by OpenGL. This is also why adjusting the bounding box in a display conduit has no effect as that also adjusts the near plane of the view frustum.
I don’t doubt there is a bug in Rhino where every once in a while the text seems to be getting biased toward the camera just a little too much in a perspective viewport. It may be easier to just tweak conduit’s code a little to make this problem go away as you will constantly be fighting with this clipping problem when you “play” on the near and far clipping planes of the viewport frustum. For this case, you are in the foreground channel which means depth testing and depth writing are turned off. I would just pick a plane right in the middle of the view frustum for drawing. This would be as easy as getting the far rectangle points and averaging them with the near rectangle.
I could tweak conduit’s code and send you a pull request if that is the easiest approach. Just let me know if that is how you would like to fix this.
On a side note, I really like the concept behind conduit. I’ve been playing around with providing some advanced effects in the viewport by tweaking OpenGL shaders. If you have any wishes for certain “effects” that you would like to have conduit support, please let me know.
Thanks for the recommended approach. It’s working much better now, for sure. Some notes that might be interesting to you:
I started out by setting the drawing plane at precisely the halfway point between the near and far rectangles. This works fine in standard views (wireframe, shaded and ghosted), and dramatically improved things in the rendered views (rendered, arctic, artistic, etc). However, although significantly improved, at the midpoint it was still possible to cause flickering with some rotation and zoom settings, but only in the rendered views.
I found that by adjusting the drawing plane somewhat I’ve found a “sweet spot” that appears to have almost no clipping in either standard or rendered views:
This seems to be doing the trick in all but a few situations for the rendered view (basically hyper-zoomed into an object, some clipping can occur, but this had been causing some odd behavior in Conduit previously anyway, so it really isn’t a problem).
So thanks again for helping us to solve this…we’re in great shape now for sure, but I thought you might be interested to note that there remains some difference in how standard and rendered views handled the updated setup.
Thanks Dave, good to know. You may also want to look at the “2D” drawing functions available on the DisplayPipeline class. Those functions shouldn’t have the issues that you have been working around.