Rhino 8 for Mac still feels like Beta software

barry1 · July 19, 2024, 2:17pm

I am so incredibly disappointed with McNeel for how they’ve rolled out Rhino 8 for Mac users.

I can’t speak to the Windows experience, but the Mac experience has been so frustrating.

The UI is laggy, the simplest commands are sometimes take a second or two (I’m not talking compilcated booleans, or grasshopper here, I’m talking using the Shift Key to get perpendicular line… ) it really feels almost like Alpha software, not iteration 8 of a product thousands rely on daily for commercial work.

I used the help command today because I couldn’t fathom how to adjust the UI (despite having a PhD in UI design), and resulting crash in Rhino resulted in me having to reboot my whole computer.

I’m all for new features, and I think releasing the software as Beta for existing customers as they do is a great idea… but the subsequent rollout of the product before it’s polished, with aggressive discounts for early adoption, and the infuriating default of saving every file in the newest format meaning it’s not easy to quickly switch back to 7 on new files, means you’re encouraging users to upgrade to a very poor experience with a ‘bear with us’ attitude, that, quite frankly stuns me.

I’m all for new features, but not at the expense of bugs, or basic functionality being infuriatingly laggy. It’s ruined my Rhino experience. Please have more engineers focused on getting 8 back to bug free, rather than committing them to whatever team is dreaming up the Rhino 9 features.

Japhy · July 19, 2024, 2:29pm

Hi Barry,

We hear you and are looking to improve your experience.

There are a few variables we should look at first, please run SystemInfo in your command line and post the results. Thanks

barry1 · July 19, 2024, 3:02pm

Hi,

Having dived into your forum a little more, I see other users with external monitors complaining of similar issues, so I suspect that might be at the root of the problem. I use two monitors.

Having used an external monitor for years, and never experiencing issues, it would never have occurred to me that this would cause problems. Especially given that I’d guess many if not most advanced/busy users of commercial software would use more than one monitor these days.

Disappointingly, your reply on other threads to others complaining of issues with external monitor problems, was that it’s not a high priority at present.

Anyway, SystemInfo is as follows:

Rhino 8 SR9 2024-7-12 (Rhino 8, 8.9.24194.18122, Git hash:master @ 785b9fde79bb684d22aab317998f7195a8c27c14)
License type: Commercial, build 2024-07-12
License details: Cloud Zoo

Apple macOS Version 14.5 (Build 23F79) (Physical RAM: 8GB)
Mac Model Identifier: iMac19,2
Language: en-GB (MacOS default)
.NET 7.0.0

Metal GPU Family Apple 0
Metal GPU Family Common 3
Metal GPU Family Mac 2
Graphics processors
Radeon Pro 560X (4 GB)
iMac (2048 x 1152)
LED Cinema Display (2560 x 1440)
GPU Vendor: AMD

USB devices
Apple Inc.: Apple LED Cinema Display
Apple Inc.: Display iSight
Apple Inc.: Display Audio
Apple Inc.: FaceTime HD Camera (Built-in)
3Dconnexion: SpaceNavigator

Bluetooth devices
None

Third party kernel extensions
None

