Disappearing icons in Grasshopper - 5.4.2

Since upgrading to the latest Rhino 5.4.2 for Mac, Grasshopper icons are disappearing for all components besides the built in ones.

This happens after a delay of 10-15 minutes after startup. Components already on the canvas retain their icon but newly copied/created ones or newly opened files all get blank icons on plugin components.


I tried removing all traces of external plugins from the Libraries and UserObjects folders, but the problem still occurs with GHpython (which seems to be the only built-in component affected). Also tried toggling the COFF loading settings and rebooting, but no luck.

Any idea what may be causing this?

Unfortunately, I’m not seeing this behavior on my machine.

Are you able to reproduce this with 5.4.1? I’d like to ascertain first if this is a regression from 5.4.1 to 5.4.2.

I’d love to hear from anyone else who is seeing this (or unseeing, I guess).

I had something like this happen once or twice on 5.4.1, but only very rarely and after GH had been running in the backgroud continuously for many hours/days. Now it happens very consistently a short while after startup, which is why I thought it was linked to the update somehow.

How do I get 5.4.1 version back? The Rhino website doesn’t let me download an old version. And honestly it’s not such a big deal in exchange for reduced number of crashes, I might just try doing a clean reinstall if it comes to that.

I’d be curious to hear whether or not it is a regression between 5.4.1 and 5.4.2. Please test out 5.4.1 and see if you can consistently repeat the behavior.

Thanks again for reporting it. Certainly odd behavior.

Okay weird, now I’m getting the same behaviour in 5.4.1 with external plugins, although for some reason the Ghpython component is not affected.
(btw the link above was to the wrong file)

Also unrelated but another GH Mac bug while I have your attention here :upside_down_face: Value List values (set by Python script) report being "None"

Whoops, sorry, fixed that link. Glad you figured it out and tested in 5.4.1. This is very odd behavior. Can you please provide some additional information? Navigate to Rhinoceros > About Rhinoceros > More info… > Copy to clipboard and paste the content back into a reply here.

If anyone else is seeing this behavior, please let us know.

unrelated but another GH Mac bug

I don’t want to cross the streams, so to speak :wink:

Hi Dan, here are my system details:

Software information

Software versions
Rhinoceros version: 5.4.2 (5E411)
Rhinoceros path: /Applications/Rhinoceros.app
IronPython version: 5.1.2015.131
Language: en-SG (MacOS default)
macOS version: Version 10.13.4 (Build 17E202)


Third party kernel extensions
com.displaylink.driver.DisplayLinkDriver (4.0.0 (85514)) 5A240BCF-1B8D-3A9E-B21B-B12D639AC9D9
com.3dconnexion.driver (10.5.2) 23F2462E-B272-3BBC-A8DC-BEE242EE3FA7
com.intel.kext.intelhaxm (6.0.1) 8FF2C637-0A5E-367E-B007-5B08655B1E8A
ch.tripmode.TripModeNKE (2.0.0) D637B8E3-E64B-3C60-9D43-87F8583B05AC
com.kensington.trackballworks.driver (1.3.0) 598CF9DF-CC79-34D9-B2DA-C63E7516FD0A

Hardware information

Computer hardware
Hardware model: MacBookPro9,1
Processor: Intel Core i7-3820QM CPU @ 2.70GHz
Memory: 16 GB
Architecture: Intel 64 bit

Video hardware
Graphics: NVIDIA GeForce GT 650M 1024 MB
Memory: 1024 MB
Screen size: 1680 x 1050, 1200 x 1920
Displays: Color LCD (129dpi 1x), DELL U2410 (94dpi 1x)

USB devices
Apple Inc.: FaceTime HD Camera (Built-in)
Apple Inc.: Apple Internal Keyboard / Trackpad
Apple Computer, Inc.: IR Receiver
Apple Inc.: Bluetooth USB Host Controller

Bluetooth devices

OpenGL information

OpenGL software
OpenGL version: 2.1 NVIDIA-10.30.25 355.
Render version: 2.1
Shading language: 1.20
Maximum texture size: 16384 x 16384
Z-buffer depth: 24 bits
Maximum viewport size: 16384 x 16384

Implementation settings
Use texture compression: No

Appearance settings
Antialiasing: 2x
Mip map filtering: None
Anisotropic filtering: Low

Although I have a sneaking feeling that this one might be due to poking around in system files, including looking inside the Rhinoceros.app bundle. ( pretty sure I didn’t modify anything there )

Might this somehow be related to the Mono framework? I recently installed several C# and F# development plugins along with a new editor, and it looks like the folder
was updated in the last few weeks, although I can’t be sure if it was by the 5.4.2 update or something else.
Here’s what I get from the terminal running mono --version

