Yes I became a DJ pressing ctrl m and f5 all the time… Sorry for negativity but this issue needs to be looked at.
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.
That the issue about repeatable case. Once display is ok, other times not and when recomputed again ok.
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,
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
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.
Thanks, I’ll dig into this as soon as I get to the office.
No matter how long I mess about with the sliders, the display simply fails to do anything out of the ordinary.
When I get back next week from a trip I’ll have to start figuring out how we can get information about these meshes from a computer where it does fail.
So strange. In the three computers I have available it glitches. Maybe you have a newer version of gh not available yet that it was fixed in? Or maybe it’s graphics card issues (My machines have nvidia gtx 980, 1070, 1080)?
I have encountered this as wellpl-e1 error.gh (46.2 KB)
Unify mesh component sometimes helps repair the display issue… But other times it causes it, so not a great fix I’m afraid
David, any updates on this?
I am working with the Version 6 SR13 (6.13.19058.371, 02/27/2019) and still have display issue when using mesh in Grasshopper. Meshes continue to display when GH preview is off plus sometimes the mesh display acting weirdly.
I just found that the Custom preview component has a “render” option (right clic) that kind of overrides the GH display when in Render mode in Rhino.
There was supposed to be a fix for meshes which may have been responsible for the display issues. We had a really hard time replicating them and thus couldn’t be certain whether the changes would fix the issue.
Apart from the Custom Preview thing, are you still getting wrong mesh previews in non-rendered display modes (i.e. Wireframe, Shaded, Ghosted, but not Rendered or Raytraced)?
The display issue I had recently were in render preview mode it was during Jan/February with the up to date version of Rhino. For some reason I am not able to reproduce it today but I remember that when refreshing the GH definition by pressing F5 many times the display cycles through different version of the mesh. Not sure but it looks like a buffer issue… If it happens again I will send you the file.