Rhino blocks it just me? Help me understand

I see that now. v5.2 is indeed the current WIP. Sorry, thought you were using the commercial version and I was behind a version.

I wouldn’t be surprised if the fusion drive turns out to be a large part (if not the root) of your problem. While I understand the reasoning behind these devices from the manufacturers’ point of view (economy), I’m suspicious of the benefits for large files which use auto-save versioning. A quick search to turn auto-save off did not reveal any easy methods. Perhaps others know of a method either system-wide or for Rhino alone. If you can turn it off, then you could at least test this theory.

As a side note, after using an SSD for the past two years, I hope to never rely on a spinner again. My machine is now blazing fast in ways I never imagined—including bootcamp into Windows in something like 20 seconds. Well worth the high price tag!

[EDIT: I see Marlin’s response above. Looking forward to his insights when he gets back in the saddle.]

~Dave

Ok. Thank you

An Auto Save in Rhino for Mac happens in three phases.

The first phase is initiated by the Apple frameworks. Some time after a Rhino model has been changed, the Apple frameworks decide it is time to start an Auto Save. The Apple frameworks initiate an Auto Save when you switch to another application. It will also initiate an Auto Save when enough time has passed (this seems to be about five minutes) and the program seems idle, i.e., no recent mouse movement or typing. If you constantly move the mouse, an Auto Save will never start. When the Apple framework initiates this first phase, it asks Rhino if it is OK to Auto Save at that moment. If Rhino is in the middle of a command, Rhino will refuse the Auto Save, and the Auto Save operation is abandoned. If Rhino says it is OK to Auto Save, then the second phase is initiated.

In the second phase of an Auto Save, the user interface is locked and the Rhino model is saved to an in-memory buffer. No disk activity occurs – this is an entirely in-memory operation. This creates a special copy of the 3DM model. No render meshes are written to the in memory buffer, which saves considerable space and time in creating the Auto Save version of the model. When the in-memory copy is finished, the user interface is unlocked and Auto Save proceeds to phase three. Note that the user interface is locked during this phase to prevent you from changing the Rhino model while it is being copied.

In phase three, the in-memory buffer is passed to a background thread that then writes the in-memory buffer to disk. Because this is running in a background thread, it can take as long as necessary and it will not block Rhino from running.

These three separate phases allow you to have your model on a very slow disk that is Mac file system compatible (HFS+), and you will not experience any Auto Save slowdowns. For example, Rhino files on Mac compatible network drives work fine with Auto Save. I have formatted a thumb drive as HFS+ and put 3DM models on the thumb drive. Rhino will perform Auto Saves to the thumb drive and I was not blocked at all when Auto Save runs. I could also see that writing the 3DM file took perhaps 10 seconds to complete, but this happened on a background thread and did not keep me from modeling in Rhino while that happened.

I tried duplicating the issues described in this thread. In a new model I created an array of 25 x 25 x 25 spheres. This is 15,625 objects. Each sphere takes 1152 polygons to mesh. (I wanted this to be a torture test.) I assigned a material to about a third of them to imitate the problematic model described above.

When I save this model using the normal File > Save, the 3DM file is about 465 MB and takes more than two minutes to save. Almost all of that time is spent compressing the meshes.

When Auto Save runs, no meshes are saved. The 3DM file that is saved is about 50 MB, and phase two of the Auto Save (when the user interface is locked) takes 0.7 seconds. If I removed all the material assignments in this model, I saved about 0.01 second in the Auto Save. The number of materials do not seem to be a factor.

I did discover one inefficiency in the Auto Save. The preview image is saved in the Auto Save version and is compressed. That compression operation added a full second to the second phase, more than doubling the time the user interface is locked. This will be fixed in the next WIP release.

These tests were run on OS X 10.10.5.

I am unable to duplicate long pauses while Auto Save is happening. Perhaps there is something else in Zsimon’s model that is causing a slowdown. I’ll need to get a copy of that specific model to duplicate it. Go to the McNeel File Upload web page. Enter your information and use marlin@mcneel.com as the recipient address at McNeel, and I can try duplicating this issue.

1 Like

All very clear. I can not send my model but because I want to get rid of my problem I can create a test model, reproduce the problem, and then send it.

Inspired by your test, I created a model with a number of spheres 20x20x20, or saved the template, then I copied some balls. Finally I moved all the time with the Mouse 3D connexion doing orbit. After about five minutes, while I was doing the orbit, Rhino crashed for about 12 seconds, the preview image of the file on the file has been updated and everything is working again.
In Italy it’s late now. time to sleep for me. I hope to get some solution. Thank you for your time.

I cannot duplicate this. When you say “crashed”, I assume you mean the Rhino paused, but I still cannot duplicate this.

A 20 x 20 x 20 sphere array is a mesh and file size torture test and not appropriate for a 3DConnexion test. The redraw frame rate for this large array is just a few frames per second on my computers.

To test 3DConnexion and Auto Save during 3DConnexion activity, I created a 5 x 5 x 5 sphere array and saved the model. I deleted one sphere (to change the model) and then leaned a weight against the 3DConnexion device. I let Rhino run overnight. After 10 hours, the model was still rotating and Rhino had never Auto Saved the model. I took the weight off the 3DConnexion device and the model was Auto Saved after about 30 seconds.