~$ mono --version
Mono JIT compiler version (2017-12/8eb8f7d5e74 Fri Apr 13 20:18:12 EDT 2018)
Copyright (C) 2002-2014 Novell, Inc, Xamarin Inc and Contributors. www.mono-project.com
	TLS:           normal
	SIGSEGV:       altstack
	Notification:  kqueue
	Architecture:  amd64
	Disabled:      none
	Misc:          softdebug
	Interpreter:   yes
	LLVM:          yes(3.6.0svn-mono-master/8b1520c8aae)
	GC:            sgen (concurrent by default)

It should not be. Rhino for Mac embeds its own version of Mono in the application bundle and does not use those installed in the system’s library.

Thanks for your system info.

It’s a stretch, but a couple of those kernel extensions are unfamiliar to me. You might try booting to macOS’s Safe Mode and see if the problem persists without those extensions loaded.

Please check out the Rhino 5 for Mac 5.5.3 update. We made some changes to how resource icons are loaded that may or may not improve this issue.

I am having the same issue in rhino 5 for mac 5.5.3. All native grasshopper components show up fine, but any plugins show up blank.

I can also confirm that the issue persists for certain components in Rhino 5.5.3, mainly for some Kangaroo2 components (@DanielPiker) and rather old third-party plugins.


45 55 05


06 16

My theory is that this bug is caused by ancient, yet miraculously macOS compatible components that stem from the Rhino Wind’ohs only area, and that probably have not been updated since.

Hi - do you get the same behavior on the Rhino 6 WIP?

@wim, doesn’t seem like it, although I don’t touch R6 WIP, unless I have to. It’s slow, buggy and not much of a worthwhile upgrade for me, since I’m after speed and reliability! Would be nice, if you could fix it in Rhino for Mac 5 as well.

I doubt we will be able to fix this in Rhino 5 for Mac, nor do I think we’ll be able to find all the situations where third-party developers are using ancient image assets and report those.

Could you please point me to the Discourse topics you have reported where it is too slow or buggy? I’m having trouble finding them with my Discourse search. We’d like to get those bugs fixed as we won’t be devoting any resources to Rhino 5 for Mac.

My intention was not to degrade Rhino 6 WIP for Mac. I understand that it’s still a work in progress, and hopeful that you will release a more polished, stable version as golden master.

Here’s a few things that I’ve noticed:

  • startup is far slower than Rhino 5 for Mac (loading the license on splash screen?)
  • when Grasshopper launches, its Window appears at the bottom left corner of the deskop, partially out of frame and has to be moved back into view
  • in Grasshopper, there’s a slight delay, when expanding the menus (to display all icons in a category)
  • the GHPython component is still not on par with the Windows version (no completion, no console, no compiling, etc.), it’s basically unusable for inexperienced users!
  • in Rhino, there is still no EditPythonScript
  • for me remapping the radial menu in Grasshopper to ALT + SPACE and totally removing it from the MMB is terrible (however we’ve already discussed this)
  • scrolling in and out of the GH canvas - even after the last update - is still not very fluent (compared to v.5)
  • sometimes there are weird graphic glitches where GH component wires get cut off (when they are twisted back?)
  • in general, when dealing with big files (lots of points, meshes) v.6 is more prone to crashing than v.5, also when running extensive GH scripts (that process a lot)
  • viewport rendering of GH scripts, manipulated with sliders in real-time or animated in some other way, is kinda laggy, even for a decent amount of geometries (e.g. 25 Nurbs boxes being rotated arounf their own axis), it’s not super bad, but not perfect either

For me, Rhino 5 for Mac runs much more stable, seems much more polished, and I’ve just come to terms with its shortcomings!
From some of the comments in other discussions, I get that even Rhino 6 for Windows isn’t that polished yet? Many of the hardcore users don’t seem to have upgraded yet?

1 Like

Thanks for this list. This is helpful. I recognize quite a few of these gripes and - as time passes - it is always good to get a reminder what are the pain-points still in the software (there are so many).

I didn’t take it that way :slight_smile: It’s just that Rhino 6 for Mac is the focus of our efforts and we need to know where we have regressed from 5.

I agree. We’ve discussed tuning this up. I still don’t know why using a stand-alone license is so much slower in Rhino 6 for Mac than Rhino 5 for Mac.

I’ve never seen or heard of this one. It would be good to get more specifics (in a separate topic if you have the time/inclination).

This will likely improve during the Rhino 6.x code-cycle. Agreed this is a pain-point, but it is already improving in recent builds. @alain has been giving this some attention lately.

And the Atom integration is not sufficient?

This is surprising to me. Can you provide definitions to compare?

Like this bug, for example?

These two should get tuned up over time, but any specifics you can provide would be helpful.

The reality is, we are getting close to shipping Rhino 6 for Mac, so it is disappointing to hear it won’t be a good fit for you. Hopefully we can address some of the above bugs in Service Releases.