Display conduit: V5 to V6 changes

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!

This gif illustrates the flickering in V6:

Hi Dave,
Can you supply the GH definition that you used for creating the above GIF so I can try and repeat this?

Hi Steve-

I’ve attached the Conduit GHA as well as the def. You should be able to test in both V5 and V6 and see the difference.

thanks for getting back!

ProvingGround.Conduit.gha (178 KB)

Conduit Instability.gh (9.1 KB)

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

public void Draw3dText(Text3d text, System.Drawing.Color color)
{
  Draw3dText(text.Text, color, text.TextPlane, text.Height, text.FontFace, text.Bold, text.Italic, text.HorizontalAlignment, text.VerticalAlignment);
  DrawLine(Point3d.Origin, text.TextPlane.Origin, System.Drawing.Color.Azure);
  DrawPoint(text.TextPlane.Origin, PointStyle.Circle, 4, System.Drawing.Color.Red);
  DrawBox(text.BoundingBox, System.Drawing.Color.Purple);
}

You can see in the attached gif that the geometry is being clipped at certain camera angles.
Text3dClip

I don’t have a recommendation yet as I’m still not sure why this worked in V5 and now doesn’t work in V6. Still investigating…

Thanks for the update! I appreciate it…

Did you ever have to set the bounding box in CalculateBoundingBox in V5?

No I didn’t…it worked without it. Although I always felt that it shouldn’t have…

Just poking you a bit on this…

Hmm… I thought I fixed that recently. There may be mention of this from Brian as soon as we release our SR9 release candidate 1

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

-Nate

Hey Nate,
Are you referring to the samples that Dave posted earlier in this thread or is this something different?

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

Ok; I’ll look into this issue this week. (edit) I can repeat the issue by adding a sphere to the scene. I’m on it
https://mcneel.myjetbrains.com/youtrack/issue/RH-49445

Is this the latest code for conduit?
https://bitbucket.org/archinate/conduit/src

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.

1 Like

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.

1 Like

3 posts were split to a new topic: DIsplayPipeline Requests

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:

Point3d[] m_farCorners = e.Viewport.GetFarRect();
Point3d[] m_nearCorners = e.Viewport.GetNearRect();

Point3d[] m_viewCorners = new Point3d[4]
{
    (m_farCorners[0] * 0.15 + m_nearCorners[0] * 0.85),
    (m_farCorners[1] * 0.15 + m_nearCorners[1] * 0.85),
    (m_farCorners[2] * 0.15 + m_nearCorners[2] * 0.85),
    (m_farCorners[3] * 0.15 + m_nearCorners[3] * 0.85)
    };

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.