DrawMeshShaded does not work well with Top/Right/Front viewports

Hello,

I am using DisplayConduit to draw robot Mesh dynamically. It works very well in perspective view. However, when I switch to any of the orthogonal views like “Top”, some triangles of the mesh are displayed “inverted” (see picture below).


The mesh looks fine in Perspective view:

I am using DrawMeshShaded inside the overriden PostDrawObjects() method to display these meshes.

Can someone please help on figuring out what could be potentially wrong? Is it a bug with Rhino or am I implementing DisplayConduit wrongly?

Hi @vaibhav.shah, some things to check:

  1. Is your bounding box set up large enough (eg. when mesh is animated) ?
  2. Is the mesh perfectly clean and has no duplicate faces ?
  3. Is the mesh far away from the origin ?
  4. Do you have the groundplane enabled ?
  5. Does the problem happen when all other objects are hidden ?

_
c.

Hi Clement,

Thanks for replying.

  • For the bounding box, I am using the viewport frustrum to obtain the boundingbox dynamically. What would be an ideal way to calculate the boundingbox assuming you are drawing possibly hundreds of different geometries at one time?
    image

  • I am not sure of the mesh. I will try and remove any duplicate faces after loading in the robot and check if the problem still persists.

  • I would not say the mesh is far from the origin. The base of the robot is on the Rhino origin and the robot is around 1.5m high.

  • The groundplane was on the whole time. But the problem still remains after I turn it off.

  • The problem happens regardless of if all the objects are visible or hidden

Edit: I forgot to mention that this behavior mostly happens when I zoom in or out while in projected views. The initial view once I open up any projected view is correct. But once I zoom too close and then zoom out, this starts happening.

Hi @vaibhav.shah,

to exclude the bbox as potential cause, generate one which is likely large enough, eg. if you know the extremes the robot can reach in all motions, make one static box which is twice as large.

If you can upload that part of the robot i can check.

then i would exclude that as possible cause.

I had similar issues in the past and found that the groundplane (when enabled) influenced the conduit’s bbox. My defined bbox has been ignored in the display conduit. (link). But your problem looks different, less likely a clipping issue. To rule this one out, you might try to draw the bbox as well in the conduit.

Do you have a space mouse connected ?

_
c.

Hi Clement,

It was a bounding box problem!

So I included a 4m x 4m x 4m bounding box inside the CalculateBoundingBox method and it fixed the issue.

Now, I just have to find a way to predict my maximum limits based on different user scenarios and that should solve the problem.

Thank you so much for the help!

2 Likes