3D SpacePilot lagging again

Hi guy’s… bit of bad news. I have noticed the lagging come back when I zoom in close on parts and do detailed work, rotation starts to slow and crawl. I have found that setting to full view then zooming back in clears the fault for a while, but it slowly comes back. Command-Shift-E is the work around for now.

I wrote at the beginning of July to support 3D Connexion to report the problem of slowness in the movements and zoom with my Space Navigator. They told me to contact the support of Rhino to see if they issue a patch. Now the patch was released, but it seems the problem remains. You need an effort “joint” Support Rhino and 3D Connexion to solve this problem.

Is the device you have the one linked to on the Rhino for Mac system specs page?
http://www.rhino3d.com/system_requirements

It may be one of the larger ones which requires something Rhino on Mac doesn’t currently support. I’ve emailed a developer (Markus Bonk) from 3D Connexion too about this thread to see if he has any input.

If you’re posting your Mac hardware info in answer to my last question? Sorry for the confusion, I didn’t mean the Mac itself but rather was curious if the 3D connexion device is the one listed as supported on the Rhino for Mac system requirements page. Or is the 3D connexion device being used when the problem is seen one of the larger models they manufacture. I want to figure out if what we say we support isn’t working well or if this is another device.

Maybe I misunderstood I ^^. I for my work with Rhino use this:

Thanks, I use the same one and that’s what we list as supported. I don’t see a lag here using their 10.2.2 driver for OSX. Have you already provided a model and step by step instructions on how to see the slow down?

I see now the SpacePilot is their larger more button laden Pro product.

I took it from a few hours from the iMac service and I could not even try the latest version of Rhino. In the coming days I’ll see if there have been improvements. ’ I will update my post.

I have found that if I zoom in using the mouse. I can override the zoom limit on the SpacePilot and carry on working in greater detail. It looks like the lag is a function of zooming using the Spacepilot and panning round a zoomed object. I can zoom out with the SpacePilot zoom in on another part and the lag returns. I get this on all drawings.

Yes, SpacePilot Pro in use here, but the core axis movements use the same mechanism as the rest of the range.

I heard back from 3D connexion and they said they don’t see a problem on their end. Sorry, I don’t have anything more concrete to offer other than their latest driver.

Your description makes me think about the zoom target though, next time this happens, please try selecting what you want to work on and then using ZS and enter to zoom selected. Then see if the lag is gone. My hunch is that the 3D device thinks the target is somewhere else and is not moving it to where you think it should be. Try the option to rotate about the camera in preferences or turn it off for that matter if it’s on as a test.

Thanks Brian, I tried to rotate about camera, but my perception was it’s worse. That makes a lot of sense about the centre of rotation not being within the view, somehow the mouse zoom performs better than the Spacepilot in that way. My thinking is the view tracking is behaving differently between the two ? I just tested ZS and that works a treat, wish I had thought of that… LOL Added ZS-Return to one of my button selections, hope that works for others too.

I managed to do some testing with the latest version of Rhino. The problem remained for me. In practice, as do I rotate or zoom in on the object, for about 2-4 seconds a freeze occurs. Roughly this problem occurs every 5 minutes. I can not send the file I’m sorry.
Summary of the audit:
Calculation tables:
90 levels
3 dimension styles
4 font
10 types of line
11741 render materials
Calculation objects:
17768 normal objects
216 locked objects
761 hidden objects
192 objects deleted (in the undo buffer)
0 items framing block
0 objects reference standard
0 objects reference blocked
0 objects hidden reference
0 items framing block reference
No error.
freeze.mp4 (999.3 KB)

Thank you for the video to show the problem? Does the freeze happen in all display modes?

Yes, in all display models.

I can describe my feeling, it’s like a YouTube video with a bad connection. You can watch the video for a while, but then it stops for a few moments because of slow download speed. I thought all’autosave. Just an idea.

I don’t want to repeat too much of what others may have offered but this may be a limitation of the computer you’re using in relation to the model size and render mesh settings. There could also be bad objects. There are a few things involved here, Rhino, the 3DC hardware, the 3DC driver, your OSX version, the GPU make/model/driver. Have you tried hiding layers to see if it continues to happen regardless of what is shown in the viewport.

Sorry for the guessing, there’s not much I can do.

in the video that you saw were active only 2 levels. tomorrow I will do other tests. thanks.

Small update. I used the command “Export selection” and I exported the whole model without the levels in which I held the scraps and background images, the time of freezing has dropped from 3-4 seconds to about 1-2 seconds.It notes that closing Rhino and then the Mac, the next time you start Rhino, it happens that the Space Navigator may not be recognized. To return to normal proceed as follows: 1) Closing Rhino. 2) disconnect USB input of the Space Navigator. 3) Opening Rhino. 4) connect usb socket Space Navigator.

I think this is the clue. Autosaving happens roughly every five minutes, and an autosave can take this long for larger models. That’s why your delay after exporting takes less time.

If you were manipulating your view with the mouse this will never happen. OS X pays attention to mouse events and will not initiate an autosave while you are using your mouse. I confirmed that the 3DConnexion device does not work the same way. An autosave can happen while the 3DConnexion device is active, and the autosave will not be deferred.

I’ve added a test for 3DConnexion activity and will defer a pending autosave until the 3DConnexion device is inactive. This will be in the next RhinoWIP and in Rhinoceros 5.1.

Yes. I suspected that it was automatically saved. I really hope this can be resolved because slows my work. They are available for any test.
Simon.