other navigation like rotating the viewport with right mouse button is very smooth no matter what light setting i use, but zooming is so laggy that its unworkable. that has been an issue for quite a while, nobody else seeing that? though i am on MacOs Sequoia that already was an issue before.
Info.txt (12.7 KB)
I don’t see that here. Is it model specific, or do you already see it in a simple test scene? Do you have another mouse you can test with to rule that out?
Is this something you can record?
Does zooming Cmd+RMB work fine?
thanks for checking @Gijs yes that issue shows in any simple file, no material just a sphere or a cube and shadow activated. Cmd+RMB works fine indeed. i have a mouse with a step wheel (never found one without) and to be sure i tried with a different mouse. also i have set the scale factor to 0.75 i assume that might exhibit the issue stronger.
Rhino always seemed a bit more laggy with the wheel that is an issue since forever, it got better at some point but then again worse (i at least have the feeling) but in Rendered mode it is very obvious.
using Cmd+RMB i can see that as long as i hold the mousebutton the shadows are a bit grainier, meaning that it kind of makes a reduced preview which performs better. zooming with the wheel it does not do that, is that something which could be improved? using a mouse with wheel is my only real option, i was thinking about getting a touch pad then zoom would be continuos like Cmd+RMB, but i am not sure if i really want to do that.
will try to record a video if that really helps
here you go, a mov file, hope that works.
in the beginning i start with the wheel zoom, later i go through Cmd+RMB and rotate and then wheel zoom in the end again
OK, to me that seems to work normally, it’s not necessary laggy bug jaggy and caused by the zoom steps and scroll wheel steps. If you change the zoom scale to 0.99 and disable the stepping in your mouse (if it has that) you get a smooth zoom experience. I’m using a Logitech MX master.
the issue appears with any mouse i use, also i can not disable the stepping, i have not encountered a mouse that could do that. i am using a Logitech G PRO. also i have set the zoom to 0.75 because i like to work very quick, setting that to 0.99 would not help me.
most certainly, but maybe there is a way to improve that? i would suggest once the zoom is activated that there is a time out in which the low resolution shading (or whatever happens) stays active till i not zoom anymore for 0.5 ms for instance.
the steps build up so slow that i am finished scrolling long ago and i still can watch it zooming that is the problem. i can not see any way to change my settings so i am hoping that somebody could look into it.
here is another video i tried to zoom a bit louder so that you can see/hear when i am finished zooming, but the zoom still needs quite some time to complete because it builds up each step by step painstakingly slow. it is unfortunately really unusable even though the performance seems to be there. i had the feeling that was better at some point, but right now working in rendered mode is absolute no go.
here to compare how it looks like in wire mode for instance, shaded mode would be the same. if you look really closely there is still a very little lag but i have gotten used to it, compared to rendered mode its a huge difference.
I don’t see any delay here, but it might be because I’m running this on M3 Max. It zooms immediately at 0.75 and stops immediately as well.
Do you know when this was better? If needed I can send older builds to compare it to.
i am running a mac studio m1 ultra, it should not be that slow, but thinking about it i am running a 4k screen which gets recalculated internally to match a different resolution, maybe that is the issue
maybe the 4k issue qualifies the problem now, if there was a difference then it probably was better in v7, will think about it and make some tests when i get to it, thanks again for double checking!
This issue has been around as long as Rhino and is a general problem for mouse wheels, trackpads, and 3d mice. When the mouse is moved while a mouse button is down we know that we are in a state where the display is updating for things like pans and orbits and that eventually Rhino will get an event signaling that the mouse button has gone up.
When the mouse button is down and moving around we redraw the views with different levels of degradation knowing that eventually the mouse will come up and we need to do a non-degraded redraw. We don’t know that when a mouse wheel is moved that there is another mouse wheel operation coming very soon and therefore can’t determine if we need to perform a degraded “dynamic” draw/
i had the feeling that windows rhino was faster in mouse wheel zooming and always hoped mac rhino would catch up eventually, of course a lot has changed since then i started in 2010 with rhino 4 and only worked a couple of times with it till i got a hold of the first mac beta.
anyway i am thinking what i suggested above to degrade the view the moment the mouse wheel gets touched and make a time out of a half a second to switch back to undegraded, could that work? or something in this direction?
Something like that is probably the approach to take. It’s hard to get right; at least I think it is.
could the wheel steps trigger a reset of the timer till it gets no more triggers with a timer set to .5 or maybe even faster .3? then it just displays the full image again after it ran out.
also does the same degrading actually happen in wired or shaded mode? i just have the feeling that zooming itself is generally faster in v7, but rotating viewport and other actions seems a bit faster in v8 so its a bit of a mixed bag for me at least.
i made some testing and it seems that the skylight shadow quality is exclusively responsible for the laggy experience in rendered mode, if i lower it just by one step it gets already better, still a bit laggy though, if i lower it more the shadow gets pretty grainy of course
