Hi,
I’ve noticed a super annoying bug in the latest version of Rhino 6 for Mac (6.20.19323.01022, 2019-11-19), where switching to a raytraced view and then back to another one makes Rhino crash!
Please fix this!
Thanks.
This is not a general problem.
I can’t duplicate the issue.
Does this happen only in a specific file for you or all files?
If you start a new file, draw a sphere, go into Raytraced and then into something else like Shaded.
Does that crash?
In general, I’ve noticed that the view change from Raytraced to another view (i.e. Ghosted) takes way too long! The beachball spins at least for 2 to 3 seconds and then a coin seems to get flipped. At heads the switch happens, at tales Rhino crashes, or vis versa!?
The crash seems to get favoured when dealing with Grasshopper geometry that doesn’t exist in Rhino (?).
I don’t know how else to describe this! I’ve encountered this bug numerous times in the last couple of weeks with different files. What is even weirder is that the performance of the view switch is sometimes better for bigger files and laggier for very simple files (i.e. sphere).
Please run the Rhino SystemInfo command and post the results.
Maybe something will stand out.
Here you go:
Rhino 6 SR20 2019-11-19 (Public Build, 6.20.19323.01022, Git hash:master @ f60ce76e397bba419469ae5277fc1578641caa3a)
License type: Educational, build 2019-11-19
License details: Stand-AloneApple Intel 64-bit macOS Version 10.14.6 (Build 18G2022) (Physical RAM: 16Gb)
Mac Model Identifier: MacBookPro13,3
Machine name: XXXX’s MacBook Pro
Language: en-LU (MacOS default)AMD Radeon Pro 460 OpenGL Engine (OpenGL ver:4.1 ATI-2.11.21)
OpenGL Settings
Safe mode: Off
Use accelerated hardware modes: On
Redraw scene when viewports are exposed: OnAnti-alias mode: 4x
Mip Map Filtering: Linear
Anisotropic Filtering Mode: HeightVendor Name: ATI Technologies Inc.
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: 4 GB
Graphics: AMD Radeon Pro 460
Displays: Thunderbolt Display (109dpi 1x)Graphics processors
Intel HD Graphics 530 (1536 MB)
AMD Radeon Pro 460 (4 GB)
Thunderbolt Display (2560 x 1440)USB devices
Apple Inc.: USB-C Digital AV Multiport Adapter
Apple Inc.: iBridge
Apple Inc.: USB3.0 Hub
LaCie: Rugged USB-C
Apple Inc.: FaceTime HD Camera (Display)
Apple Inc.: Apple Thunderbolt Display
Apple, Inc: Apple Keyboard
Apple Inc.: Display AudioBluetooth devices
Unknown:Third party kernel extensions
NoneThird party plugins
/usr/lib/log/liblog_network.dylibRhino plugins
/Applications/Rhinoceros.app/Contents/PlugIns/PanelingTools.rhp “PanelingTools” 6.20.19323.1002
/Applications/Rhinoceros.app/Contents/Frameworks/RhCore.framework/Resources/ManagedPlugIns/GrasshopperPlugin.rhp “Grasshopper” 6.20.19323.1022
/Applications/Rhinoceros.app/Contents/Frameworks/RhCore.framework/Resources/ManagedPlugIns/RhinoDLR_Python.rhp “IronPython” 6.20.19323.1022
/Applications/Rhinoceros.app/Contents/Frameworks/RhCore.framework/Resources/ManagedPlugIns/Commands.rhp “Commands” 6.20.19323.1022
/Applications/Rhinoceros.app/Contents/PlugIns/NamedSnapshots.rhp “Snapshots” 6.20.19323.1002
/Applications/Rhinoceros.app/Contents/Frameworks/RhCore.framework/Resources/ManagedPlugIns/RDK_EtoUI.rhp “RDK_EtoUI” 6.20.19323.1022
/Applications/Rhinoceros.app/Contents/PlugIns/Displacement.rhp “Displacement” 6.20.19323.1002
/Applications/Rhinoceros.app/Contents/Frameworks/RhMaterialEditor.framework “Renderer Development Kit” 6.20.19323.1002
/Applications/Rhinoceros.app/Contents/PlugIns/RhinoRender.rhp “Rhino Render” 6.20.19323.1002
/Applications/Rhinoceros.app/Contents/Frameworks/RhCore.framework/Resources/ManagedPlugIns/RhinoCycles.rhp “RhinoCycles” 6.20.19323.1022
Thanks!
I don’t see any obvious problems there.
We have added some additional fixes for SR21.
It’s the Service Release Candidate now.
If it were me, I’d try it and see if it helps.
In the Rhinoceros pull-down, choose Preferences.
Go into the General tool.
Towards the bottom, change the Update frequency to Service Release Candidate and click Check Now.
Download the SRC and install it, replacing your current SR20.
See if that works better.
OK, thanks John! I’m familiar with the Service Release Candidate option. I’ve used it in the recent past, but turned it off, since I rely on a more or less stable Rhino.
I agree, I would not normally leave SRCs turned on.
If this fixes the problem, please let us know.
Then I’d switch back to SRs.
OK, will do!
Back to report that the issue still persists in Version 6 (6.26.20147.06482, 2020-05-26)!
I really can’t believe that nobody else has encountered this!!
Might it have something to do with Grasshopper displaying the scene objects and Rhino being empty? Or even the Custom Preview component?
To be totally frank, this makes Raytraced mode unusable on macOS!
Here’s a video of the behaviour! I switch from Ghosted to Raytraced, and later back to Rendered and Rhino crashes as expected.
Starting at 00:13, the cursor turns into the spinning beachball, which QuickTime failed to capture. On macOS, the beachball is usually an indicator that an application has crashed.
I hope this is prove enough!
You can grab the Grasshopper file here. There is no Rhino file to speak of, just an empty document in mm (small scale).
You seem to miss the point.
You don’t need you to “prove” there is a problem. We believe you!
What we need help with is Repeating the problem here.
We need all of the files and specific details so we can duplicate the problem here.
Then we can figure out what is causing it and hopefully fix it.
As mentioned above there was only a blank Rhino document (mm, small scale) and I’ve linked to the Grasshopper file. Details are provided in the video as well as description! My system information is also already in this thread. There was no error report.
this bug is in there since forever, it still happens and drives me nuts, happened in v7 and happens in v8. when you render something in cycles, and cycles stalls the cycle count which also happens often (and is a bug on its on i guess) then switching to shaded kills rhino 100% of the time. though i noticed a tendency when i save quickly while cylcles has stalled i have often a chance that rhino does not quit. but without saving it quits always. nobody ever reproduced that? can not be, i had this problem happening on 3 different computers. one was an intel still and two were m1. i sent in many many bugreports when this happened.
also i think this belongs under the rendering tag .
I have seen this on my M1 as well, but not on my M2 Max. This is an error in the Metal driver code from Apple. At some point it fails to run the Metal kernel. This crash is deep in Metal and outside of our control. I have passed this issue on to them already end of last year, and as of yet no ways to fix this. This happens especially when using Rhino procedural materials, it appears to be a double-whammy for the Metal driver where the display code creates a version (the OpenGL variant but for Metal), and then Metal is used by the Raytraced or Rhino Render.
Currently the only way I know to reliably sidestep that is by using the CPU for Raytraced and Rhino Render.
The bug is logged as [RH-78648](https://mcneel.myjetbrains.com/youtrack/issue/RH-78648) Crash after internal Metal error (but closed to public due for reasons). My latest fix attempt was Close command encoder buffers on error. · mcneel/cycles@d88ee2a · GitHub but that clearly didn’t work.
ok Nathan i already hate Apple so much already, dont make me buy a pc 
i played now switching to cpu, that is quite a bit slower, but not soo much slower as i expected, is cycles for Metal not fully optimized yet? also… would there be a way to make your own Rhino version of metal or is that just too astronomical to even think about?
It is as optimized as Blender 3.5 was at the time.
Metal is an Apple technology we get to use, not something we can replace.
but, would there not be a way to utilize vulcan or whatever that was named? i am not so much into computer science i just pick up what i find on the way so sorry if those questions are noobish
I don’t think Vulkan is directly supported on Metal. At most there would be a Vulkan implementation that gets translated to Metal, I believe via MoltenVK.
But no, adding a new API in and of itself will not solve the problem on the Mac, since it ultimately will go through Metal. And would just take yet again lots of time and resources to do.
ic… well that dream melted fast then… thanks Nathan you made my day. will go and hang myself then.