Third party plugins
/usr/lib/swift/libswiftCore.dylib
/usr/lib/swift/libswiftCoreFoundation.dylib
/usr/lib/swift/libswiftCoreGraphics.dylib
/usr/lib/swift/libswiftCoreImage.dylib
/usr/lib/swift/libswiftDarwin.dylib
/usr/lib/swift/libswiftDispatch.dylib
/usr/lib/swift/libswiftIOKit.dylib
/usr/lib/swift/libswiftMetal.dylib
/usr/lib/swift/libswiftOSLog.dylib
/usr/lib/swift/libswiftObjectiveC.dylib
/usr/lib/swift/libswiftQuartzCore.dylib
/usr/lib/swift/libswiftUniformTypeIdentifiers.dylib
/usr/lib/swift/libswiftXPC.dylib
/usr/lib/swift/libswift_Concurrency.dylib
/usr/lib/swift/libswiftos.dylib
/usr/lib/swift/libswiftsimd.dylib
/usr/lib/swift/libswift_StringProcessing.dylib
/usr/lib/swift/libswift_RegexParser.dylib
/Library/Frameworks/3DconnexionClient.framework/Versions/A/3DconnexionClient
/usr/lib/swift/libswiftCryptoTokenKit.dylib
/usr/lib/usd/libusd_ms.dylib
/usr/lib/swift/libswiftCoreAudio.dylib
/usr/lib/swift/libswiftCoreLocation.dylib
/usr/lib/swift/libswiftCoreMedia.dylib
/usr/lib/swift/libswiftCompression.dylib
/usr/lib/swift/libswiftCoreMIDI.dylib
/usr/lib/swift/libswiftAVFoundation.dylib
/usr/lib/swift/libswiftCoreML.dylib
/usr/lib/swift/libswiftFileProvider.dylib
/usr/lib/swift/libswiftIntents.dylib
/usr/lib/swift/libswiftAccelerate.dylib
/usr/lib/swift/libswiftGLKit.dylib
/usr/lib/swift/libswiftGameplayKit.dylib
/usr/lib/swift/libswiftMetalKit.dylib
/usr/lib/swift/libswiftModelIO.dylib
/usr/lib/swift/libswiftSceneKit.dylib
/usr/lib/swift/libswiftSpriteKit.dylib
/usr/lib/swift/libswiftVision.dylib
/usr/lib/swift/libswiftRegexBuilder.dylib
/usr/lib/swift/libswiftDemangle.dylib
/usr/lib/swift/libswiftShazamKit.dylib
/usr/lib/swift/libswiftObservation.dylib
/usr/lib/swift/libswiftVideoToolbox.dylib
/usr/lib/swift/libswiftWebKit.dylib
/usr/lib/swift/libswiftNaturalLanguage.dylib
/usr/lib/swift/libswiftSystem.dylib
/usr/lib/swift/libswiftMapKit.dylib
/usr/lib/log/liblog_network.dylib

Rhino plugins that do not ship with Rhino
/Users/mccaul/Library/Application Support/McNeel/Rhinoceros/packages/8.0/FreeJewels/1.1.3/FJ_FreeJewelsToolbar.rhp “FJ_FreeJewelsToolbar” 1.0.0.0

Rhino plugins that ship with Rhino
/Applications/Rhino 8.app/Contents/Frameworks/RhMaterialEditor.framework “Renderer Development Kit” 8.9.24194.1002
/Applications/Rhino 8.app/Contents/Frameworks/RhCore.framework/Resources/ManagedPlugIns/Commands.rhp “Commands” 8.9.24194.18122
/Applications/Rhino 8.app/Contents/PlugIns/NamedSnapshots.rhp “Snapshots” 8.9.24194.1002
/Applications/Rhino 8.app/Contents/Frameworks/RhCore.framework/Resources/ManagedPlugIns/RDK_EtoUI.rhp “RDK_EtoUI” 8.9.24194.18122
/Applications/Rhino 8.app/Contents/Frameworks/RhCore.framework/Resources/ManagedPlugIns/MeshCommands.rhp “MeshCommands” 8.9.24194.18122
/Applications/Rhino 8.app/Contents/Frameworks/RhCore.framework/Resources/ManagedPlugIns/RhinoRenderCycles.rhp “Rhino Render” 8.9.24194.18122
/Applications/Rhino 8.app/Contents/Frameworks/RhCore.framework/Resources/ManagedPlugIns/RhinoCycles.rhp “RhinoCycles” 8.9.24194.18122
/Applications/Rhino 8.app/Contents/PlugIns/SectionTools.rhp “SectionTools” 8.9.24194.1002
/Applications/Rhino 8.app/Contents/PlugIns/RhinoRender.rhp “Legacy Rhino Render” 8.9.24194.1002
/Applications/Rhino 8.app/Contents/PlugIns/Displacement.rhp “Displacement” 8.9.24194.1002
/Applications/Rhino 8.app/Contents/PlugIns/PanelingTools.rhp “PanelingTools” 8.9.24194.1002
/Applications/Rhino 8.app/Contents/Frameworks/RhCore.framework/Resources/ManagedPlugIns/RhinoDLR_Python.rhp “IronPython” 8.9.24194.18122
/Applications/Rhino 8.app/Contents/Frameworks/RhCore.framework/Resources/ManagedPlugIns/GrasshopperPlugin.rhp “Grasshopper” 8.9.24194.18122
/Applications/Rhino 8.app/Contents/Frameworks/RhCore.framework/Resources/ManagedPlugIns/RhinoCodePlugin.rhp “RhinoCodePlugin” 8.9.24194.18122

flixchameroy · July 19, 2024, 3:40pm

I feel the exactly the same way ! Seriously guys it’s been 8 month now I’ve restrained myself from writing a similar post several times lately… It’s small things everywhere, small lags and crashes that happen so often. And I don’t have an external monitor ! Truth is I always wonder if I am the one doing something wrong, or if the soft is - but I don’t recall thinking this with V6 or V7.

