Rhino6 Grasshopper mesh display disordered

Hello,

Please see the above two videos. I was using the same file to display the movement of robot.
After I upgrade to rhino6 6.7.18210.11281, it seems like the mesh display is disordered.
This situation also happened in the prior version, but it can be resolved by reconnecting the mesh component in grasshopper file.

Any ideas??
Thanks in advance.

Regards,
Shaun

1 Like

It constantly happens for me too. Especially when creating meshes through c# script editor and reconnecting wires helps a little.

1 Like

I’m getting the same problem:


It’s on-and-off, and sometimes just refreshing the solution (F5) clears it, but it very quickly comes back again, and is different every time.

I have tried cleaning the meshes, but this seems to happen to any mesh, including ones I’ve just referenced from Rhino. Very annoying… :frowning:

Is it when using C# script editor in grasshopper?

Hmm yes it seems so. Just tried it again, and it does seem like something to do with meshes that come out of a C# component. Mind you, it’s not the C# component preview. Even when you hook up a Mesh parameter it still causes these funny errors.

Agree no preview stuff, just things that happen in C# script editor especially if you have more than one mesh as input.

For a long time I thought I was making shitty code (which I do) but this was additional layer of frustration

Mcneel people ignore these posts. Bastardos.

@tom_svilans I found a little trick to hide the issue.

Try “ctrl+m” to hide the mesh edge preview in grasshopper.

by the way. I’m using python, it comes out same issue with C# user.

Same mesh display errors for Kangaroo2.
If you want to reset solver each time and you get this stuff it is annoying…

@Petras_Vestartas Have you tried ctrl+m?
It doesn’t solve the issue, but at least make your day brighter.

Yes I became a DJ pressing ctrl m and f5 all the time… Sorry for negativity but this issue needs to be looked at.

1 Like

I’ve been busy setting up a new workstation since Thursday, but this is next on my list. At this point I’m still trying to get a repeatable case though.

2 Likes

Thank you:)

That the issue about repeatable case. Once display is ok, other times not and when recomputed again ok.

Hey David,
is there any news on this issue?
I’m still getting the errors described above in the SR6.9.18271.20591 from 09/28/2018.

Thanks and cheers,
Robert

Can confirm it is still occurring, any idea?

Is there a repeatable case anywhere? I’ve not seen any problems on my machine so far, but then I haven’t been making many meshes with scripting components either.

There have been many changes to the mesh display code over the lifespan of Rhino6, and recently there were also some optimisations with Mesh.Append(), and there have been reports that seem to point towards a problem with single vs. double precision vertex list mismatches. Any one of these could be causing display problems, and without a repeating case it’s near impossible to fix it.

For me the issue isn’t just with script components, I think others that noticed it just happen to be scripting meshes more. Here is a case where it occurs in a repeatable way without scripting. Morphing a mesh into surface boxes in R6.9.


SrfBox.gh (8.4 KB)

It may or may not appear when you first open, just change the sliders around until you see the weirdness occur. The glitches are always different also. And then with just a simple recompute (or two) it goes away, it also does not bake the glitch.

After a recompute

After changing some sliders again

1 Like

This issue is still with me.
It happens quite often, especially when I’m running a simulation, mesh’s positions are constantly updating, but it seems like some kind of conflict occurring with old mesh positions.

My rhino version: (6.9.18271.20591, 09/28/2018)
I don’t have this issue in Rhino5 instead.

This time got even worse:face_with_raised_eyebrow:
I copy paste a nurb surface in the file, and some part of the robot meshs “connect” to it instantly on display.

Yep, it happened for me too.