Rhino 7 7.16 update on macOS has broken grasshopper

Hello good people of the internet,

After downloading the most recent version of Rhino 7 (7.16, March 2022) my grasshopper files will no longer load. In particular, I use some modules in the Pancake add-on to load .obj files into rhino and perform mesh operations. I bring up the pancake module because my grasshopper file will load as long as the module is not trying to input a .obj file. If it is trying to input a file (which was done without issue for months prior to most recent update), grasshopper will not load the algorithm at all, though it will eventually output the proper files (which is even more head scratching). If there is no direct fix, is there any way to revert my rhino 7 back to the version before the latest update? I’m grateful for any help you fine folks give! I’ve attached my system info if that helps.

System Info:
Rhino 7 SR16 2022-3-8 (Rhino 7, 7.16.22067.13002
License type: Commercial, build 2022-03-08
License details: Cloud Zoo

Apple macOS Version 12.2.1 (Build 21D62) (Physical RAM: 64Gb)
Rhino is running in Rosetta2 on Apple Silicon
Mac Model Identifier: MacBookPro18,2
Language: en-US (MacOS default)

Apple M1 Max (OpenGL ver:4.1 Metal - 76.3)

OpenGL Settings
Safe mode: Off
Use accelerated hardware modes: On
Redraw scene when viewports are exposed: On

Anti-alias mode: 4x
Mip Map Filtering: Linear
Anisotropic Filtering Mode: High

Vendor Name: Apple
Render version: 4.1
Shading Language: 4.10
Maximum Texture size: 16384 x 16384
Z-Buffer depth: n/a
Maximum Viewport size: 16384 x 16384
Total Video Memory: 48 GB
Graphics: Apple M1 Max
Displays: Unknown (255dpi 2x)

Graphics processors
Apple M1 Max
Color LCD (1728 x 1117 @ 120.00Hz)

USB devices
None

Bluetooth devices
None

Third party kernel extensions
None

Third party plugins
/usr/lib/swift/libswiftCloudKit.dylib
/usr/lib/swift/libswiftCore.dylib
/usr/lib/swift/libswiftCoreData.dylib
/usr/lib/swift/libswiftCoreFoundation.dylib
/usr/lib/swift/libswiftCoreGraphics.dylib
/usr/lib/swift/libswiftCoreLocation.dylib
/usr/lib/swift/libswiftDarwin.dylib
/usr/lib/swift/libswiftDispatch.dylib
/usr/lib/swift/libswiftFoundation.dylib
/usr/lib/swift/libswiftIOKit.dylib
/usr/lib/swift/libswiftObjectiveC.dylib
/usr/lib/swift/libswiftXPC.dylib
/usr/lib/swift/libswiftos.dylib
/usr/lib/swift/libswift_Concurrency.dylib
/usr/lib/swift/libswiftAppKit.dylib
/usr/lib/swift/libswiftCoreImage.dylib
/usr/lib/swift/libswiftMetal.dylib
/usr/lib/swift/libswiftQuartzCore.dylib
/usr/lib/swift/libswiftCryptoTokenKit.dylib
/usr/lib/swift/libswiftAccelerate.dylib
/usr/lib/swift/libswiftContacts.dylib
/usr/lib/swift/libswiftCoreAudio.dylib
/usr/lib/swift/libswiftCoreML.dylib
/usr/lib/swift/libswiftCoreMedia.dylib
/usr/lib/swift/libswiftOSLog.dylib
/usr/lib/swift/libswiftVision.dylib
/usr/lib/swift/libswiftsimd.dylib
/usr/lib/swift/libswiftNetwork.dylib
/usr/lib/swift/libswiftDemangle.dylib
/usr/lib/swift/libswiftFileProvider.dylib
/usr/lib/swift/libswiftIntents.dylib
/usr/lib/swift/libswiftPrivate_BiomePubSub.dylib
/usr/lib/swift/libswiftPrivate_BiomeStreams.dylib
/usr/lib/swift/libswiftUniformTypeIdentifiers.dylib
/usr/lib/swift/libswiftAVFoundation.dylib
/usr/lib/swift/libswiftCoreMIDI.dylib
/usr/lib/log/liblog_network.dylib

Rhino plugins that do not ship with Rhino

Rhino plugins that ship with Rhino
/Applications/Rhino 7.app/Contents/PlugIns/PanelingTools.rhp “PanelingTools” 7.16.22067.1002
/Applications/Rhino 7.app/Contents/Frameworks/RhCore.framework/Resources/ManagedPlugIns/GrasshopperPlugin.rhp “Grasshopper” 7.16.22067.13002
/Applications/Rhino 7.app/Contents/PlugIns/import_IGES.rhp “IGES Import Plug-in” 7.16.22067.1002
/Applications/Rhino 7.app/Contents/PlugIns/Displacement.rhp “Displacement” 7.16.22067.1002
/Applications/Rhino 7.app/Contents/Frameworks/RhMaterialEditor.framework “Renderer Development Kit” 7.16.22067.1002
/Applications/Rhino 7.app/Contents/Frameworks/RhCore.framework/Resources/ManagedPlugIns/Import_OBJ.rhp “Import_OBJ” 7.16.22067.13002
/Applications/Rhino 7.app/Contents/Frameworks/RhCore.framework/Resources/ManagedPlugIns/RhinoDLR_Python.rhp “IronPython” 7.16.22067.13002
/Applications/Rhino 7.app/Contents/PlugIns/NamedSnapshots.rhp “Snapshots” 7.16.22067.1002
/Applications/Rhino 7.app/Contents/Frameworks/RhCore.framework/Resources/ManagedPlugIns/Commands.rhp “Commands” 7.16.22067.13002
/Applications/Rhino 7.app/Contents/Frameworks/RhCore.framework/Resources/ManagedPlugIns/RhinoRenderCycles.rhp “Rhino Render” 7.16.22067.13002
/Applications/Rhino 7.app/Contents/Frameworks/RhCore.framework/Resources/ManagedPlugIns/RDK_EtoUI.rhp “RDK_EtoUI” 7.16.22067.13002
/Applications/Rhino 7.app/Contents/PlugIns/RhinoRender.rhp “Legacy Rhino Render” 7.16.22067.1002
/Applications/Rhino 7.app/Contents/Frameworks/RhCore.framework/Resources/ManagedPlugIns/RhinoCycles.rhp “RhinoCycles” 7.16.22067.13002

There’s a known bug when Pancake tries to load something from a SMB server (network location) on macos, with file sync enabled.

If so, you can lock the solver before opening the file and remove the file sync first.

Thank you so much for explaining the problem to me! The synchronization was indeed broken. Is there an alternative add-on that performs the same function without the bug in pancake?

:stuck_out_tongue_winking_eye: I am the author of Pancake.

You may try Import 3DM from the vanilla Grasshopper (it also imports other formats). But the file sync bug is from the Grasshopper side so I believe as long as you have that enabled, Grasshopper will be stuck. I just told my friends to disable file sync on macos. (btw older versions of Pancake have that enabled by default, while newer versions have disabled it)

Thank you again for the response and thank you for your contributions to pancake! I tried using params on vanilla grasshopper and the sync is broken there as well, which I guess makes sense as the problem is on the grasshopper side. Is there any way to contact someone about the bug in vanilla grasshopper?

I notified @DavidRutten about the issue months ago.

I believe he cannot replicate the issue because he doesn’t have a macos-based file server, which is necessary for the bug to occur. But anyway it’s up to Grasshopper itself.

Yes. Before I start to investigate this, here is a link to Rhino 7 for Mac (7.15) - bugs and all (notably a major display bug on Apple Silicon machines). Hopefully, while we figure this out, that will get you running again. Keep in mind, it is possible to have two versions of Rhino for Mac installed at the same time on the same machine (just not running simultaneously). Simply rename the application bundle from Rhino 7.app to Rhino 7_15.app.

Reading through this topic, I’m unsure if there is something we need to fix on our end or not. The post implies that this bug started happening with updating from Rhino 7.15 to 7.16 (regressions are not uncommon). If so, we’ll need some hand-holding here to reproduce the steps on our machines.

Thanks so much for the help, Dan! Having the old version of Rhino will be helpful until the issue is fixed, I appreciate your time!

1 Like

Happy to help fill in any gaps as needed

Hi Eric -

The first step would be a confirmation that reverting to 7.15 does, in fact, solve the issue for you.
-wim

1 Like

I will be back to my office in an hour and will revert to the old version and update ASAP. Thanks!

I reverted back to Rhino to 7.15 and now all the modules work as intended. If it helps to diagnose the problem, whenever I use Params or pancake to input a file, it is retrieving the file from google drive. If you need anything else from me please don’t hesitate to reach out. Thanks!

I used to profile a similar issue. It seems something happens when the file is hosted on a special mac location (in my case a macos SMB server, maybe this time Google Drive is ‘special’ too), regardless of whether it’s accessed by mac or windows. If file sync is enabled, GH’s FileWatcher class receives continous notification of file changes (although it’s not changed at all), therefore depleting system resources.

Maybe it’s related to the issue here.