Problems I had today :

Materials tab is soooo slow - either material edit from the object properties, or just from the regular material library
Rhino can’t quit properly without crashing. It seems like it only happens if Grasshopper was open. Or maybe it’s because Rhino was open for too long. No idea, but I very often forcequit Rhino at the end of the day.

Japhy · July 19, 2024, 4:02pm

please feel free to post issues

I do think we have youtracks (bug reports) in progress that are similar to these

Slower display speed at certain external Monitor Scalings
Material Tabs slow

This one i’m not seeing anything similar, can you grab a DMP and send us it along with your systemInfo

https://wiki.mcneel.com/rhino/manual_rhino_dmp_mac

CallumSykes · July 19, 2024, 4:29pm

To second @Japhy please do post these issues, no matter how small.

This thread here involves lots of papercuts, annoyances etc and I’ve been slowly youtracking items and fixing bugs, missing features etc. fixing them is very much in our interests.

And definitely report these, especially if they’re not getting fixed, we put a lot of priority into crashes.

encephalon · July 20, 2024, 5:43pm

i had that happening quite often either, can not recall if grasshopper was involved but it happened so often that i was starting to expect Rhino to crash rather than to close regularly. maybe it was file dependend, heavy file with plenty of materials is what i might have been using when these crashes when closing happened.

keithscadservices · July 21, 2024, 3:31am

McNeel’s worked hard to fix a lot of problems. It was a really ambitious project to bring the iOS Rhino up to the level of the Window’s version.

What does worry me is seeing “Rhino 9 WIP” posts already when 8 is still so broken.

Using the same code for multi-platform hasn’t worked out for most developers. Maybe game development engines but I’m just guessing on that one. Maui is a train wreck. I’m not sure if I should love or hate ETO - it seems to have its strengths but is also proving to be a bit of a basket case.

I’m a Window’s guy. Developing for Windows AND iOS at the same time consumes a lot of resources (I don’t blame them for trying to make everything the same - once everything is fixed it will probably pay off). As nice as it is to have a development team committed to Windows I’m sure that Windows would be even worse without iOS existing given the lack of competition.

McNeel won’t give up but they need to focus and not be working on WIP stuff that less than 2% of users will ever touch.

clivecarter · July 21, 2024, 5:52am

SEVERAL months ago I bought a Rhino 8 for Mac Commercial Licence upgrade, but I have yet to install it. That was largely and initially due to my need to update one of my 2012 Mac Pros to a more recent MacOS (using OpenCore Legacy Patcher).

However, given the issues I’ve read on the forum about V8, I’m not in a hurry to make that update.

Thus, I can’t comment on any Mac V8 issues. But if there are unresolved problems with V8 (possibly including the Windows version too), then it is slightly alarming to see references to WIP for a V9.

It suggests that not enough attention is focused on getting the basics right first. It reminds me of my local Council (if it is not a general human trait) who prefer to work on the bright, the shiny and the new, rather than to fix and maintain existing stuff which lacks PR- or photo-opportunities and is boring and unglamorous!

I would hope subsequent versions were at least as robust as their predecessor. McNeel is capable of doing great things. I continue to use Rhino 7 for Mac almost every day and remain impressed with it’s speed and stability.

Helvetosaur · July 21, 2024, 9:24am

Classically, the first iteration of the next version WIP is released the same day as the initial official release version. The fact that it was delayed by 6 months or more speaks to the fact that McNeel has been concentrating pretty much all their resources on fixing V8 stuff.

The WIP is not only new stuff but also potentially breaking re-writes of existing stuff that are too risky to put into a release version. The main new thing I have seen in the V9 WIP so far is ELMO - something that has been asked for for more than a decade - and which is guaranteed to be used by more than 2% of the people once fully developed.

In fact, if you are using V8, many of the functions you use were developed/redeveloped in the WIP phase. To dismiss that as ‘marginal 2% fluff’ is basically saying that you want to stop Rhino development altogether.

Gijs · July 21, 2024, 9:57am

Most of the development time still is focussed on Rhino 8. The WIP stuff that has been added is done by people that did not work on Rhino 8. (Elmo, Variable FilletSrf in gh to name a few)
Some stuff in the WIP was already in development but had to be postponed, but had already started in the Rhino 8 development cycle. Things like Constraints, Flair.

keithscadservices · July 21, 2024, 1:05pm

Lots of features soak up a lot of resources relative to how many actually use them. 2% is an exaggeration… in some cases but not all.

Helvetosaur · July 21, 2024, 1:14pm

