Rhino blocks it just me? Help me understand

Rhino Rhino for Mac
1

Given that the cause could be a combination of factors and not just Rhino, I ask your help to figure out if I can do something. my work is being slowed by the constant “freezing” during auto save. Every 5 minutes Rhino stops for about 5 seconds (the update of the preview icon on the Finder, shows that saving takes place) then everything starts to work. Also, after a certain period of work, pan and orbit slow down and become jerky. Everything back to normal Rhino restarting. I did many tests to try to improve the situation (elimination plugin, saving reduced, reducing the number of active levels etc.) but nothing worked. Any help will be appreciated.

Simon.

Software information

Software versions
Rhinoceros version: 5.2 WIP (5C41w)
IronPython version: 5.1.2015.132
Language: it (MacOS default)
OS X version: Versione 10.9.5 (Build 13F1134)

Plug-ins
/Library/Frameworks/3DconnexionClient.framework/Versions/A/3DconnexionClient

Third party kernel extensions
com.3dconnexion.driver (10.2.3)

Hardware information

Computer hardware
Hardware model: iMac13,2
Processor: Intel Core i5-3470 CPU @ 3.20GHz
Memory: 32 GB
Architecture: Intel 64 bit

Video hardware
Graphics: NVIDIA GeForce GTX 680MX 2048 MB
Memory: 2048 MB
Screen size: 2560 x 1440
Displays: iMac (109dpi 1x)

USB devices
Wacom Co.,Ltd.: CTH-460
3Dconnexion: SpaceNavigator
Apple Inc.: FaceTime HD Camera (Built-in)
Apple Inc.: Bluetooth USB Host Controller

Bluetooth devices
Apple: Apple Wireless Keyboard
Apple: Apple Wireless Trackpad

OpenGL information

OpenGL software
OpenGL version: 2.1 NVIDIA-8.26.29 310.40.55f01
Render version: 2.1
Shading language: 1.20
Maximum texture size: 16384 x 16384
Z-buffer depth: 24 bit
Maximum viewport size: 16384 x 16384

Implementation settings
Use texture compression: Yes

Appearance settings
Antialiasing: 4x
Mip map filtering: Nessuno
Anisotropic filtering: Nessuno

some information about the file to which work
51 named views
20 building plans with name
Summary of the audit:
Calculation tables:
97 levels
2 dimstyles
3 font
2 types of line
6348 render materials
Calculation items:
11965 normal objects
42 locked objects
745 hidden objects
0 items deleted (in the undo buffer)
0 items framing block
0 items normal reference
0 objects reference blocked
0 objects hidden reference
0 items framing block reference
No error.

2

Hmm… wonder if this is a possible cause… Just throwing things out here. --Mitch

3

I can not place the file or part of it here. But if I can figure out how to act on the 6348 materials render. I have not applied any material objects, only changed the color display…

Simon

4

If you have not assigned any materials to objects, how did those all get in there? Did you import stuff from elsewhere?

What happens if you run the command “Purge” and check Materials=Yes in the command options? If you run Audit3dm afterwards, are the materials gone? Does it help?

–Mitch

5

I run as I’ve said, but the materials are always there. The files are the starting points and lines created with a program of photogrammetry and saved in 3dm.

Simon.

6

OK, if the materials are not assigned to objects, and you can’t purge them, there is something wrong there. I don’t know if it’s related to your problem, but it’s something to look at…

Can you just run the following script and see what it reports? Just download it to your desktop, type _RunPythonScript and browse to the file on your desktop… It should pop up a message box.

–Mitch

TestMaterialsReport.py (555 Bytes)

7

8

I reasoned on this photo material and I came to this conclusion: the colors that you see have been assigned in the program of photogrammetry to the lines and points, and when they were imported into Rhino were then changed (usually black). If I try to select a line created with the program of photogrammetry, they are apparently not able to restore the original color (the photo). Now my idea is to try to make lines with Rhino on those imported. Then delete all imported from the program Photogrammetry and cross your fingers for the audit 3dm … …

Schermata 2015-11-17 alle 12.26.04.png399×674 95.5 KB

9

OK, that means that somehow there are materials assigned to your objects, which is why you can’t delete them…

You can try running the following to get rid of the materials - do this on a copy of the file !!

RemoveAllMaterials.py (480 Bytes)

–Mitch

10

Forgive Mitch. How do I exactly?
Edit: It worked.

Summary of the audit:
Calculation tables:
97 levels
2 dimstyles
3 font
2 types of line
** 1 render materials**
Calculation items:
11192 normal objects
0 locked objects
0 hidden objects
1574 dropped objects (in the undo buffer)
0 items framing block
0 items normal reference
0 objects reference blocked
0 objects hidden reference
0 items framing block reference
No error.

11

Now lunch … … then write here any updates. Thank you Mitch. Anyhow.

12

OK, I hope that helps something… If the slowdowns during autosave stop, then that was it… Otherwise, no idea.

–Mitch

13

Just tried. Lock Rhino remained. The only difference now is no longer the rainbow ball. :expressionless:

14

Oh well… sorry. There must be something it’s having trouble saving… :confounded: – Mitch

15

:weary: Unfortunately back the suspicion of something wrong with the driver 3d connexion and Wacom

16

The time an autosave takes is directly related to the size of the file. What is the size of your 3DM file before all the materials were removed? What is the size of the file after the materials were removed?

17

The file had a size of 211.4mb. After removal of materials and about 700 objects, the size is 199.8 mb. Items removed had a size of 10.1MB. the size occupied by materials (lines and points) was then very small (2 MB)

18

200 Mb is not tiny, but it’s not gigantic either these days. In your computer specs above, there is not a description of your HDD - might you have a slow disc? You’re also on 10.9.5, which I guess is not all that great. Here on a more or less standard HDD (Windows), it takes about 3 seconds to save a 200 Mb file.

However, quoting from Auto Save and Versions in macOS (autosave) [McNeel Wiki] :

The periodic autosaves run in the background. You will never know when a
background autosave is happening because it never blocks Rhino from
working. If you start changing your model while Rhino is performing an
autosave, Rhino silently abandons the autosave and will attempt it again
later.

So, @marlin - it shouldn’t be doing this, no? Or is the info above incorrect?

–Mitch

19

I have a fusion drive to 1TB.
They are not able to determine whether when saving the file on ssd is moved to HHD (7200rpm)

20

I propose to do the following. If my idea is wrong stop me. Since the behavior of the fusion drive is not predictable, I try to install Rhino on Yosemite and El Capitan on external SSD with USB 3.0 see if anything changes. Look a your ok for testing (because if you think it relevant not waste time).

Simon