Computer seemingly corrupting file. Selection issue?

We’ve got a computer in the office that seems to be corrupting rhino files. There is no pop up or warning of corruption but we’ve identified that the file works fine until this specific computer opens the file. It then acts similarly when others open the file that the corrupting computer has saved.

Operations that don’t work include:
-Many commands where the selection happens after the command is entered.
Such as Area - then Select.
Hide then select. etc. (problem does not seem to exist when the selection is made first and then the command is run. Only when the command is run and it asks for a selection)

The selections eventually work they just take 10 mins or more every time. We tested the same file before this computer opens it on a different computer and all of these commands work instantly. As soon as the bad computer saves it however, everyone then has the same problems with that file.

The computer creating bad files is running windows 10 however we think it had been doing this before windows 10.

The latest Rhino (Version 5 SR14 64-bit) has been reinstalled multiple times on the computer with no change.

Anyone run into anything similar?

Would it be possible to post a sample of a file which works before being saved by the “bad” machine, and the exact same file that has stopped working correctly after it has been saved by the “bad” machine? It might then be possible to audit the files and see what the difference is (if any).

Just an idea… --Mitch

Yes definitely.
I created the file on a working computer. Then duplicated it and opened it on the bad computer and saved.

No Bueno.3dm (18.8 MB)
Bueno.3dm (18.8 MB)

Hello - one thing I notice is that NoBueno has Flux user data and Bueno does not… Not a lot or anything, I just notice the difference.

 Model User Data Table:
    user table[0]: (3583 bytes)
      Plug-in name: Renderer Development Kit
      Plug-in id: 16592D58-4A2F-401d-BF5E-3B87741C1B1B
    user table[1]: (497 bytes)
      Plug-in name: Rhino Render
      Plug-in id: 5DC0192D-73DC-44f5-9141-8E72542E792D
    user table[2]: (4 bytes)
      Plug-in name: Flux.Rhino
      Plug-in id: 8BE43FA8-460F-4b0b-905C-673AFB9F9D24
    3 user tables, 4387 bytes (offset 19739347 to 19743734)


1 Like

We were chatting with the Rhino support and he also mentioned it may have to do with plugins that do not ship with Rhino.

What’s still confusing though is that the flux plugin is also installed on the computer that created the Bueno file.

Hello - I guess the test would be to block Flux and run through the process again…
Any different? Does Flux do some checking on line or something that might take time etc? It may not be Flux of course, it just is the one difference I see.
Perhaps best, since we suspect a plug-in is involved, to go through the whole process of blocking all non-default plug-ins and re-enabling one at a time until you see the problem.


We’ve identified the problem to be the “loaded” flux rhino plugin. When loaded, commands such as invert, flip, delete and hide take a very long time to complete. Also any command that requires a selection after the command is started. Saving the file with the plugin loaded creates a bad file where other computers also have the same issue with the file. Reopening the file with the plugin unloaded, the file can be resaved to work fine.

Thanks all for the help. I’ve notified Flux if they respond I’ll link it to here.

Great, thanks for letting us know.