One person’s critical feature is another person’s needless junk… Fillets? 99%+ of architects won’t need or use them. Layouts/drafting tools? Most people modeling for direct manufacturing won’t need them or can get by with a very minimal toolset.

keithscadservices · July 21, 2024, 1:35pm

None of that is really being disputed here. It’s more a matter of how much resources are tied up in a given feature relative to how much it’s used and/or how critical it is to the user that it functions properly. The original concerns from this post are pretty critical. “Flare” and even Elmo aren’t. Now… that’s not to say that the people working on those features would just be able to drop what they’re doing and try to fix the issues described above.

Fillets are actually a pretty important feature. That might not be the best example to make your case.

And Layout/Drafting tools: They are more like a fundamental program feature. It would be crazy if that was missing.

Your examples are more like things LOTS of people use. I wouldn’t consider either to be “fringe” or “niche” features.

davidcockey · July 21, 2024, 1:37pm

You can install V8 and keep V7. No need to replace V7 with V8.

Try V8 and see if it is as bad as you are assuming from forum posts.

Helvetosaur · July 21, 2024, 1:46pm

Dunno, most architects I deal with don’t even know that the fillet (surface/solid) tools exist.

And most of the modelmakers I know - who use Rhino to create data for CNC cutting or 3D printing - don’t know what a layout is or how to make one. They simply have no need of them.

clivecarter · July 21, 2024, 1:55pm

YES, I’ll probably do that when I have the updated an OS as described above (i.e. OpenCore Legacy Patcher).

I’m running V7 on MacOS 10.14.6 (Mojave) on the modular Mac Pro 2012. It’s still a capable computer and I have several.

However, Mojave was the last official Apple OS that supports it, whereas the minimum system requirement for Mac Rhino V8 is macOS 12.4 (Monterey).

stevebaer · July 21, 2024, 3:43pm

There is a very good chance Rhino 8 will not work well on your computer. I’ve seen a case where a user tried running an unsupported version of MacOS on older hardware and things were not working correctly. One of the reasons Apple does not update an OS for older hardware is because there are specific hardware features that don’t exist that the OS depends on. Mac Rhino expects certain hardware features of metal to be available on the GPU for a given version of the operating system and when the OS possibly lies in this case because it was “patched”, then crashes start happening.

clivecarter · July 21, 2024, 5:25pm

Steve,

Thanks for the comment. Ok, I accept that.

Although I’ll give OpenCore Legacy Patcher a try when I have time (on another Mac Pro). OCLP is at version 1.5.0.

I haven’t tried OCLP yet, but I understand that in earlier development, the presence of Metal capability was strongly recommended, if not required (heroically, this community project now appear to be developing OCLP for certain specified non-Metal Macs also!)

Rhino 8 needs Monterey (MacOS 12) which is likely the furtherest to which I would try to advance, using OCLP. After Monterey, Apple started steering strongly towards their Apple Silicon chip spec.

I wonder if anyone else has tried to run Rhino 8 using OCLP on older hardware?

Rhino 7 required a minimum of Mojave and in turn, Mojave required a *Metal-*capable card.

Thus, I’m running Rhino 7—very well—on an nVidia Quadro K5000 driving a 30" HP monitor. I have several other Metal-compatible cards of higher spec. I reckon they’d be worth trying.

From the above OCLP notes (green box), my tentative conclusion is that I may be okay with a Mac Pro 2012 using Metal-capable cards, but only up to 12 (MacOS Monterey) that is McNeel’s Mac system requirement for V8.

———
Below are the graphics aspects of my current V7 configuration:

Rhino 7 SR37 2024-4-16

Apple macOS Version 10.14.6 (Build 18G9323) (Physical RAM: 48Gb)
Mac Model Identifier: MacPro5,1
Language: en-GB (MacOS default)

NVIDIA Quadro K5000 OpenGL Engine
(OpenGL ver:4.1 NVIDIA-12.0.24 355.11.10.50.10.103)

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: NVIDIA Corporation
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: NVIDIA Quadro K5000
Displays: HP ZR30w (101dpi 1x)

Graphics processors
NVIDIA Quadro K5000 (4 GB)
HP ZR30w (2560 x 1600)

miano · July 25, 2024, 6:11pm

I express a contrary view. I have been using Rhino for Mac since it first came out. I was surprised how good the first version was.

I have seen a steady improvement in the product.

I complain about bugs as much as anyone. However, we are dealing with complex system. Rhino is not a news app for a phone. The folks at McNeel are responsive to user questions and bugs.