I’m happy we are at least in two people experiencing the same problem.
Cold comfort (but still a comfort : )
Yet another info: now (some more time modeling in the same session) the lagging happens also in zooming and panning, and even with just 3 objects visible (only 18 surfaces total!) and it happens either in shaded modes and in wireframe mode the same way. All the preferences for all the view modes are set to default.
Now I will try to play with them.
Yet yet another test: I saved the work, closed the session, opened a new session on the same work (at the same point with three objects visible, where it was lagging in the previous session) and now EVERYTHING moves and works perfectly smooth again: panning, zooming, selecting multiple objects. In all the view modes.
As I suspected it’s something “building up” as the session goes on: the more I work on a file, the more selection and movements are lagging.
@pascal @John_Brock Someone at McNeel may want to look into this:
@gian Please post the results of SystemInfo (WIP V8) from your systems with the updated drivers.
1 Like
Hi @davidcockey
Here it is sysinfo for the machine where that occurs, even with updated (VERY recent!) drivers:
Sysinfo DELL T7600 - DRIVERS 2023.txt (2.7 KB)
Please note that after updating the drivers on all my three machines, this is the machine with the most recent ones and with the last Rhino 8 WIP release. Here is a resume:
DELL T7600 Desktop Workstation
Windows 10 Pro v. 22H2 Build 19045.2788 - 18/01/2022
Primary display and OpenGL: NVIDIA Quadro K4200 (NVidia) Memory: 4GB
Driver date: 2-24-2023 (M-D-Y). OpenGL Ver: 4.6.0 NVIDIA 474.30
Rhino 8 SR0 2023-4-4 (Rhino WIP, 8.0.23094.11475
So far, I can not duplicate this.
My last test was a 25 x 25 x 1 array of shaded boxes.
I started selecting with Shift held to add to the selection.
Then copy a stack of the selected boxes and try again.
Can someone please provide an easily repeated sequence to duplicate the problem?
Hi @John_Brock
Thank you for being here!
At the moment I am working to a project for a client and I cannot do much more than what I’m doing and posting here, I am sorry! Not now and for some days on at least.
What I can say is that I suspect it is something related to the management of memory or so, because the sensation is that - as I said - something is “building up” somewhere, gradually “obstructing” the dataflow for the viewport.
Until now I didn’t noticed specific operations causing this, but a progressive deterioration of movements (lagging more and more) as the modeling session goes on. It gets worse and worse in time, as the sequence of commands goes on. It happens after minutes and after many different operations and camera movements.
The same model, saved from Rhino 8 WIP and the opened in Rhino 7 is not affected: you can work on it for hours without any problem and perfectly smooth movents and selections.
What I could try is to isolate only the parts of the assembly I am working on (copy and paste them to a new file in Rhino 8 WIP) and see if it happens also this way. If it does, I can send you the model of that isolated parts for you to test.
That’s what I could do.
If we can repeat it, we can find it, and most likely fix it.
Thanks
1 Like
Wise position.
I’ll let you now as soon as I figure out how to do.
Thanks to you
Ok. Even on the (much!) reduced model, after about 15 minutes of nurbs modeling session, the lagging starts. I can send you the model then, as it is a tiny part of the whole project.
Only thing: you got to work at the model for many minutes with cutting, booleans, joining, exploding, extracting and adding surfaces and so on, before something happens. Admitting that it happens, on your machine, of course.
Give me the time to finish my working session and I send the file here.
Only thing: you got to work at the model for many minutes with cutting, booleans, joining, exploding, extracting and adding surfaces and so on, before something happens.
It’s a kind of magic… 
Here is the model to test, @John_Brock
Sasso56 - only interface - v7.3dm (4.2 MB)
This is a bit of a problem.
I do not, and never have used Rhino professionally.
I poke at, and test specific problems; working with the developers to isolate problems and test their fixes.
Yes, I have “guerilla tested” Rhino on a few of my own home projects; designing and building furniture in my home shop, but just poking around is not an effective way to reproduce a problem.
I’ll do what I can between calls and testing, but to use Rhino like you do to reproduce a specific problem is problematic.
I do see a “clipping plane” in your file.
If you remove it, can you still reproduce the problem?
That strikes me as a likely culprit.
Thanks
Hi @John_Brock
Yes I know and understand the different approach. And thank you for helping anyways. Bit really I did’nt find any particular moment or instruction or object (until today: now I’m observing things deeper and deeper within this problem, so with tine I could give new clues).
So the only thing I noticed is the “building up” phenomenon: perfectly smooth movements and selecrions at the very beginning of modeling, gettin worse and worse as soon as I use the modeler on that file. Then I close and reopen and it’s ok again.
It happens on any model I work on and is not affected by clipping planes it seems. But I should give it more careful try to that…
I have found a problem.
The polysurface on layer “Main Shell”, does not check out.
I isolated it using Layers, Exploded it, Rebuild Edges, and Join.
This resulted in an “Open polysurface” with naked edges.
PS: I will seriously put under test your clipping planes suspect tonight…now it’s 17:30 here.
Oh aye, we just started Friday here.
I did not find any other problem objects, just the one, as if someone may have used the much misused “JoinEdges” command.
Another thing to watch is the memory Rhino is using.
What you’re describing sounds like a “memory leak”.
If it is, then the memory used by Rhino will slowly climb during the session.
Thanks and good luck!
Enjoy your weekend.
Yeah I know that “open” thing: it was solved meanwhile (it’s a file I am working on as I said) but nothing new: same lagging after a while.
Please consider that these are (in part) surfaces/solids imported from a STEP file coming from SolidWorks.
But, again, I’m working since years to this kind of files with Rhino 7, and it was never affected by this problem: not any slight lagging even after a whole day modeling session!
And the files are exactly the same ones: now I went back to Rhino 7 to work on these as I must finish and Rhino 8 WIP was a pain in the ass with that lagging, while Rhino 7 works smoothly on this too.
A suspect and so a test I must do: start a file from scratch in Rhino 8 WIP and see if “internally generated” geometries are free of this issue.
Infact, imported geometries on Rhino 8 WIP already gave me problems with Extrudesrf: you’ve seen that topic, that now was filed by @davidcockey as a “major bug”.
One thing to try…
Shapes that Rhino would created with fewer surfaces, are split up in STEP.
Sometimes the “_MergeAllCoplanarFaces” command.
You may have already done that simplification.
The ExtrudeSrfbug is independent of wither the object was imported. Or created in Rhino. It occurs with any trimmed surface in the current V8 WIP. ExtendSrf on trimmed surfaces - major regression