Since my Rhino 6 evaluation license expires in couple of days, can I download the upcoming Rhino 6.27 to try if the fix is working with my Logitech G502 while still use the program as an evaluation version without saving possibility?
I believe that will work. The installer just updates your installed Rhino. You’ll just have an expired 6.27
@stevebaer - thank you for making this fix. While I did not discover/experience the problem by OP, I have been dealing with similar issue for a while now when my Stork plugin users working with 1000Mhz polling rate mice reported experiencing stuttering while using the plugin. Spent a lot of time trying to figure out the problem to no avail; so far a not very practical one was just to advise them to switch mouse polling rate to 125 Mhz.
Now after reading this topic, I can confirm that:
a) turning off the Status Bar helps to fix it and have smooth movement
b) your fix does the job, both V7 and V6 recent daily builds work smooth even with Status Bar visible and with any mouse polling rate.
@maje90 - thanks for your persistence and documenting this issue well.
Unfortunately, switching a Logitech G502 mouse from 1000 rps to 125 rps turns on the acceleration of the mouse, which means that fast movements with the mouse will result in a longer travel of the mouse pointer on the screen compared to the same distance of moving the mouse with a slower speed.
On my G502, 2000 DPI at 1000 rps is relatively equal to 1250 DPI at 125 rps, but the latter setting feels really distracting because of the added variable speed for the mouse pointer acceleration.
Hi @stevebaer, I have one more question, perhaps related to this one, that I ran into with my view navigation plugin. It uses MMB-press (and mouse up/down) to change flight altitude. All works well and smooth (overriding Rhino’s MMB via lowlevelmousehook) in most cases, but as soon as Render or GroundPlane panels are visible, the movement stutters a lot. Note that no other mouse or key movements are affected, only when MMB is down. Is there anything in these two panels that may affect this behavior?
I’m not sure; probably best to start another thread for that
I confirm, on 2 machines the problem is greatly decreased. I can also use the mouse at 1000Hz while using the 3d mouse.
Using fpsmon.com to see framerate and frametimes:
- turntable alone go 300fps with enough constant frametimes;
- enabling status bar make it drop to 280fps;
- enabling/showing “Properties” tab make it drop to 40fps and the frametimes go crazy!
- moving the cursor over the ui or the viewport still insert spikes in both framerate and frametimes (holding the left click sometime prevent the worsening);
- drawing a line with status bar and Properties tab off, 28 fps!
3dconnexion rotations go 61fps, and now seems to be much less influenced by cursor movement, but still there are recurrent “hiccups”, very noticeable inconstant frametimes.
Blender 3dconnexion rotations go 200fps but 3dmouse is disabled while the cursor is outside of the viewport (and i hate that).
I don’t know if I should continue “reporting” the various cases and their combinations, i can found much more of them than what i’m reporting, but i fear to bother you.
Overall the situation now is good, not perfect, but much much better than before.
Thank you for the support! Really appreciated!
You mentioned one huge advantage of Rhino and that’s the ability to rotate the viewport even while dialog boxes are opened (such like “Blend surface”, “Sweep 2 rails”, “Import” etc). It’s an extremely useful feature that I hope “McNeel” will keep in Rhino 7 as well.
That’s strange. Are there any values updating on the properties panel while you are testing? Things like the camera position…
Please do keep reporting issues; it only helps us improve Rhino. The status bar bug was a great find and will help a lot of users.
Not sure who those guys are, but the McNeel team isn’t planning on making any changes to remove this functionality
Sorry for the misspelling. I like how you pointed it out in a fun way.
Sorry for late reply.
I was collecting more cases and situations where the stutter happen, but they were simply too many.
I constantly use the 3dmouse and i’m also used to high framerate due to videogames.
I see micro-stutters on rhino everywhere.
Last month i started working on another office with 3 pc with rhino, finding again situations with stutters.
That made me remember about this post.
But sadly it’s still there.
While no other command is active, the problem is indeed gone, almost completely.
But if a command is active (like, while trimming a bunch of curves) the stutter is still there!
I don’t know what to say.
I feel like i’m the only one using the 3dconnexion this extensively, or the only one bothered by the stutters…
If the status bar and properties tab coordinates are the problem, can’t them be “set on lowest priority” all the time?
Currently working with status bar off again…
But generally, on any pc, no 3d connexion, even the normal “2D” mouse disconnected, turntable command doesn’t give a smooth animation (fps and frame time) even with an empty file, just the grid.
It’s incredible how big is the difference, from CAD to videogames. On games you can see millions of polygons changing place and color at rock-solid 60fps or more… on rhino the grid alone stutters.
I am not criticizing, i love rhino.
No it’s not really incredible. In games everything’s been optimized a dozen ways(by programming teams bigger than the entire CAD industry) to flow as quickly as possible, and the polygon counts are never, ever, never actually THAT high due again to optimizations and clever level layout and normal mapping that can make a square look like a sphere. Also, nothing happens in a game that hasn’t been accounted for, they are “static” no matter how “dynamic” they look. “Content creation” is entirely different.
No, it’s not. But they tend to structure (and process) data differently compared CAD and Business applications (OOP isn’t optimal for having an entire army marching, and no, they don’t have to make moving figures “static” either).
In games they can just skip bothering about precision (the eye won’t catch small mishaps in collisions etc).
I don’t know why you keep harping on that same misconception about gaming vs other “every detail-changes-the world” kind of software which games does NOT suffer from but which CAD and Business systems suffer from. Data must be correct in the latter case, in games you can skip frames if the CPU/GPU load is to big simply because … nothing breaks if you do. So please…
I can’t repeat any stuttering with turntable and an empty model. Do you have modified grid settings from the default?
Personally, I’d prefer the priority was put on status bar stutter during ongoing commands.
I did post a video in slowmotion back there. Turntable alone have frametime that vary +/- 50% or even more.
I can see that all day, but maybe because i’m used seeing high smooth framerate.
For example most of people are not bothered seeing fast scenes at cinema’s 24fps, i do, i’m used to solid 60fps and 24 is less than half!
I don’t want to stick on the frametime matter in specific but, for example, disabling status bar and properties tab make the turntable run 3x faster! (not moving any mouse all the time).
It’s like the viewport camera animation (turntable in this case, 3dmouse in other) is already “choking” on the Rhino UI itself!
This is about me being able to reproduce what you are seeing. If I can’t reproduce the problem, I can’t fix it. I don’t know which specific video you are referring to above and have been testing turntable on an empty scene with a standard mouse. This is why I was asking if your grid settings were custom as that is the only difference I can think of at the moment between your tests and mine.
How are you determining frame rate? I doubt the actual time it takes to redraw a frame in a viewport is changing, but if you have a tool for viewing frame rate during the Turntable command, then I would like to see what you are seeing.