If you perform this test, be sure to set your screen saver delay to Never and set Display Sleep to Never. If the screen saver activates, then this will put Rhino in the background and then an Auto Save will occur.

I think at this point you need to experiment with either another Macintosh, or create another OS X partition and install a fresh copy of OS X on the new partition. It seems at this point there is something with your particular computer environment that is part of the problem, because no one else can duplicate the behavior you are describing.

I see. I will evaluate in the next 2-3 days to make an updated clean El Capitan (by Maverick). It is a huge risk for my operation. I just hope this eliminates the problem.

Thank you Marlin

Simon

I do not think this is a Mavericks vs. El Capitan issue. The computer where Rhino ran overnight with the weight leaning against the 3DConnexion device was running 10.9.5.

If you do not have disk space on your current computer to create a second partition, buy a fast external disk and install a fresh copy of 10.9.5 there.

Yes, but if I have to do a clean install of 10.9.5, you might as well go to El Capitan. I had made a request that I repeat here. I Yosemite installed on SSD external (USB 3.0). Rhino could install them and see what happens. Any idea?

I’m not sure I understand your question. Are you asking if installing Yosemite and Rhino on a external SSD will work? I think it should.

The behavior you describe was fixed in Rhino 5.1 and Rhino 5.2 WIP. It existed in 5.0.2 and earlier. Are you sure that you do not have old copies of Rhino still on your computer? Use the procedure described here to delete all copies of Rhino and then install only the latest version.

Yes, I still have the penultimate version of Rhino Wip installed, and last 2 trading. In the past I have learned not to delete them in order to use them in case of serious bugs of the latest versions. Now obviously this is no longer necessary and could perhaps be one of the problems. I read the article for the procedure but I have a doubt. I have to uninstall all copies of Rhino (including 5.1 and 5.2 WIP) and then reinstall? I have to save your settings before?

Rhino WIP 5C83w.
@marlin Update: After installing the version 5C83w unfortunately, I did not notice any difference using the SpaceMouse Pro 3D Connexion. When does the autosave, Rhino stops for about 3-5 seconds. Instead of working with the entire file, select and export parts to reduce the size of the model. This reduces the time of the block, but does not solve the problem.
I installed the latest version WIP, overwriting the previous. The version 5B161 is installed as well.

Update. From now use Rhinoceros with El Capitan (SSD external). No difference with regard to the blocks during momentary auto-saving. I only noticed once again that using the “Export selection” and working with small parts of the model, the blocks can be seen much less or even not noticed at all. I remember using one SpaceMouse Pro and Wacom tablet on Rhinoceros.

Auto Saves are not always instantaneous. They can take, in worst cases, a few seconds. Usually the pauses are a fraction of a second, but depending on the model, can take longer.

We have not been able to get models from you that show your long Auto Save time. You did send us a sample model. This sample model takes two seconds to Auto Save. That sample model contains 30 bitmaps that take a total of 100 MB of memory. It appears only one of those bitmaps is actually used in the sample file. These 30 bitmaps must be compressed when written to the Auto Save file, and doing that compression takes one second each time an Auto Save is performed.

I selected all the geometry in your sample file, then copied and pasted the geometry into a new file. An Auto Save for this new file takes less than a second.

You might inspect the bitmaps in your models. You can see the bitmaps included in a model by using the TestListTables command. This is a test command and will not autocomplete. It will list the original path for each bitmap that is embedded in your model.

Autosaves happen when the computer is idle for at least 20 seconds, so to even see a pause due to an Auto Save, you have to perfectly time your computer interaction to match this delay. You must start using the computer again after waiting between 20 and 22 seconds. Wait any less than this, and an Auto Save won’t happen. Wait any more than this, and the Auto Save is already completed. There was a problem earlier when using only a 3DConnexion device. Previously, the delay before an Auto Save was only 2 seconds when using just a 3DConnexion device, but is now fixed in the 5C83w WIP release.

Bitman is that of good information. I would like to do this test, remove all bitman model. How do I proceed?

Here’s what I did. Select all the geometry in your model, copy it, and paste the geometry into a new template file. Make sure you choose a template that matches the units that you are currently using.

@pascal may have other suggestions for removing orphaned bitmaps in a 3DM model.

I did as you wrote. The complete model, using the command “TestListTables” were 42 bitman (all high resolution …) After copying and pasting into a new file, no longer bitman.
The file size dropped from 284 to 182 mb.

testPurgeBitmapTable may help - but it gets ALL bitmaps in the table - it does not ask any questions, so beware…

( This is a test command and will not autocomplete, “use at your own risk”)

-Pascal

WIP 5C249w
I continue to have big problems of slowing down. Each time it is performed automatically save, Rhino crashes for about 7-10 seconds. If the save is done while I’m doing the orbit with 3D mouse connection, after saving the object moves with the speed in the direction that I was following orbit.
Note that when you save, I can still move the cursor using the mouse (wacom in my case). Right now I’m working with a file that contains the following parts.

Summary of the audit:
Schedule tables:
43 levels
2 dimension styles
3 fonts
5 types of line
118 render materials
Calculation objects:
231 normal objects
3 locked objects
1445 hidden objects
583 deleted objects (in the undo buffer)
0 objects definition block
0 normal reference objects
0 reference objects blocked
0 reference objects hidden
0 items framing reference block
No error.

Please upload your model using this link http://www.rhino3d.com/upload so we can see what is in your model that is causing the delay. Thank you.