As a trainee of our online training is working on Rhino for Mac, he mentioned that setting proper values is not possible. And he’s right as I tested it on both Rhino 5 for Mac and Rhino 6 for Mac WIP.
What we need are more or less these settings:
-0.000000001 and +0.000000001
Can the responsible developer test this out and fix this please. I am crying over here when I feel where Rhino for Mac is after more than 10 years of development and promiss after promiss. I never looked too much into it but again I feel how embarrassing it is to sell Rhino for Mac when even the WIP shows these kind of problems.
I’m sad to hear you are so embarrassed by Rhino for Mac. I’m really not sure what promises you are referring to…I know we try hard not to promise things, so I’m just curious.
This probably boils down to me not understanding how this dialog works, but, in Rhino 6 for Windows, in the Analyze > Surface > Curvature > Gaussian dialog, when I enter 0.000000001 in the upper or lower bounds of the curvature range, the values get rounded in an unpredictable way. Perhaps @pascal can help me better understand what is going on here.
It looks like these numbers are indeed rounded on Mac. On Windows, but not on Mac, I can use -1e-09 and 1e-09 and get the expected results; typing in a lot pf leading zeros does do something ‘automatic’ on Windows.
And yes, on the Mac small figures are rounded to zero. However, especially Gaussian curvature analysis for analyzing surface developability only works when I am able to use small figures.
In Rhino Win, I often type -0.000000001 which then automatically is converted to -1e-09. I am fine with that.
It is strange that in 10 years no one ever mentioned this problem with Rhino for Mac. Apparently these users never do anything with the Gaussian Curvature feature for analyzing developability.
I know that you do everything to make Rhino for Mac a good product. However, after 10 year of development, it is so strange that a simple feature like this doesn’t work when I try to use it in the WIP after my trainee mentioned it didn’t work.
I never work with Rhino for Mac as it is not my taste and at the same time I am very happy with my iPhone. So I do understand the power of Apple products.
When I develop a training, I don’t want to be bothered whether Rhino Win functions work in Rhino Mac. Then it would be impossible to develop a training based on workflows that I developed with Rhino Win. Another option is to mention that my training is only applicable to Rhino Win, but that would be a strange thing don’t you think?
The promiss was that Rhino for Mac would be similar to Rhino for Windows when it comes to features and functions and when such a simple thing doesn’t work in the WIP, I feel disappointed.
A couple of years ago I had to give Rhino training to an architecture firm with Rhino Mac and tried to figure out what was working for me related to my workflows. When I realized how limited Rhino 5 for Mac was I just gave up on it.
Rhino 5 for Mac was never sold as an equivalent to Rhino 5 for Windows.
Rhino 6 WIP for Mac is just that - a WIP. And, like it or not, as it has been since before Rhino 1, McNeel relies on feedback from users to get that out of WIP.
Like often there’s nothing to blame McNeel here? Isn’t the development of Rhino for Mac a super slow process? We speak to prospects and users every day and what do you think about their perception?
What about when you’re interested in, or purchase a diesel Audi to find out that it doesn’t have airconditioning like the petrol Audi? And, oh yes it also seems missing the fifth gear when you drive it? That’s my perception of Rhino for Mac since that’s the only version we can sell and use for training.
I was there in Barcelona when it was announced that Rhino for Mac would be developed and soon would be the same as Rhino Win. That’s more than a decade ago…
Thanks for clarifying this. I was curious what you were referring to. This meeting was probably about 6 or 7 years before I joined McNeel. I can’t promise I wouldn’t have said anything like this but it does sound like an unrealistic promise to make. But we now have the benefit of hindsight.
We are definitely responsible for the slow development. I would agree that it is a slow process. Cross-platform development is quite challenging, especially in the case of Rhino (the decision to use native UI on both platforms, supporting a plugin architecture, and the list goes on). You likely know all that already, but I think it bears repeating.
Me too. We need to fix that bug. Thanks for reporting it. While researching it, I found a lot of counter-intuitive and odd behavior in Rhino for Windows. Cross-platform is hard.
Features and bugs aside, I believe this will still be a challenge given the decision we made to change many aspects of the user interface in Rhino for Mac; both large and small. This is a major tradeoff and one I hear from educators quite a bit. If the tutor is familiar with one platform, doing a training with students on both platforms poses some problems. I still think we have a lot of work to do on this front.
This is what I need. Just a patient listener who doesn’t counter my arguments but shows empathy.
And yes, Rhino for Windows is often counter intuitive. And then I got used to that…
Trainees who are new to Rhino often give valuable feedback about non logical stuff in Rhino.
but it does sound like an unrealistic promise to make. But we now have the benefit of hindsight.